Zero is true ... whoda thunk?

From: David Naseby [mailto:david.naseby@eonesolutions.com.au]

Got milk?

What’s your answer, yes or no?

No, of course.

I’d prefer to encode this as:

if got_milk? … end

where

def got_milk?
@milk_volume.zero?

Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…

···

-----Original Message-----

David
http://homepages.ihug.com.au/~naseby/

David Naseby wrote:

···

-----Original Message-----
From: David Naseby [mailto:david.naseby@eonesolutions.com.au]

Got milk?

What’s your answer, yes or no?

No, of course.

I’d prefer to encode this as:

if got_milk? … end

where

def got_milk?
@milk_volume.zero?

Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…

Haha… well, the got-milk logic would mean that negative numbers
would also be false, right? “I’ve got -5 gallons of milk. Give me
5 gallons, and I still won’t have any!”

Now you’ve got me thinking about the Mad Hatter’s tea party…

Hal

David Naseby wrote:

> ... THIS is why I don't > post normally....

Do you do anything “normally” :slight_smile: ??

I agree with your original argument 100%, though.

How about:

@milk_volume.nonzero?

···

David Naseby (david.naseby@eonesolutions.com.au) wrote:

def got_milk?
@milk_volume.zero?

Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…


Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

nonzero? returned nil instead of false for me. Shouldn’t it return false?

Eric Hodel wrote:

···

David Naseby (david.naseby@eonesolutions.com.au) wrote:

def got_milk?
@milk_volume.zero?

Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…

How about:

@milk_volume.nonzero?

8< ----- snip -----

No. From the pickaxe:

nonzero? num.nonzero? → num or nil

Returns num if num is not zero, nil otherwise. This behavior is useful
when chaining comparisons:

a = %w( z Bb bB bb BB a aA Aa AA A )
b = a.sort {|a,b| (a.downcase <=> b.downcase).nonzero? || a <=> b }
b » [“A”, “a”, “AA”, “Aa”, “aA”, “BB”, “Bb”, “bB”, “bb”, “z”]

Cheers…
-C

···

On Thu, 20 May 2004 09:47:07 +0900, Nicholas Van Weerdenburg nick@activehitconsulting.com wrote:

nonzero? returned nil instead of false for me. Shouldn’t it return false?

[Claus Spitzer DocBoobenstein@gmail.com, 2004-05-20 02.53 CEST]

···

On Thu, 20 May 2004 09:47:07 +0900, Nicholas Van Weerdenburg > nick@activehitconsulting.com wrote:

nonzero? returned nil instead of false for me. Shouldn’t it return false?

8< ----- snip -----

No. From the pickaxe:

nonzero? num.nonzero? → num or nil

Returns num if num is not zero, nil otherwise. This behavior is useful
when chaining comparisons:

a = %w( z Bb bB bb BB a aA Aa AA A )
b = a.sort {|a,b| (a.downcase <=> b.downcase).nonzero? || a <=> b }
b » [“A”, “a”, “AA”, “Aa”, “aA”, “BB”, “Bb”, “bB”, “bb”, “z”]

But why shouldn’t it return false instead of nil?

Well, it’s just a matter of grammar. zero? could have been implemented
as returning nil or or 0 (since 0 is true), but that’s not as neat and
tidy as true/false. On the other hand, nonzero? returns nil or the
actual number, and nil/number is a better pair than false/number. From
the programmer’s view, it’s neater to have false/true and nil/value
pairs, and unless you do something like
if num.nonzero? == false
instead of
if num.zero?
then you won’t really notice the difference. Cheers!
-C

···

On Thu, 20 May 2004 23:42:59 +0900, Carlos angus@quovadis.com.ar wrote:

[Claus Spitzer DocBoobenstein@gmail.com, 2004-05-20 02.53 CEST]

On Thu, 20 May 2004 09:47:07 +0900, Nicholas Van Weerdenburg > > nick@activehitconsulting.com wrote:

nonzero? returned nil instead of false for me. Shouldn’t it return false?

8< ----- snip -----

No. From the pickaxe:

nonzero? num.nonzero? → num or nil

Returns num if num is not zero, nil otherwise. This behavior is useful
when chaining comparisons:

a = %w( z Bb bB bb BB a aA Aa AA A )
b = a.sort {|a,b| (a.downcase <=> b.downcase).nonzero? || a <=> b }
b » [“A”, “a”, “AA”, “Aa”, “aA”, “BB”, “Bb”, “bB”, “bb”, “z”]

But why shouldn’t it return false instead of nil?

I’ve said this elsewhere in the thread, so just briefly here: true/false can
possibly be considered not as basic as nil/object; true and false would then
be seen as a secondary representation of that dichotomy, for convenience.
See [ruby-talk:100755].

Nicholas Van Weerdenburg> nonzero? returned nil instead of false for me.
Shouldn’t it return false?
Claus Spitzer > No. From the pickaxe:

···

But why shouldn’t it return false instead of nil?

Hi –

···

On Fri, 21 May 2004, Dave Burt wrote:

I’ve said this elsewhere in the thread, so just briefly here: true/false can
possibly be considered not as basic as nil/object; true and false would then
be seen as a secondary representation of that dichotomy, for convenience.
See [ruby-talk:100755].

There’s no nil/object dichotomy, though; nil is an object. It’s handy
for flagging certain conditions (like failure, as in Regexp#match),
but that’s just a matter of convention; nil itself is still fully an
object.

David


David A. Black
dblack@wobblini.net

I found this problem thorny when trying to export true/false to a
database that does not support booleans (only int). So I wrote a class
that magically does the conversion coming and going. Other than that, I
find nil a very useful value and nice to be separate from numbers.

Dan

···

On May 20, 2004, at 20:58, David A. Black wrote:

Hi –

On Fri, 21 May 2004, Dave Burt wrote:

I’ve said this elsewhere in the thread, so just briefly here:
true/false can
possibly be considered not as basic as nil/object; true and false
would then
be seen as a secondary representation of that dichotomy, for
convenience.
See [ruby-talk:100755].

There’s no nil/object dichotomy, though; nil is an object. It’s handy
for flagging certain conditions (like failure, as in Regexp#match),
but that’s just a matter of convention; nil itself is still fully an
object.

David


David A. Black
dblack@wobblini.net

David A. Black> There’s no nil/object dichotomy, though; nil is an object.

Naturally – everything is.

Nil is the object that stands in at roll call and says “um, he’s not
here.”

:slight_smile:

cheers,
–Mark

···

On May 21, 2004, at 1:18 AM, Dave Burt wrote:

David A. Black> There’s no nil/object dichotomy, though; nil is an
object.

Naturally – everything is.

“Dan Janowski” danj@3skel.com schrieb im Newsbeitrag
news:AE82CDF1-AAE8-11D8-AC4D-00039357B54C@3skel.com

I found this problem thorny when trying to export true/false to a
database that does not support booleans (only int). So I wrote a class
that magically does the conversion coming and going. Other than that, I
find nil a very useful value and nice to be separate from numbers.

That inspired me to this piece of code:

CONVERSIONS = {}

def convert(obj)
cv = find_converter obj
cv ? cv.call( obj ) : obj
end

def find_converter(obj)
obj.class.ancestors.each do |cl|
x = CONVERSIONS[cl]
return x if x
end

nil
end

CONVERSIONS[1.class] = proc {|x| x != 0}

convert 1023

You could even extend this to handle different target contexts (sometimes
you want int → bool, sometimes int → float):

def convert(obj, target=nil)
cv = find_converter obj, target
cv ? cv.call( obj ) : obj
end

def find_converter(obj, target)
if target
obj.class.ancestors.each do |cl|
x = CONVERSIONS[ [cl, target] ]
return x if x
end
else
obj.class.ancestors.each do |cl|
x = CONVERSIONS[cl]
return x if x
end
end

nil
end

Regards

robert