#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 pbruin):
Replying to [comment:10 dimpase]:
> Replying to [comment:9 pbruin]:
> > 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
> }}}
Part of the subtlety is that the real number whose decimal expansion is
`.4980113944988315000000...` does not have a finite binary expansion:
{{{
sage: a=.4980113944988315
sage: a.prec()
53
sage: a.str(base=2)
'0.011111110111110110101100101111000110100001100111111010'
sage: b=.49801139449883150
sage: b.prec()
54
sage: b.str(base=2)
'0.0111111101111101101011001011110001101000011001111110101'
sage: c=.498011394498831500000000000
sage: c.str(base=2)
'0.0111111101111101101011001011110001101000011001111110100111111111110011011100001100100101'
}}}
At least this is consistent with normal rounding rules.
There is another subtlety, namely that `a` is a `RealLiteral` and
remembers its decimal expansion, which demonstrates its effect when you
convert `a` into a field with higher precision. (See also
[https://groups.google.com/forum/#!searchin/sage-
devel/RealLiteral|sort:date/sage-devel/c2Ih4uglTgQ/siUeEa4fz64J this sage-
devel discussion].) Instead of extending by 0, it gives the same binary
expansion as `c`:
{{{
type(a)
<type 'sage.rings.real_mpfr.RealLiteral'>
sage: RealField(c.prec())(a).str(base=2)
'0.0111111101111101101011001011110001101000011001111110100111111111110011011100001100100101'
}}}
Now I don't know if this is what behind your observation; at least the
output of `elliptic_e()` seems to be a `RealNumber`, not a `RealLiteral`.
> One reason against just putting ellipses is that this is a sure way to
hide this problem forever...
Yes, but I'd say the same holds for the `RealField(prec)(0.123)`
solution... I tend towards `# abs tol`/`# rel tol` as the least invasive
solution, although that could also hide precision bugs.
--
Ticket URL: <http://trac.sagemath.org/ticket/15921#comment:11>
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.
