Forum: Ruby Why was the object_id for true and nil changed in ruby2.0?

irb(main):001:0> true.object_id
=> 20
irb(main):002:0> false.object_id
=> 0
irb(main):003:0> nil.object_id
=> 8

The values for true and nil were respectively 2, 4 in 1.9.3 and 1.8.7,
but have been changed to 20, 8 in ruby2.0.0 - even though the id of
false remains the same i.e. 0 and the ids for Fixnum maintains the same
old 2n+1 pattern.

What's the reason behind this object_id change?

Why was this change made? How is this going to help developers?

The full question can be seen here:
http://stackoverflow.com/questions/15506763/why-wa...

thanks!

your question was already answered at stackoverflow:

>> Seems to be something to do with “flonums” – a technique for speeding up 
floating point calculations on 64-bit: 
github.com/ruby/ruby/blob/v2_0_0_0/include/ruby/ruby.h#L383-431 and 
ruby-forum.com/topic/4404164.

Hans Mackowiak wrote in post #1102392:
> your question was already answered at stackoverflow:
>
>>> Seems to be something to do with “flonums” – a technique for speeding up
> floating point calculations on 64-bit:
> github.com/ruby/ruby/blob/v2_0_0_0/include/ruby/ruby.h#L383-431 and
> ruby-forum.com/topic/4404164.

I have tried to read it, but the presentations given in that link are 
written in Japanese, and I couldn't understand what Flonums are why they 
are implemented.

Know any place where I can read them in English to understand why it was 
changed?

hm the forumtopic i linked was in english ...

hm okay, Flonums may be not the reason because they are only in 2.1dev

  a = 1.1 + 1.2
  b = 1.1 + 1.2
  p(a.object_id == b.object_id)

this shows true on 2.1, its false on 2.0p0

ruby-forum.com/topic/4404164  specifically states why it was changed. 
Its a speed thing.



> Hans Mackowiak <mailto:lists@ruby-forum.com>
> March 20, 2013 2:03 AM
> floating point calculations on 64-bit:
> github.com/ruby/ruby/blob/v2_0_0_0/include/ruby/ruby.h#L383-431 and
> ruby-forum.com/topic/4404164.
>

--
D. Deryl Downey

  "The bug which you would fright me with I seek" - William Shakespeare
- The Winter's Tale, Act III, Scene II - A court of Justice.

On 20 March 2013 14:27, D. Deryl Downey <me@daviddwdowney.com> wrote:
>
> ruby-forum.com/topic/4404164 specifically states why it was changed. Its a speed 
thing.
>

I'm interested (as is Hans, I think) in understanding the specifics of
the implementation and _why_ this leads to better performance. Looks
like someone would have to translate the Japanese, though.

Hans Mackowiak wrote in post #1102451:
> hm okay, Flonums may be not the reason because they are only in 2.1dev
>
>   a = 1.1 + 1.2
>   b = 1.1 + 1.2
>   p(a.object_id == b.object_id)
>
> this shows true on 2.1, its false on 2.0p0

This shows true in my system too, but my ruby -v is ruby 2.0.0p0 
(2013-02-24 revision 39474) [x86_64-linux], not 2.1.

On Wed, 20 Mar 2013 17:22:57 +0100, Bharadwaj Srigiriraju 
<lists@ruby-forum.com> wrote:

> (2013-02-24 revision 39474) [x86_64-linux], not 2.1.
This only should be true on 64bit Ruby 2.0.

Bartosz Dziewoński wrote in post #1102469:
> On Wed, 20 Mar 2013 17:22:57 +0100, Bharadwaj Srigiriraju
> <lists@ruby-forum.com> wrote:
>
>> (2013-02-24 revision 39474) [x86_64-linux], not 2.1.
> This only should be true on 64bit Ruby 2.0.

Yes.

On 32 bit systems the object_id didn't change at all.

Well, there is a new answer on Stack Overflow.

Gentlemen over here might want to take a look: 
http://stackoverflow.com/a/15526818/1076075

Seems legit... but I am not sure how can something like this lead to 
better perfomance? Any comments?

Because immediate values have no overhead. It takes memory and cpu 
cycles
to create an object instance; it takes no (extra) memory if the value is
stored in the reference (ie the object id _is_ the value, albeit 
slightly
modified), and far fewer cycles to shift and OR some bits.

Sent from my phone, so excuse the typos.