1. Big Integer Atoms

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

new topic     » topic index » view message » categorize

2. Re: Big Integer Atoms

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: Big Integer Atoms

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: Big Integer Atoms

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: Big Integer Atoms

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 ]

new topic     » goto parent     » topic index » view message » categorize

6. Re: Big Integer Atoms

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: Big Integer Atoms

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu