Why is 0x7FFFFFFF Bignum and not Fixnum ?

M

Mr Magpie

According to the Pickaxe book :
"A Fixnum holds Integer values that can be represented in a native
machine word (minus 1 bit). If any operation on a Fixnum exceeds this
range, the value is automatically converted to a Bignum."

In IRB :
=> 4
As expected, this comfortably fits into 32 bits, but so should this :
=> 4

1) Why has it gone to Bignum ? it shouldn't do this until 0x80000000.
2) Interestingly, BigNum has recognised it fits into 32 bits, but it was
upsized anyway !

I'm trying to do some performance critical bit manipulations (without
leaving ruby) and this means I'll be using BigNum unnecessarily.

Regards

Magpie
 
M

Mr Magpie

Because 0x40000000 is either the sign bit or the magic flag.

0x80000000 would be the sign bit. What is this "magic flag" that seems
to be occupying 0x40000000 ?
 
M

Mr Magpie

unknown said:
Remember how it said you get "32 bits, minus one"?

What that means is you have a total of 31 bits available for values.

Oh, right!
So. The largest 31-bit number is 0x7FFF,FFFF. But wait! What about
negative numbers? How do we represent those? If we are using a 31-bit
representation, then the topmost of *those 31 bits* must be the sign
bit, so the highest number is 0x3FFF,FFFF -- because 0x7FFF,FFFF is
negative.

Unless something else similar is being done; I never read the source. I
just know that, if you have 31 bits available for positive and negative
numbers, you can't represent 0x7FFF,FFFF as a positive number in that
range, and Ruby seems to have no unsigned types.

Oh really, thats kinda sad - the abstractions are getting in the way...
 
G

Gary Wright

This is kind of "hack" / implementation detail:

this bit is a flag that distinguishes between immediate values and
full objects.

This is another of my attempts to kill the 'immediate value' meme
in Ruby. Feel free to ignore.


I think Ruby's semantics are clearer if you consider that the only
'values' in the language are references. These values reference
objects but the objects themselves are not manipulated as values
by the language.

Some references indicate implicit objects (nil, false, true,
fixnums, and symbols) and some references indicate explicit objects
(everything else). This differentiation is mostly an
implementation detail.

This point of view makes assignment and parameter passing semantics
consistent regardless of what objects are being referenced.


Gary Wright
 
J

Jano Svitok

This is another of my attempts to kill the 'immediate value' meme
in Ruby. Feel free to ignore.


I think Ruby's semantics are clearer if you consider that the only
'values' in the language are references. These values reference
objects but the objects themselves are not manipulated as values
by the language.

Some references indicate implicit objects (nil, false, true,
fixnums, and symbols) and some references indicate explicit objects
(everything else). This differentiation is mostly an
implementation detail.

This point of view makes assignment and parameter passing semantics
consistent regardless of what objects are being referenced.


Gary Wright

Thanks, your explanation seems clearer.
 
M

Mr Magpie

Thanks for the informative answers. I see the reasoning now.

Has anyone done performance comparisons of Fixnum and Bignum ?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top