Blog

Floats are mutable objects, apparently?

UPDATE[4/7]: Floats are NOT mutable apparently. Thank you to Robert for clarifying what is actually happening below. Read his comment below. 

——————————

I just discovered another interesting tidbit while working with floats and modulos. 

First this: 

1.9.3p125 :001 > 3 % 0.05
 => 0.049999999999999836 

I haven’t figured out the reason for why this happens (I would have assumed 3 % 0.05 returns 0), but it’s something about how math is done in the computer.

Now check this out:

1.9.3p125 :002 > a = 3 % 0.05
 => 0.049999999999999836 
1.9.3p125 :003 > a.object_id
 => 5271720 

Makes sense. But wait! Let’s add on another bit:

1.9.3p125 :002 > a = 3 % 0.05
 => 0.049999999999999836 
1.9.3p125 :003 > a.object_id
 => 5271720 
1.9.3p125 :004 > b = 3 % 0.05
 => 0.049999999999999836 
1.9.3p125 :005 > b.object_id
 => 5304200 

To drive the point home:

1.9.3p125 :006 > a == b
 => true 
1.9.3p125 :007 > a.object_id == b.object_id
 => false 

This can only mean that floats are mutable. Here’s more proof in case you were thinking (like I was) that the modulo is returning something different each time and truncating the end from the display.

1.9.3p125 :008 > a = 0.999
nbsp;=> 0.999 
1.9.3p125 :009 > b = 0.999
 => 0.999 
1.9.3p125 :010 > a == b
 => true 
1.9.3p125 :011 > a.object_id == b.object_id
 => false 

Just in case you were wondering, this is different from how integers (and symbols) work:

1.9.3p125 :012 > c = 1
 => 1 
1.9.3p125 :013 > d = 1
 => 1 
1.9.3p125 :014 > c == d
 => true 
1.9.3p125 :015 > c.object_id == d.object_id
 => true

Maybe I should have learned this by reading up on it somewhere, but chancing across it was ultimately more interesting.

“Called id for nil, which would mistakenly be 4”

I’ve gotten this error so many times while building Rails applications and it didn’t make any sense. It usually appeared when I was trying to call Some_Object.id and the object wasn’t assigned correctly, so in essence I was calling .id on nil. But I had no idea why that would “mistakenly be 4”.

Thanks to Tim, I finally unraveled the mystery. 

The first important thing to know is that in Ruby, everything is an object. No really, everything. Even the class “Object” which contains everything inside it is an object. Think of it like an index of keywords, and each one has an object_id. The object_id for the Object class is 18703980.

This index goes like this:

• All odd indexes are integers. E.g. 0.object_id = 1, 1.object_id = 3, 2.object_id = 5, etc. 
• All immutable objects always have the same object_id (Classes, Symbols, Fixnum, etc)
• Mutable objects like strings DON’T have the same object id. E.g. “apple”.object_id != “apple”.object_id. 

I’m sure there are more rules, but these are the ones I’ve discovered so far. 

Getting back to nil

There’s no particular reason for this that I can see, but Ruby was designed so that the first object in this index is false. So, false.object_id = 0. The next non-integer object is true. And finally, the third non-integer object is nil. 

1.9.3p125 :050 > false.object_id
 => 0 
1.9.3p125 :051 > true.object_id
 => 2 
1.9.3p125 :052 > nil.object_id
 => 4 

My next question was obviously, how do I find what object is assigned to a given object_id. A quick search revealed that

ObjectSpace._id2ref(object_id)

will return the object associated with the given parameter. 

Oh and, by the way. the ObjectSpace class also has an object_id. :)

Method names and variables are the same thing

I discovered something interesting today. Kudos to Craig for leading me to this discovery. 

Method names and variables are really the same thing. Both point to some object that is being returned. This makes more sense now that I know it, but we proved it in IRB below. 

We first create a class Person that is initialized with a name property and make the name accessible outside.

1.9.3p125 :067 >   class Person
1.9.3p125 :068?>   attr_accessor :name
1.9.3p125 :069?>   def initialize(name)
1.9.3p125 :070?>     @name = name
1.9.3p125 :071?>     end
1.9.3p125 :072?>   end

We define a method that returns a string “Bob”

1.9.3p125 :073 > def get_name
1.9.3p125 :074?>   “Bob”
1.9.3p125 :075?>   end

And then we initialize an instance of the Person class with the get_name method.

1.9.3p125 :076 > bob = Person.new(get_name)
 => #<Person:0x00000002ad78a0 @name=”Bob”> 

When we call the name property of the instance, we see that it doesn’t return “get_name” which is what we initialized the class with. We get the value that the method returned. 

1.9.3p125 :077 > bob.name
 => “Bob” 

Taking this one step further, suppose we update our get_name method

1.9.3p125 :078 > def get_name
1.9.3p125 :079?>   “Sally”
1.9.3p125 :080?>   end

Now, the name property of bob, our instance of the Person class, remains “Bob” because the method wasn’t called again. It returned “Bob” only once when the instance was initialized.

1.9.3p125 :081 > bob.name
 => “Bob” 

This nuance may or may not seem important until you think about storing these properties in a database. For example, imagine a 3rd party company that handles customer service for B2Cs. When the 3rd party company hires a new employee, they ask him or her to fill out a form indicating their gender. Based on the gender, they assign a random pseudonym to that employee for all their interactions with customers on the phone or email, etc. One way to assign and store these pseudonyms would be to create two different tables for male and female employees and instantiate records with “Bob” or “Sally” names. There’s no reason to have two different tables other than that, as far as I can tell. 

Or, you could have one class and instead of instantiating records with a string, instantiate with a method that assigns “Bob” or “Sally” based on the gender from the input form. The method could also provide extra flexibility and have a set of names instead of having every male employee being assigned “Bob” and every female employee “Sally.”

If I made a mistake in my reasoning above, or if you can add to this, comment below!