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

On Thu, 20 Apr 2006, John J. wrote:

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

David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” PDF now on sale! http://www.manning.com/black
Paper version coming in early May!

On Apr 20, 2006, at 1:51, John J. 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

\$ 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 …

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

puts “It’s equal” if 0 == 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 4/20/06, Peter E. [email protected] 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.

-austin

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

case x

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

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 4/20/06, Logan C. [email protected] wrote:

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.

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

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

On 20-Apr-2006, at 08:05, Austin Z. 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.

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

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

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 E. wrote:

An: [email protected] (ruby-talk ML)

surprise C/C++/etc. people).

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.

On 4/21/06, Logan C. [email protected] wrote:

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

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

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.