Prev: binary encode 7 ([7].pack("C")) as "\007" instead of "\a"
Next: leak tracking x64
From: John Sikora on 30 Jul 2010 14:22
Rick Denatale wrote:

> 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
>>

Well, that seals it for me. My thinking is wrong if it goes against
convention, not only in Ruby, but in universal quantification.

>
> 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.
>

Agreed, I should use a similar technigue for my specific applications.

js
--
Posted via http://www.ruby-forum.com/.

From: John Sikora on 30 Jul 2010 14:25
Joel VanderWerf wrote:
> pattern = /.../
> tests = [ Test.new(...), ..., Test.new(...) ]
> runnable_tests = tests.select {|test| pattern === test.name}
>
> if runnable_tests.all?{|test|test.pass}
> puts "Ok!"
> else
> puts "Failed!"
> end
> __END__
>
> How do we want this program to work if no tests match the pattern? Is it
> a failure case? IMO, it is not.
>
> I don't want to code a special case for runnable_tests.empty?
>
> This seems very English-like to me, but YMMV of course.

Yes, I can see where you would want your result to be according to
convention and opposite of what I stated.

js

--
Posted via http://www.ruby-forum.com/.

From: Robert Klemme on 31 Jul 2010 06:14
2010/7/30 Jarmo Pertman <jarmo.p(a)gmail.com>:

> I'd have to agree with John on this one. It is really bizarre that
> [].any? returns false and [].all? returns true. It is just not what to
> expect without reading documentation and thinking about every word
> written in there and trying things out in irb.

This behavior is _exactly_ what I expect from these methods.
Otherwise it would break all sorts of boolean logic. These methods
are defined the way they are with good reason - even if this does not
meet your expectation here. It's the most reasonable definition in
light of boolean logic and De Morgan's laws which I believe
*everybody* writing software must know by heart and understand because
it is at the very foundation of our profession.

> I love Ruby because most of the time everything just works as you'd
> expect without reading any documentation at all and this is not the

Frankly, this is a dangerous thing to do. Generally doing away with
documentation will bring you in trouble sooner or later.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

From: Maurizio De Santis on 1 Aug 2010 12:28
Josh Cheek wrote:
> On Fri, Jul 30, 2010 at 10:49 AM, Rick DeNatale
> <rick.denatale(a)gmail.com>wrote:
>
>> [].all? {|element| element != 3 } # => true
>> 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?
> :)

I think that the best name for that method would be

def all!?(&block)
!empty? && all?(&block)
end

It's a pity it is not permitted!

so I propose

def strict_all?(&block)
!empty? && all?(&block)
end
--
Posted via http://www.ruby-forum.com/.

From: Rick DeNatale on 1 Aug 2010 12:46
On Sun, Aug 1, 2010 at 12:28 PM, Maurizio De Santis
<desantis.maurizio(a)gmail.com> wrote:
> Josh Cheek wrote:
>> On Fri, Jul 30, 2010 at 10:49 AM, Rick DeNatale
>> <rick.denatale(a)gmail.com>wrote:
>>
>>> [].all? {|element| element != 3 }   # => true
>>> 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?
>> :)
>
> I think that the best name for that method would be
>
> def all!?(&block)
>  !empty? && all?(&block)
> end

No that doesn't make sense to me all not? Not at all!

All not what?

Personally I think this attempts too hard to make the method name
short, at the expense of revealing the intention.
>
> It's a pity it is not permitted!
>
> so I propose
>
> def strict_all?(&block)
>  !empty? && all?(&block)
> end

I don't like this either, it doesn't evoke the right meaning, to me at
least. What are we being strict about? I would tend to read it as
following strictly the conventional meaning of the existential
quantifier, which the existing Enumerable#all? method already does.


--
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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: binary encode 7 ([7].pack("C")) as "\007" instead of "\a"
Next: leak tracking x64