#15921: work around Maxima fpprintprec bug and other ARM-specific problems
-------------------------------------+-------------------------------------
Reporter: dimpase | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: calculus | Resolution:
Keywords: Maxima, | Merged in:
fpprintprec, ARM | Reviewers: Peter Bruin
Authors: | Work issues:
Report Upstream: Reported | Commit:
upstream. Developers acknowledge | b8fea1cb11554aff202cd669342136d5a4ea084c
bug. | Stopgaps:
Branch: |
u/pbruin/15921-arm_fixes |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by pbruin):
Replying to [comment:36 vbraun]:
> What is the upstream status for the Maxima fpprintprec bug? If there is
a fix then we should just go with upstream instead of increasing our
tolerances imho. Its not cool of maxima to print too many digits.
I don't think a change in upstream will help us. Besides, I see printing
too many digits as a feature in this case, since printing 17 decimal
digits guarantees exact conversion of floats with 53 bits of precision.
What explains the difference between ARM and x86_64 in the cases of
interest for us is just floating point noise. There are only two Maxima-
related affected doctests. The first one is
{{{
sage: from sage.functions.bessel import _Bessel
sage: _Bessel(20,algorithm='maxima')(5.0)
27.70330052128944e-12 # ARM
27.703300521289436e-12 # x86_64
}}}
In this case, the number of digits does differ, but the correct answer is
2.770330052128941687...e-11, so the last 1-2 digits are wrong in both
cases.
Another issue here is that this example has two digits before the decimal
point, instead of one. This is apparently an ECL issue, since Maxima on
GCL or SBCL only prints one digit before the point.
The second relevant doctest is
{{{
elliptic_e(0.5, 0.1)
0.498011394498831 # ARM
0.498011394498832 # x86_64
}}}
Here the number of digits is the same, and the correct answer is
0.49801139449883153311546...
So I think for these two doctests we should just specify a tolerance.
> As for the eglibc issue, I'm in favor of increasing the tolerance there.
At the end of the day that seems to be a valid implementation choice as
for how to implement tgamma, and 2 ulp isn't the end of the world.
For the gamma(10) doctest the relative error is roughly 1.3e-15 (9 ulp).
OK, it isn't the end of the world, and it doesn't seem to increase for
larger arguments, but one would expect the gamma function to have a
smaller error (which is the case for other architectures, according to the
glibc Info manual).
--
Ticket URL: <http://trac.sagemath.org/ticket/15921#comment:38>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
