Zero is true, but it isn't

I was wondering today, so I tried this:

puts "It's true" if 0

Which prints "It's true", meaning 0 is not false. (This should surprise C/C++/etc. people).

So that means
puts "It's equal" if 0 == true

but 0 != true. Although it seems it should be, since 0 != false as well. So, by extension, if an object is not nil, and it is not equal to false, then it would stand to reason that it is equal to true.

Any thoughts?

Regards,
   JJ

···

---
Help everyone. If you can't do that, then at least be nice.

So that means
puts "It's equal" if 0 == true

but 0 != true. Although it seems it should be, since 0 != false as
well. So, by extension, if an object is not nil, and it is not equal to
false, then it would stand to reason that it is equal to true.

Any thoughts?

0 is not equal to true, but is implicitly converted to true.

Try:
puts "It's equal" if !!0 == true

Hi --

I was wondering today, so I tried this:

puts "It's true" if 0

Which prints "It's true", meaning 0 is not false. (This should surprise C/C++/etc. people).

So that means
puts "It's equal" if 0 == true

but 0 != true. Although it seems it should be, since 0 != false as well. So, by extension, if an object is not nil, and it is not equal to false, then it would stand to reason that it is equal to true.

Any thoughts?

Every object has a Boolean value of true or false, separately from the
fact that there are objects called true and false. The objects false
and nil have a Boolean value of false; all other objects have a
Boolean value of true (including true, integers, strings, etc.).

The result is that passing the "if x" test, on the one hand, and being
the object true, on the other, are not the same thing.

David

···

On Thu, 20 Apr 2006, John Johnson wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" PDF now on sale! Ruby for Rails
Paper version coming in early May!

You are seeing a particular case of the fact that the boolean interpretation an object may be different from the object value itself. And == is comparing object values, not boolean interpretations. Then the result of == is interpreted in boolean context, but by then 0 was seen as an integer already, which is certainly different from the object true.

To make it apparent take "foo". The string "foo" is true in boolean context, but it won't surprise you to realise that "foo" == true does not hold.

-- fxn

···

On Apr 20, 2006, at 1:51, John Johnson wrote:

I was wondering today, so I tried this:

puts "It's true" if 0

Which prints "It's true", meaning 0 is not false. (This should surprise C/C++/etc. people).

So that means
puts "It's equal" if 0 == true

$ irb

irb(main):001:0> true.class
=> TrueClass
irb(main):002:0> false.class
=> FalseClass
irb(main):003:0> 0.class
=> Fixnum

0 is not a boolean, so interpretation is up to the language.

Most common is 0 := false, 1 := true as you already know.
I think in Visual Basic it is 0 := false, -1 := true
Also possible 0 := false, not 0 := true

So it depends ... :slight_smile:

···

--- Ursprüngliche Nachricht ---
Von: Xavier Noria <fxn@hashref.com>
An: ruby-talk@ruby-lang.org (ruby-talk ML)
Betreff: Re: Zero is true, but it isn't
Datum: Thu, 20 Apr 2006 16:26:09 +0900

On Apr 20, 2006, at 1:51, John Johnson wrote:

> I was wondering today, so I tried this:
>
> puts "It's true" if 0
>
> Which prints "It's true", meaning 0 is not false. (This should
> surprise C/C++/etc. people).
>
> So that means
> puts "It's equal" if 0 == true

You are seeing a particular case of the fact that the boolean
interpretation an object may be different from the object value
itself. And == is comparing object values, not boolean
interpretations. Then the result of == is interpreted in boolean
context, but by then 0 was seen as an integer already, which is
certainly different from the object true.

To make it apparent take "foo". The string "foo" is true in boolean
context, but it won't surprise you to realise that "foo" == true does
not hold.

-- fxn

Wouldn't it be neat if true === worked with anything that is interpreted as true

e.g.

case x
   when true
      ...
    else
      ...
end

Of course anyone would use an if statement in this situation, but it is kind of conceptually clean and sort of matches up with Range#===, Regexp#===, etc.

···

On Apr 20, 2006, at 3:26 AM, Xavier Noria wrote:

On Apr 20, 2006, at 1:51, John Johnson wrote:

I was wondering today, so I tried this:

puts "It's true" if 0

Which prints "It's true", meaning 0 is not false. (This should surprise C/C++/etc. people).

So that means
puts "It's equal" if 0 == true

You are seeing a particular case of the fact that the boolean interpretation an object may be different from the object value itself. And == is comparing object values, not boolean interpretations. Then the result of == is interpreted in boolean context, but by then 0 was seen as an integer already, which is certainly different from the object true.

To make it apparent take "foo". The string "foo" is true in boolean context, but it won't surprise you to realise that "foo" == true does not hold.

-- fxn

And the argument against 0 being false is shell scripts, where 0 is true.

-austin

···

On 4/20/06, Peter Ertl <pertl@gmx.org> wrote:

$ irb

irb(main):001:0> true.class
=> TrueClass
irb(main):002:0> false.class
=> FalseClass
irb(main):003:0> 0.class
=> Fixnum

0 is not a boolean, so interpretation is up to the language.

Most common is 0 := false, 1 := true as you already know.
I think in Visual Basic it is 0 := false, -1 := true
Also possible 0 := false, not 0 := true

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

Wouldn't it be neat if true === worked with anything that is
interpreted as true

You saved my day, I was really disappointed when I found that this code was
missing from ruby

def TrueClass.===(other);other?true:false;end
def FalseClass.===(other);! true === other; end ### That 1 is ugly
def NilClass.===(other);! true === other; end

shall we make a CR or for Ruby2?

e.g.

case x
   when true
      ...
    else
      ...
end

Of course anyone would use an if statement in this situation, but it
is kind of conceptually clean and sort of matches up with Range#===,
Regexp#===, etc.

Completely agree and if anyone uses an if statement why should we!!!!!

But I guess it is up to everyone to "fix" ruby for his own needs.

Cheers
Robert

···

On 4/20/06, Logan Capaldo <logancapaldo@gmail.com> wrote:

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

Thanks to all who responded to my query.

Ruby is so magnificent, I would never dream of suggesting a change, because, ultimately, it would probably somehow hose the principal of least surprise that makes it so great.

Thanks again,
   JJ

···

On 20-Apr-2006, at 04:26, Peter Ertl wrote:

Most common is 0 := false, 1 := true as you already know.
I think in Visual Basic it is 0 := false, -1 := true
Also possible 0 := false, not 0 := true

So it depends ... :slight_smile:

--- Ursprüngliche Nachricht ---
Von: Xavier Noria <fxn@hashref.com>
An: ruby-talk@ruby-lang.org (ruby-talk ML)
Betreff: Re: Zero is true, but it isn't
Datum: Thu, 20 Apr 2006 16:26:09 +0900

On Apr 20, 2006, at 1:51, John Johnson wrote:

I was wondering today, so I tried this:

puts "It's true" if 0

Which prints "It's true", meaning 0 is not false. (This should
surprise C/C++/etc. people).

So that means
puts "It's equal" if 0 == true

You are seeing a particular case of the fact that the boolean
interpretation an object may be different from the object value
itself. And == is comparing object values, not boolean
interpretations. Then the result of == is interpreted in boolean
context, but by then 0 was seen as an integer already, which is
certainly different from the object true.

To make it apparent take "foo". The string "foo" is true in boolean
context, but it won't surprise you to realise that "foo" == true does
not hold.

-- fxn

---
Help everyone. If you can't do that, then at least be nice.

Sorry if this is offensive, but since text doesn't really transmit tone of voice, are you being sarcastic? I wasn't seriously suggesting changing ruby in this manner, it was just sort of "this seems to jive with the other uses of #=== for the cases where the lhs side of #=== represents a set of values". +true+ conceivably represents the set of "true" values.

···

On Apr 20, 2006, at 3:32 PM, Robert Dober wrote:

You saved my day, I was really disappointed when I found that this code was
missing from ruby

[snip code]

shall we make a CR or for Ruby2?

e.g.

case x
   when true
      ...
    else
      ...
end

Of course anyone would use an if statement in this situation, but it
is kind of conceptually clean and sort of matches up with Range#===,
Regexp#===, etc.

Completely agree and if anyone uses an if statement why should we!!!!!

But I guess it is up to everyone to "fix" ruby for his own needs.

Cheers
Robert

Perhaps 0 in this context is SUCCESS, and anything else is an error?

···

On 20-Apr-2006, at 08:05, Austin Ziegler wrote:

Most common is 0 := false, 1 := true as you already know.
I think in Visual Basic it is 0 := false, -1 := true
Also possible 0 := false, not 0 := true

And the argument against 0 being false is shell scripts, where 0 is true.

---
Help everyone. If you can't do that, then at least be nice.

Sorry if this is offensive, but since text doesn't really transmit
tone of voice, are you being sarcastic?

That is why I am never sarcastic unless with people who know me, see how
lucky U R.

I wasn't seriously suggesting

changing ruby in this manner,

that is too bad, I thought you were :frowning:

it was just sort of "this seems to jive

with the other uses of #=== for the cases where the lhs side of #===
represents a set of values". +true+ conceivably represents the set of
"true" values.

The case idiom is so widespread look at it again
case value
    when something,
now something can meaningful be an instance of
Range, Regexp, Class, and many more
it cannot be an instance of TrueClass, FalseClass or NilClass.
Seems somehow unorthogonal, and you put it vert clearly and nicely, well I
thaught.

With all due respect to Matz, having a TrueClass and a FalsClass with a
single instance each (true and false for that matter) and them being not
related whatsoever more than any other two objects * this point is often
overlooked * seems confusing at least.
Is there a good reason for it?
The design of a Doubleton class Boolean having true and false as values
seems so much preferable.
Seems just odd to me.

Well as a matter of fact we are OT.
The topic was why is 0 not treated as false when in such context.
I like it, especially the
!!"" == true thing is very useful.
Maybe the !!0 == true thing is less useful (BTW that is how I should have
defined the #=== above ;).
So I am quite serious about that and

- I did not take any offence.

It is completely normal telling me "hey buddy you misunderstood what I
said", and moreover I am used to it.

Cheers
Robert

···

On 4/21/06, Logan Capaldo <logancapaldo@gmail.com> wrote:

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein