Prev: [].all?{} and [].any?{} Behavior
Next: binary encode 7 ([7].pack("C")) as "\007" instead of "\a"
From: Joseph E. Savard on 29 Jul 2010 17:55
The docs pretty clear...
If the block is not given, Ruby adds an implicit block of{|obj| obj} (that
is all? <Enumerable.html#M003131>  will return true only if none of the
collection members are false or nil.)

Its an assumption is always true unless the block tells it something
different..

Assuimng Happy unless its told not to be happy! :-)

irb(main):019:0> [].all? {|e| puts e; e==3}
=> true
irb(main):020:0> [].all? {|e| puts e; e==2}
=> true
irb(main):021:0> [].all? {|e| puts e; e==1}
=> true
irb(main):022:0> [].all? {|e| puts e; e==100}
=> true
irb(main):023:0>


[].all? Is true..

Its interesting.

irb(main):019:0> [].all? {|e| e==3}
=> true
irb(main):020:0> [].all? {|e| e==2}
=> true
irb(main):021:0> [].all? {|e| e==1}
=> true
irb(main):022:0> [].all? {|e| e==100}
=> true
irb(main):023:0>


[].all? Is true..

Its interesting.


> From: John Sikora <john.sikora(a)xtera.com>
> Reply-To: <ruby-talk(a)ruby-lang.org>
> Newsgroups: comp.lang.ruby
> Date: Fri, 30 Jul 2010 06:27:52 +0900
> To: ruby-talk ML <ruby-talk(a)ruby-lang.org>
> Subject: [].all?{} and [].any?{} Behavior
>
> I find the following behavior interesting (so interesting that I
> modified it), and I would like to hear others' thoughts on the subject:
>
> [3].all? {|element| element == 3 } # => true
> [3].all? {|element| element != 3 } # => false (sanity checks)
>
> [].all? {|element| element == 3 } # => true
> [].all? {|element| element != 3 } # => true
>
> [].any? {|element| element == 3 } # => false
> [].any? {|element| element != 3 } # => false
>
> Ruby 1.8.6 and 1.9.1 both give these results.
>
> The first interesting thing is that both the == and the != checks give
> the same logical result (always true for all?, always false for any?).
> After thinking about it a little, I decided that this is the desired
> behavior.
>
> I also understand why it happens. For example, in the case of all?, the
> documentation says that true will be the result if the block never
> returns false or nil. In the case of [], the block never gets called, so
> the result is true. I know the block never gets called because the
> following does not print anything:
>
> [].all? {|dummy| puts 'print something'}, while
>
> [3].all? {|dummy| puts 'print something'} does.
>
> The second interesting thing is that a result of this behavior is that
> for the same check, all? will give a result of true, while any? will
> give a result of false. This seems contradictory.
>
> I would prefer that for [], both all? and any? would give a result of
> false for any check. So I have over-ridden Array#all?, returning false
> if self == []. My main motivation for doing so is in situautions such
> as:
>
> obj_array.find_all{|obj| obj.attr_1 == x}.all?{|obj| obj.attr_2 == y}
>
> If the find_all returns [], I want the all? result to be false, not
> true.
>
> I assume that others have run across this but some quick searches did
> not turn up anything. I am wondering how others deal with this such as
> over-riding as I do, checking for [] each time (which does not seem very
> Ruby-like), or even leaving the operation as is because for some, it may
> be the desired behavior.
>
> Finally, are there any potential detrimental effects that might occur
> due to the behavior modification that I made. I am not a Rails user (if
> that matters), I mainly use Ruby for scripting and hardware control
> applications (and I am interested in learning as much as I can about
> Ruby because I like it so much).
>
> js
> --
> Posted via http://www.ruby-forum.com/.
>


From: John W Higgins on 29 Jul 2010 19:39
[Note: parts of this message were removed to make it a legal post.]

Afternoon,

On Thu, Jul 29, 2010 at 2:27 PM, John Sikora <john.sikora(a)xtera.com> wrote:

> I assume that others have run across this but some quick searches did
> not turn up anything. I am wondering how others deal with this such as
> over-riding as I do, checking for [] each time (which does not seem very
> Ruby-like), or even leaving the operation as is because for some, it may
> be the desired behavior.
>

I might suggest your better course would be to create a new method rather
than override the existing method. Maybe something like js_any? or js_all?
would be better in that it shows both what it's doing and that it's not the
standard method at the same time. Then you have no issues with any other
code that depends on the standard methodology in terms of the methods. I
appreciate the aesthetics are a little lacking but sometimes that a small
price to pay.

John

From: Rick DeNatale on 30 Jul 2010 11:49
On Thu, Jul 29, 2010 at 5:27 PM, John Sikora <john.sikora(a)xtera.com> wrote:
> The second interesting thing is that a result of this behavior is that
> for the same check, all? will give a result of true, while any? will
> give a result of false. This seems contradictory.

Well, there's a theoretical basis for this. Enumeration#all? is an
implementation of the universal quantifier from predicate logic (that
upside down A) symbol.

By convention the universal quantifier evaluates to true for an empty set:
http://en.wikipedia.org/wiki/Universal_quantification#The_empty_set
http://en.wikipedia.org/wiki/Vacuous_truth
>
> I would prefer that for [], both all? and any? would give a result of
> false for any check. So I have over-ridden Array#all?, returning false
> if self == []. My main motivation for doing so is in situautions such
> as:
>
> obj_array.find_all{|obj| obj.attr_1 == x}.all?{|obj| obj.attr_2 == y}
>
> If the find_all returns [], I want the all? result to be false, not
> true.
>
> I assume that others have run across this but some quick searches did
> not turn up anything. I am wondering how others deal with this such as
> over-riding as I do, checking for [] each time (which does not seem very
> Ruby-like), or even leaving the operation as is because for some, it may
> be the desired behavior.
>
> Finally, are there any potential detrimental effects that might occur
> due to the behavior modification that I made. I am not a Rails user (if
> that matters), I mainly use Ruby for scripting and hardware control
> applications (and I am interested in learning as much as I can about
> Ruby because I like it so much).

For your own usage as long as it doesn't mess up some other code you
are using, feel free.

For library code, such as in a gem I think it would be better to think
up some other method name rather than changing the standard, e.g.

module Enumerable
def non_vacuous_all?(&b)
!empty? && all?(&b)
end
end

[3].all? {|element| element == 3 } # => true
[3].all? {|element| element != 3 } # => false

[].all? {|element| element == 3 } # => true
[].all? {|element| element != 3 } # => true

[3].non_vacuous_all? {|element| element == 3 } # => true
[3].non_vacuous_all? {|element| element != 3 } # => false

[].non_vacuous_all? {|element| element == 3 } # => false
[].non_vacuous_all? {|element| element != 3 } # => false

[].any? {|element| element == 3 } # => false
[].any? {|element| element != 3 } # => false

There may be a better name than non_vacuous_all? but I can't think of one.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

From: Josh Cheek on 30 Jul 2010 14:55
[Note: parts of this message were removed to make it a legal post.]

On Fri, Jul 30, 2010 at 10:49 AM, Rick DeNatale <rick.denatale(a)gmail.com>wrote:

> module Enumerable
> def non_vacuous_all?(&b)
> !empty? && all?(&b)
> end
> end
>
> [3].all? {|element| element == 3 } # => true
> [3].all? {|element| element != 3 } # => false
>
> [].all? {|element| element == 3 } # => true
> [].all? {|element| element != 3 } # => true
>
> [3].non_vacuous_all? {|element| element == 3 } # => true
> [3].non_vacuous_all? {|element| element != 3 } # => false
>
> [].non_vacuous_all? {|element| element == 3 } # => false
> [].non_vacuous_all? {|element| element != 3 } # => false
>
> [].any? {|element| element == 3 } # => false
> [].any? {|element| element != 3 } # => false
>
> There may be a better name than non_vacuous_all? but I can't think of one.
>
>
How about #appall? to imply that it is a pessimistic implementation of #all?
:)

From: Robert Klemme on 31 Jul 2010 06:07
2010/7/30 Rick DeNatale <rick.denatale(a)gmail.com>:
> On Thu, Jul 29, 2010 at 5:27 PM, John Sikora <john.sikora(a)xtera.com> wrote:
>> The second interesting thing is that a result of this behavior is that
>> for the same check, all? will give a result of true, while any? will
>> give a result of false. This seems contradictory.
>
> Well, there's a theoretical basis for this.  Enumeration#all? is an
> implementation of the universal quantifier from predicate logic (that
> upside down A) symbol.
>
> By convention the universal quantifier evaluates to true for an empty set:
> http://en.wikipedia.org/wiki/Universal_quantification#The_empty_set
> http://en.wikipedia.org/wiki/Vacuous_truth

To complement this, De Morgan's Laws help do the conversion between
all? and and? variants properly:
http://en.wikipedia.org/wiki/De_Morgan%27s_laws

>> I would prefer that for [], both all? and any? would give a result of
>> false for any check. So I have over-ridden Array#all?, returning false
>> if self == []. My main motivation for doing so is in situautions such
>> as:
>>
>> obj_array.find_all{|obj| obj.attr_1 == x}.all?{|obj| obj.attr_2 == y}
>>
>> If the find_all returns [], I want the all? result to be false, not
>> true.
>>
>> I assume that others have run across this but some quick searches did
>> not turn up anything. I am wondering how others deal with this such as
>> over-riding as I do, checking for [] each time (which does not seem very
>> Ruby-like), or even leaving the operation as is because for some, it may
>> be the desired behavior.
>>
>> Finally, are there any potential detrimental effects that might occur
>> due to the behavior modification that I made. I am not a Rails user (if
>> that matters), I mainly use Ruby for scripting and hardware control
>> applications (and I am interested in learning as much as I can about
>> Ruby because I like it so much).
>
> For your own usage as long as it doesn't mess up some other code you
> are using, feel free.

I disagree: IMHO it is a bad idea to change such fundamental behavior
if only for own code. This opens the door widely for all sorts of
bugs and issues. For example, you get used to #all? doing also the
emptyness check and get confused when reading other code which of
course relies on the regular behavior. Or you forget the "require"
for the file that changes semantics of #all? and #any? and receive in
turn subtly bugs which might be hard to track down. Even worse, you
use library code that in turn uses #all? or #any? without you knowing
it and this code suddenly breaks.

> For library code, such as in a gem I think it would be better to think
> up some other method name rather than changing the standard, e.g.

That's definitively the way to go if the behavior should be put into a method.

> module Enumerable
>  def non_vacuous_all?(&b)
>    !empty? && all?(&b)
>  end
> end
>
> [3].all? {|element| element == 3 }  # => true
> [3].all? {|element| element != 3 }  # => false
>
> [].all? {|element| element == 3 }   # => true
> [].all? {|element| element != 3 }   # => true
>
> [3].non_vacuous_all? {|element| element == 3 }  # => true
> [3].non_vacuous_all? {|element| element != 3 }  # => false
>
> [].non_vacuous_all? {|element| element == 3 }   # => false
> [].non_vacuous_all? {|element| element != 3 }   # => false
>
> [].any? {|element| element == 3 }   # => false
> [].any? {|element| element != 3 }   # => false
>
> There may be a better name than non_vacuous_all? but I can't think of one
 |  Next  |  Last
Pages: 1 2
Prev: [].all?{} and [].any?{} Behavior
Next: binary encode 7 ([7].pack("C")) as "\007" instead of "\a"