On Thu, Feb 2, 2012 at 11:23 AM, Julien Puydt <julien.pu...@laposte.net>wrote:
>
> Let us consider :
> #include <math.h>
> #include <stdio.h>
>
> int
> main ()
> {
> long double x;
> x=6.0;
> printf ("%.20Lf\n", tgammal(x));
> x=10.0;
> printf ("%.20Lf\n", tgammal(x));
> return 0;
> }
>
> On an x86_64 box, I get :
> $ ./test
> 119.99999999999999998612
> 362880.00000000000022737368
>
> and on the ARM box, I get:
> $ ./test
> 119.99999999999997157829
> 362880.00000000046566128731
>
>
Interesting. You can also replicate these results (double and long double
using sage):
sage: exp(RealField(64)(log(120))).str(truncate=False)
'119.999999999999999986'
sage: exp(RealField(53)(log(120))).str(truncate=False)
'119.99999999999997'
Anyway, the first value doesn't fit in a double, so when it gets converted
to a double it has to be rounded. It turns out that 120.0 is the closest
double to 119.999999999999999986, so that is why sage ends up getting the
answer exactly correct:
sage: RR(exp(RealField(64)(log(120)))).str(truncate=False)
'120.00000000000000'
> (The maxima conversion is a different issue. There the result _is_
>> wrong. 1.7e17 is exact in double precision, and the conversion should
>> not change that.)
>>
>
> Well, that problem goes away with "# tol rel", hence the situation isn't
> that clear-cut.
>
Can you think of a reason that the answer should change? Does maxima use
less that 53 bits of precision ever?
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
