OpenEuphoria

1. More atom precision (was: Re: File size limit)

• Posted by Jason Gade <jaygade at yaho?.co?> Jun 12, 2008
• 761 views

Fernando Bauer wrote:
> 
> Jason Gade wrote:
> > And atoms are unique integers up to
> > (2^52) - 1 so I don't know why you can't do full precision integer math on
> > them.
> 
> The maximum contiguous integer in Eu is:
>    2^53 = power(2,53) = 9,007,199,254,740,992
> 
> Demonstrations:
> 
> 1) By decimal representation:
> 
> 2^53-5= 9007199254740987  -- ok
> 2^53-4= 9007199254740988  -- ok
> 2^53-3= 9007199254740989  -- ok
> 2^53-2= 9007199254740990  -- ok
> 2^53-1= 9007199254740991  -- ok
> 2^53+0= 9007199254740992  -- ok
> 2^53+1= 9007199254740992  -- Problem: it's equal to 2^53
> 2^53+2= 9007199254740994
> 2^53+3= 9007199254740996
> 2^53+4= 9007199254740996
> 2^53+5= 9007199254740996
> 
> 2) IEEE754 double-precision (64 bits) bit values:
> Value =|s|--exponent-|--------------------fraction------------------------|
> 2^53-5= 0 10000110011 1111111111111111111111111111111111111111111111111011
> 2^53-4= 0 10000110011 1111111111111111111111111111111111111111111111111100
> 2^53-3= 0 10000110011 1111111111111111111111111111111111111111111111111101
> 2^53-2= 0 10000110011 1111111111111111111111111111111111111111111111111110
> 2^53-1= 0 10000110011 1111111111111111111111111111111111111111111111111111
> 2^53+0= 0 10000110100 0000000000000000000000000000000000000000000000000000
> 2^53+1= 0 10000110100 0000000000000000000000000000000000000000000000000000
> 2^53+2= 0 10000110100 0000000000000000000000000000000000000000000000000001
> 2^53+3= 0 10000110100 0000000000000000000000000000000000000000000000000010
> 2^53+4= 0 10000110100 0000000000000000000000000000000000000000000000000010
> 2^53+5= 0 10000110100 0000000000000000000000000000000000000000000000000010
> 
> 3)IEEE754 double-precision normalized numbers:
>   v = (-1)^s * 2^e * (1 + fraction * 2^-52)
>     = (-1)^s * (2^e + fraction * 2^(e-52))
> 
> Note that there is NO problem when v=2^52 (e=52):
>   v = (-1)^s * (2^52 + fraction)   where 0<=fraction<=2^52-1
> 
> Note that there are problems when 2^53<v<2^54 (e=53):
>   v = (-1)^s * (2^53 + fraction * 2)   where 0<=fraction<=2^52-1
> since fraction is an integer number, it's impossible to represent 2^53+1
> exactly.
> 
> 2^53-5= +2^52 * (1 + 4503599627370491 * 2^-52)
> 2^53-4= +2^52 * (1 + 4503599627370492 * 2^-52)
> 2^53-3= +2^52 * (1 + 4503599627370493 * 2^-52)
> 2^53-2= +2^52 * (1 + 4503599627370494 * 2^-52)
> 2^53-1= +2^52 * (1 + 4503599627370495 * 2^-52)
> 2^53+0= +2^53 * (1 +                0 * 2^-52)
> 2^53+1= +2^53 * (1 +                0 * 2^-52)
> 2^53+2= +2^53 * (1 +                1 * 2^-52)
> 2^53+3= +2^53 * (1 +                2 * 2^-52)
> 2^53+4= +2^53 * (1 +                2 * 2^-52)
> 2^53+5= +2^53 * (1 +                2 * 2^-52)
> 
> 4)By measuring integer distances:
> Look at this:
> <a
> href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=1&fromYear=D&toMonth=6&toYear=D&postedBy=Fernando&keywords=NextInteger">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=1&fromYear=D&toMonth=6&toYear=D&postedBy=Fernando&keywords=NextInteger</a>

<snip>

> Look at this line in function get_epsilon():
> }}}
<eucode>
>     if exp > 1023 then
> </eucode>
{{{

> I think it should be:
> }}}
<eucode>
>     if exp > -1023 then
> </eucode>
{{{

> 
> With that modification, the output is:
> 0.5
>  4503599627370494
>  4503599627370495
>  4503599627370496
>  4503599627370497
> 1
>  4503599627370495
>  4503599627370496
>  4503599627370497
>  4503599627370498
> 1
>  4503599627370496
>  4503599627370497
>  4503599627370498
>  4503599627370499
> 
> which shows that (2^52) and (2^52+1) are still contiguous.
> 
> [snipped]
> 
> Regards,
>   Fernando

Okay, I looked at the code again and I think that I got it right.

First let me say that the epsilon and exponent stuff was actually written by
Matt Lewis. I just "adopted" (stole) it.

What I realized reading the code, though, was that it wasn't a comparison to
-1023 that should be changed (which made little sense to me) but rather this:

if exp > 1023 then
	    -- normalized, so implicit 1 (53rd bit) in front
        epsilon = power(2, exp - 53)
    else
        -- denormalized, so no implicit 1 (no 53rd bit)
        epsilon = power(2, exp - 52)
    end if

The original code compared to 52 and 51 respectively. An off by one error. A
normalized number adds an implicit 53rd bit (and therefore an extra power of 2)
and a denormalized number only uses the 52 bits of the fraction to represent the
number.

I could be wrong, but that was my thought process, and it seems to be consistent
at the high end.

I haven't tested it at the small end.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

3. Re: More atom precision (was: Re: File size limit)

• Posted by Fernando Bauer <fmbauer at hotma?l.?om> Jun 12, 2008
• 718 views
• Last edited Jun 13, 2008

Jason Gade wrote:
> 
> Jason Gade wrote:
> > 
> > Okay, I looked at the code again and I think that I got it right.
> > 
> > First let me say that the epsilon and exponent stuff was actually written by
> > Matt Lewis. I just "adopted" (stole) it.
> > 
> > What I realized reading the code, though, was that it wasn't a comparison to
> > -1023 that should be changed (which made little sense to me) but rather
> > this:
> > 
> > }}}
<eucode>
> >     if exp > 1023 then
> > 	    -- normalized, so implicit 1 (53rd bit) in front
> >         epsilon = power(2, exp - 53)
> >     else
> >         -- denormalized, so no implicit 1 (no 53rd bit)
> >         epsilon = power(2, exp - 52)
> >     end if
> > </eucode>
{{{

> > 
> > The original code compared to 52 and 51 respectively. An off by one error. A
> > normalized number adds an implicit 53rd bit (and therefore an extra power of
> > 2) and a denormalized number only uses the 52 bits of the fraction to
> > represent
> > the number.
> > 
> > I could be wrong, but that was my thought process, and it seems to be
> > consistent
> > at the high end.
> > 
> > I haven't tested it at the small end.
> 
> Never mind -- I think I see comparing to -1023 more clearly and more correct.
> 
> Thanks again, my understanding of FP representation has increased.
> 

Thanks Jason for our chat about this subject. As you, I think my understanding
of Euphoria and FP representation have increased too.

Best Regards,
Fernando