1. Big Integer Atoms
- Posted by "Igor Kachan" <kinz at peterlink.ru> Jul 11, 2004
- 589 views
Hi, dear Euphorians, The EU manual says: "... Those declared with type integer must be atoms with integer values from -1073741824 to +1073741823 inclusive. You can perform exact calculations on larger integer values, up to about 15 decimal digits, but declare them as atom, rather than integer ..." This "up to about 15 decimal digits" seems to be not enough concrete thing for some cases. Couldn't someone tell me about more precise bounds of these "larger integer values"? Thanks! Regards, Igor Kachan kinz at peterlink.ru
2. Re: Big Integer Atoms
- Posted by Robert Craig <rds at RapidEuphoria.com> Jul 11, 2004
- 569 views
Igor Kachan wrote: > > Hi, dear Euphorians, > > The EU manual says: > > "... Those declared with type integer must be atoms > with integer values from -1073741824 to +1073741823 > inclusive. > You can perform exact calculations on larger integer > values, up to about 15 decimal digits, but declare > them as atom, rather than integer ..." > > This "up to about 15 decimal digits" seems to be not > enough concrete thing for some cases. > > Couldn't someone tell me about more precise > bounds of these "larger integer values"? (As I recall) with IEEE floating-point, you have 1 bit for the +/- sign, 52 bits for the mantissa, and 11 bits for the exponent. When storing integers in f.p. form, at some point you are going to use up all 52 bits in the mantissa, and you won't be able to store the integers exactly anymore, or get exact results from your calculations. I guess you could look for the point where: x + 1 = x i.e. you don't have the resolution to distinguish between one huge integer and the next. There's roughly 3 decimal digits per 10 binary digits, so I guess that would be around 52 * 3 / 10 = 15 decimal digits, roughly. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: Big Integer Atoms
- Posted by "Kat" <gertie at visionsix.com> Jul 11, 2004
- 582 views
On 11 Jul 2004, at 14:31, Robert Craig wrote: > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > Igor Kachan wrote: > > > > Hi, dear Euphorians, > > > > The EU manual says: > > > > "... Those declared with type integer must be atoms > > with integer values from -1073741824 to +1073741823 > > inclusive. > > You can perform exact calculations on larger integer > > values, up to about 15 decimal digits, but declare > > them as atom, rather than integer ..." > > > > This "up to about 15 decimal digits" seems to be not > > enough concrete thing for some cases. > > > > Couldn't someone tell me about more precise > > bounds of these "larger integer values"? > > (As I recall) with IEEE floating-point, you have 1 bit > for the +/- sign, 52 bits for the mantissa, and 11 bits > for the exponent. > > When storing integers in f.p. form, > at some point you are going to use up all 52 bits in > the mantissa, and you won't be able to store the integers > exactly anymore, or get exact results from your calculations. > I guess you could look for the point where: > x + 1 = x > i.e. you don't have the resolution to distinguish between > one huge integer and the next. There's roughly 3 decimal > digits per 10 binary digits, so I guess that would be > around 52 * 3 / 10 = 15 decimal digits, roughly. I am guessing you cannot do something like allocate x number of 8bit memory locations, repeat(poke rand(256) into them) x times, and then point an Eu atom to it without warning? At least, that's what i'd do in turbo pascal... i guess in Eu, to avoid the overflow, you'd use object or even sequence? Kat
4. Re: Big Integer Atoms
- Posted by Robert Craig <rds at RapidEuphoria.com> Jul 11, 2004
- 579 views
Kat wrote: > On 11 Jul 2004, at 14:31, Robert Craig wrote: > > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > > > Igor Kachan wrote: > > > > > > Hi, dear Euphorians, > > > > > > The EU manual says: > > > > > > "... Those declared with type integer must be atoms > > > with integer values from -1073741824 to +1073741823 > > > inclusive. > > > You can perform exact calculations on larger integer > > > values, up to about 15 decimal digits, but declare > > > them as atom, rather than integer ..." > > > > > > This "up to about 15 decimal digits" seems to be not > > > enough concrete thing for some cases. > > > > > > Couldn't someone tell me about more precise > > > bounds of these "larger integer values"? > > > > (As I recall) with IEEE floating-point, you have 1 bit > > for the +/- sign, 52 bits for the mantissa, and 11 bits > > for the exponent. > > > > When storing integers in f.p. form, > > at some point you are going to use up all 52 bits in > > the mantissa, and you won't be able to store the integers > > exactly anymore, or get exact results from your calculations. > > I guess you could look for the point where: > > x + 1 = x > > i.e. you don't have the resolution to distinguish between > > one huge integer and the next. There's roughly 3 decimal > > digits per 10 binary digits, so I guess that would be > > around 52 * 3 / 10 = 15 decimal digits, roughly. > > I am guessing you cannot do something like allocate x number of 8bit > memory locations, repeat(poke rand(256) into them) x times, and then point > an Eu atom to it without warning? At least, that's what i'd do in turbo > pascal... i guess in Eu, to avoid the overflow, you'd use object or even > sequence? Euphoria won't do anything like that automatically. For really huge integers you can use one of the "big integer" math packages in the Archive. They let you store big integers in long sequences of digits. All calculations use Euphoria subroutines rather than f.p. hardware so they're pretty slow. e.g. a "big integer" system could store one base 10 digit per sequence element, or, to save memory it might store (say) 9 digits per sequence element, and do all calculations in base one billion, instead of base 10. e.g. store 123456789555555555 as: s[1] = 123456789 s[2] = 555555555 and remember that s[1] is one billion times more significant than s[2]. The usual math operations, add/sub/mul/div can be implemented just like how you do them "on paper" in base 10. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
5. Re: Big Integer Atoms
- Posted by "Carl R. White" <euphoria at cyreksoft.yorks.com> Jul 12, 2004
- 597 views
Igor Kachan wrote: > > Hi, dear Euphorians, > > The EU manual says: > > "... Those declared with type integer must be atoms > with integer values from -1073741824 to +1073741823 > inclusive. > You can perform exact calculations on larger integer > values, up to about 15 decimal digits, but declare > them as atom, rather than integer ..." > > This "up to about 15 decimal digits" seems to be not > enough concrete thing for some cases. > > Couldn't someone tell me about more precise > bounds of these "larger integer values"? The IEEE 64-bit floating point number, known to us as the Euphoria atom, is made up from one sign bit, ten exponent bits, and 53 mantissa bits. This means (IIRC) that you can accurately represent all the integers from -power(2^53) to +power(2,53) (-9007199254740992 to 9007199254740992). The fact that power(2,53) is representable is a bit of a fluke as the last bit of its binary representation isn't stored (54 bits are needed, yet it is stored in 53). You can prove it with this little bit of code:
atom x x = power(2,53)-100 while x != x + 1 do ? x x += 1 end while
It looks like it loops forever (a number is never equal to one more than itself), but it actually stops at the largest representable integer. -- [ Carl R White == aka () = The Domain of Cyrek = ] [ Cyrek the Illogical /\ www.cyreksoft.yorks.com ]
6. Re: Big Integer Atoms
- Posted by "Igor Kachan" <kinz at peterlink.ru> Jul 12, 2004
- 582 views
Robert Craig wrote: ----- > From: Robert Craig <guest at RapidEuphoria.com> > To: EUforum at topica.com > Subject: Re: Big Integer Atoms > Sent: 12 jul 2004 y. 1:31 > > posted by: Robert Craig <rds at RapidEuphoria.com> > > Igor Kachan wrote: > > > > Hi, dear Euphorians, > > > > The EU manual says: > > > > "... Those declared with type integer must be atoms > > with integer values from -1073741824 to +1073741823 > > inclusive. > > You can perform exact calculations on larger integer > > values, up to about 15 decimal digits, but declare > > them as atom, rather than integer ..." > > > > This "up to about 15 decimal digits" seems to be not > > enough concrete thing for some cases. > > > > Couldn't someone tell me about more precise > > bounds of these "larger integer values"? > > (As I recall) with IEEE floating-point, you have 1 bit > for the +/- sign, 52 bits for the mantissa, and 11 bits > for the exponent. > > When storing integers in f.p. form, > at some point you are going to use up all 52 bits in > the mantissa, and you won't be able to store the integers > exactly anymore, or get exact results from your > calculations. > I guess you could look for the point where: > x + 1 = x > i.e. you don't have the resolution to distinguish between > one huge integer and the next. There's roughly 3 decimal > digits per 10 binary digits, so I guess that would be > around 52 * 3 / 10 = 15 decimal digits, roughly. Thanks, I'll try to get the experimental bounds by this method, useing printf(), floor() etc. Regards, Igor Kachan kinz at peterlink.ru
7. Re: Big Integer Atoms
- Posted by "Igor Kachan" <kinz at peterlink.ru> Jul 12, 2004
- 541 views
Carl White wrote: ------ > From: Carl W. <euphoria at cyreksoft.yorks.com> > To: EUforum at topica.com > Subject: Re: Big Integer Atoms > Sent: 12 jul 2004 y. 12:20 > > > Igor Kachan wrote: > > > > Hi, dear Euphorians, > > > > The EU manual says: > > > > "... Those declared with type integer must be atoms > > with integer values from -1073741824 to +1073741823 > > inclusive. > > You can perform exact calculations on larger integer > > values, up to about 15 decimal digits, but declare > > them as atom, rather than integer ..." > > > > This "up to about 15 decimal digits" seems to be not > > enough concrete thing for some cases. > > > > Couldn't someone tell me about more precise > > bounds of these "larger integer values"? > > The IEEE 64-bit floating point number, known to us as the Euphoria atom, > is made up from one sign bit, ten exponent bits, and 53 mantissa bits. > > This means (IIRC) that you can accurately represent all the integers > from -power(2^53) to +power(2,53) (-9007199254740992 to > 9007199254740992). The fact that power(2,53) is representable is a bit > of a fluke as the last bit of its binary representation isn't stored (54 > bits are needed, yet it is stored in 53). > > You can prove it with this little bit of code: > }}} <eucode> > atom x > x = power(2,53)-100 > while x != x + 1 do > ? x > x += 1 > end while > </eucode> {{{ > > It looks like it loops forever (a number is never equal to one more than > itself), but it actually stops at the largest representable integer. Thanks Carl! I think, I'll catch this floating animal now. Good Luck! Regards, Igor Kachan kinz at peterlink.ru