OpenEuphoria

Re: atom = problem?

• Posted by CChris <christian.cuvier at agric?ltur?.gouv.fr> Apr 29, 2008
• 818 views

CChris wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > CChris wrote:
> > > 
> > > You shouldn't use string conversion to compare atoms, because of the
> > > limited
> > > precision of floating point numbers in hardware.
> > > Use atom_to_float64() in machine.e instead to obtain a sequence of 8
> > > bytes,
> > > which is the internal representation of the number. Then comparing these
> > > sequences
> > > of equal length becomes unambiguous.
> > > 
> > 
> > I'm not following. Here's what I did:
> > 
> > }}}
<eucode>
> > test_equal("atan2() #1",
> > atom_to_float64(1.283713957607754085898932316922582685947418212890625),
> >     atom_to_float64(atan2(10.5, 3.1)))
> > </eucode>
{{{

> > 
> > Here's what I get:
> > 
> >   failed: atan2() #1. expected: {41,129,149,165,23,138,244,63} but got:
> >   {42,129,149,165,23,138,244,63}
> > 
> > 
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
> 
> Ok, I get it better now.
> The problem may lie in how the interpreter parses the string
> "1.283713957607754085898932316922582685947418212890625".
> It won't check all digits. 
> I'll check tonight at home using Mathematica, and will tell you more precisely
> where the error is.
> Oh, by the way, do you get the same issue when using atan2(105,31) instead?
> Because there is some imprecision in 3.1, as you know (same old "penny
> issue").
> 
> CChris

In Mathematica 5.5:
* N[ArTan[105/31],100] results in a string of the expected length, which the one
you parse is a subset of;
* N[ArcTan[10.5,3.1],100] outputs only a few decmals.

This seems to confirm my guess according to which it is the "3.1" in your test
which causes an issue, because 3.1 is not a finite sum of large enough powers of
2. Those sums are the only numbers the hardware can handle loss-less.

CChris