On Sat, Feb 4, 2012 at 8:17 AM, rjf <fate...@gmail.com> wrote:
>
> On Feb 2, 1:16 pm, Julien Puydt <julien.pu...@laposte.net> wrote:
>> Le 02/02/2012 23:22, Jonathan Bober a crit :
>>
>> > Can you think of a reason that the answer should change? Does maxima use
>> > less that 53 bits of precision ever?
>>
>> Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more
>> than the 15,95.. that fit in 53 binary digits.
One doesn't care about decimal digits, only binary digits. The fact
that this change is being pushed by someone who doesn't understand
this distinction is worrisome.
sage: s = (10^17).binary(); s
'101100011010001010111100001011101100010100000000000000000'
sage: len(s.strip('0'))
40
> Maxima uses the floating point in the underlying lisp implementation
> unless
> you specify bigfloats, in which case the floating point precision can
> be
> set to fewer bits as well as more bits.
Sage uses "bigfloats" (via MPFR) by default, defaulting to the
underlying machine implementation when explicitly requested.
> In my casual testing of MPFR, I found that either the claims were
> exaggerated,
> or maybe I was printing one or more digits than the binary
> representation provided.
Have you submitted a bug report? They're very careful about this kind
of thing, and if they're ever off by even 0.5ulp I'm sure they want to
know. Of course, as you mention, such accuracy comes with a
(performance) price.
>> In any case, let me repeat : three of the four failing numerical tests
>> pass if I add a relative tolerance of 1e-15... the only remaining one is
>> the computation of $\Gamma(10)$, where the relative error is
>> 1.2832...e-15, for which I don't know if it's acceptable or not, but
>> doesn't look that crazy.
>
> I think that's unacceptable.
While not as bad as cos(0.0) != 1.0, or violating monotonicity, it's
still pretty bad.
Note that what is broken[1] here is ARM's libc, if one types
"gamma(6.0)" one gets "120.000000000000" on all systems. It's a
question about gamma(float(6.0)) which is explicitly requesting the
(presumably faster but potentially less accurate) system
implementation. The question is should we
1) Weaken this doctest to support this broken platform.
2) Provide a workaround for this platform (e.g. using gsl or similar)
to avoid the broken implementation of gamma.
3) Mark this test as broken (not tested?) on ARM, and ARM only.
I think options 2 & 3 are far superior to 1.
- Robert
[1] By "broken" here I mean significantly worse than any other libc
we've run into yet, producing an aesthetically as well as numerically
poor answer, thereby defying expectations (as set by all other
platforms) of what the accuracy of this function should be. As there's
no proper specification to adhere to or violate, this seems the best
we can do.
--
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
