Forum: Ruby Why is 0x7FFFFFFF Bignum and not Fixnum ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3124abca01505075e10b81250eaee619?d=identicon&s=25 Mr Magpie (magpie)
on 2007-04-30 06:04
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 :

>> 0x3FFFFFFF.class
=> Fixnum
>> 0x3FFFFFFF.size
=> 4
As expected, this comfortably fits into 32 bits, but so should this :

>> 0x7FFFFFFF.class
=> Bignum
>> 0x7FFFFFFF.size
=> 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
B8cfd5ec0f88bf5b5f2eedda7d1a0746?d=identicon&s=25 unknown (Guest)
on 2007-04-30 06:09
(Received via mailing list)
In message <d1522f1fde212135fae0bea4fd1142d1@ruby-forum.com>, Mr Magpie
writes:
>>> 0x3FFFFFFF.class
>=> Fixnum
>>> 0x3FFFFFFF.size
>=> 4
>As expected, this comfortably fits into 32 bits, but so should this :
>
>>> 0x7FFFFFFF.class
>=> Bignum
>>> 0x7FFFFFFF.size
>=> 4

>1) Why has it gone to Bignum ? it shouldn't do this until 0x80000000.

Because 0x40000000 is either the sign bit or the magic flag.  I don't
know
how Ruby does that part, but that's what I'd expect.  There's no
"unsigned" types here.

-s
3124abca01505075e10b81250eaee619?d=identicon&s=25 Mr Magpie (magpie)
on 2007-04-30 06:25
> 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 ?
B8cfd5ec0f88bf5b5f2eedda7d1a0746?d=identicon&s=25 unknown (Guest)
on 2007-04-30 06:31
(Received via mailing list)
In message <b6597fbb7656f667941d80d0f00bfd63@ruby-forum.com>, Mr Magpie
writes:
>> 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 ?

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

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

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.

-s
3124abca01505075e10b81250eaee619?d=identicon&s=25 Mr Magpie (magpie)
on 2007-04-30 07:15
unknown wrote:
> In message <b6597fbb7656f667941d80d0f00bfd63@ruby-forum.com>, Mr Magpie
> writes:
>>> 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 ?
>
> 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...
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2007-04-30 08:46
(Received via mailing list)
From: "Mr Magpie" <gazmcgheesubs@yahoo.com.au>
>> range, and Ruby seems to have no unsigned types.
>>
>
> Oh really, thats kinda sad  - the abstractions are getting in the way...

I think I've missed unsigned ints in ruby about as often as I've ever
missed unsigned floats.  ;)

If you really need fast 32-bit unsigned int manipulation, possibly
RubyInline
might be of use?

http://www.zenspider.com/ZSS/Products/RubyInline/


HTH,

Bill
97550977337c9f0a0e1a9553e55bfaa0?d=identicon&s=25 Jano Svitok (Guest)
on 2007-04-30 15:59
(Received via mailing list)
On 4/30/07, Mr Magpie <gazmcgheesubs@yahoo.com.au> wrote:
> > 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 ?

This is kind of "hack" / implementation detail:

this bit is a flag that distinguishes between immediate values and
full objects.
the number is either
- 31 bit signed fixnum
- nil
- true
- false
- symbol
- pointer/handle to VALUE object
For more details see
http://www.oreillynet.com/ruby/blog/2006/01/the_ru...
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 Gary Wright (Guest)
on 2007-04-30 18:42
(Received via mailing list)
On Apr 30, 2007, at 9:58 AM, Jano Svitok wrote:
> 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
97550977337c9f0a0e1a9553e55bfaa0?d=identicon&s=25 Jano Svitok (Guest)
on 2007-04-30 18:53
(Received via mailing list)
On 4/30/07, Gary Wright <gwtmp01@mac.com> wrote:
>
> 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.
3124abca01505075e10b81250eaee619?d=identicon&s=25 Mr Magpie (magpie)
on 2007-05-01 03:32
Thanks for the informative answers. I see the reasoning now.

Has anyone done performance comparisons of Fixnum and Bignum ?
This topic is locked and can not be replied to.