#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:
Authors: | Work issues:
Report Upstream: Reported | Commit:
upstream. Developers acknowledge | 079bb9af4f12892268a19f0d218ac96bd72466f4
bug. | Stopgaps:
Branch: |
u/dimpase/arm_fixes_etc |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by dimpase):
Replying to [comment:9 pbruin]:
> It seems to me that converting to a `RealField` is not only (possibly
confusing) noise for the reader; it could also hide potential future
precision bugs.
>
> Is there any chance that the Maxima bug will get fixed soon?
all I know about this is in the thread cited in the ticket description.
>
> Also, maybe I misunderstand, but what makes conversion of floats into a
`RealField` with ''higher'' precision suppress numerical noise (mentioned
in the ticket description)?
probably it should be classified as "numerical noise", but as
"precision/formatting/rounding bugs". And the latter are Maxima, and
perhaps also the ECL's interpretation of a particular case of undefined
behaviour. Hmm, perhaps it's also some specifically Sage problem:
{{{
sage: .4980113944988315
0.498011394498831
sage: .49801139449883150
0.498011394498832
}}}
Conversion into `RealField(54)` appears to fix this discrepancy (I don't
know why).
{{{
sage: RealField(54)(.49801139449883150)
0.498011394498832
sage: RealField(54)(.4980113944988315)
0.498011394498832
}}}
By the way, Python behaves differently, but still confusing :
{{{
$ python
Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> .4980113944988315
0.4980113944988315
>>> .49801139449883150
0.4980113944988315
>>> .49801139449883155
0.49801139449883153
>>> .49801139449883156
0.4980113944988316
>>>
}}}
In particular that `55` at the end being printed as `53`, and rounding
`56` at the end as `60`, but keeping `55` as just `55`.
One reason against just putting ellipses is that this is a sure way to
hide this problem forever...
--
Ticket URL: <http://trac.sagemath.org/ticket/15921#comment:10>
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.
