OpenEuphoria

Re: New proposal for math.e

• Posted by Jason Gade <jaygade at yahoo.c??> Aug 04, 2007
• 708 views

Pete Lomax wrote:
> 
> CChris wrote:
> > I'm contemplating a brute force attack against the backend code 
> 
> Hurrah! Go, tiger, go!
> 
> This is excellent news. Instead of wasting time trying to improve Eu, we can
> all spend the next five years trying to fix it. I can't wait.
> 
> Pete
Heh. Nice.


Juergen Luethje wrote:
> 
> Pete Lomax wrote:
> 
> > Juergen Luethje wrote:
> > (I am a bit allergic to machine_func(47 etc, but it is not life-threatening)
> 
> I also think it's better readable. float64_to_atom() would require
>    include machine.e
> I think that was the reason for not using it. But that include statement
> should not cause any problem, should it?

I think it's just for namespace reasons, or if you want to use safe.e instead of
machine.e. It shouldn't really be problem though.


> > If after that, PI/2 is not as accurate as it sh/could be, then something is
> > seriously wrong.
> 
> I created a short test, and division doesn't seem to cause any problem
> (here). The two differences that occur are between assigning a hard-coded
> value vs. assingnimg the corresponding function result. I don't know what
> that means.
> }}}
<eucode>
> global constant
>    E          = machine_func(47, {105,87,20,139,10,191,5,64}),     --
>    2.7182818284590452e0
>    PI         = machine_func(47, {24,45,68,84,251,33,9,64}),       --
>    3.1415926535897932e0
> 
>    LN2        = machine_func(47, {239,57,250,254,66,46,230,63}),   --
>    0.6931471805599453e0
>    LN10       = machine_func(47, {21,85,181,187,177,107,2,64}),    --
>    2.3025850929940456e0
>    SQRT2      = machine_func(47, {204,59,127,102,158,160,246,63}), --
>    1.4142135623730950e0
>    HALF_SQRT2 = machine_func(47, {204,59,127,102,158,160,230,63}), --
>    0.7071067811865475e0
>    HALF_PI    = machine_func(47, {24,45,68,84,251,33,249,63}),     --
>    1.5707963267948966e0
>    QUARTER_PI = machine_func(47, {24,45,68,84,251,33,233,63}),     --
>    0.7853981633974483e0
>    TWO_PI     = machine_func(47, {24,45,68,84,251,33,25,64}),      --
>    6.2831853071795864e0
> 
>    LN2_test        = log(2),
>    LN10_test       = log(10),
>    SQRT2_test      = sqrt(2),
>    HALF_SQRT2_test = SQRT2/2,
>    HALF_PI_test    = PI/2, 
>    QUARTER_PI_test = PI/4, 
>    TWO_PI_test     = PI*2 
> 
> 
> ? compare( LN2       , LN2_test )
> ? compare( LN10      , LN10_test )          -- LN10_test  is bigger!
> ? compare( SQRT2     , SQRT2_test )         -- SQRT2_test is bigger!
> ? compare( HALF_SQRT2, HALF_SQRT2_test )
> ? compare( HALF_PI   , HALF_PI_test ) 
> ? compare( QUARTER_PI, QUARTER_PI_test ) 
> ? compare( TWO_PI    , TWO_PI_test ) 
> </eucode>
{{{

> Tested with EXW.EXE 3.0.2.
> 
> Regards,
>    Juergen
Some precision will be lost after more than a few operations anyway. Just like
almost any other calculation.

Hmm. Should check it with C sometime soon.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.