#15542: Rounding weirdness when increasing the precision of a real number
----------------------------+----------------------------------------------
Reporter: | Owner:
mmezzarobba | Status: positive_review
Type: defect | Milestone: sage-duplicate/invalid/wontfix
Priority: major | Resolution:
Component: | Merged in:
numerical | Reviewers: Jeroen Demeyer
Keywords: | Work issues:
Authors: | Commit:
Report Upstream: N/A | Stopgaps:
Branch: |
Dependencies: |
----------------------------+----------------------------------------------
Comment (by mmezzarobba):
Replying to [comment:5 zimmerma]:
> ok, but then this is definitively a bug:
> {{{
> sage: a=RealField(53)(1.0e-20)
> sage: Reals(200)(a)
> 1.0000000000000000000000000000000000000000000000000000000000e-20
> sage: Reals(200)(a.exact_rational())
> 9.9999999999999994515327145420957165172950370278739244710772e-21
> }}}
> Since a 53-bit floating-point value is exactly representable with a
precision of 200 bits, we should have {{{Reals(200)(a) ==
Reals(200)(a.exact_rational())}}}. Otherwise Sage is not IEEE-754
compliant (despite MPFR being compliant).
I also can't see how this could be considered anything other than a bug.
If `RealField(200)(1.0e-20)` really has to be equal to
`RealField(200)(10**(-20))` (which is definitely ''not'' what I would call
"work as expected"), then `1.0e-20` should be preparsed to something else
than an element of `RR`!
--
Ticket URL: <http://trac.sagemath.org/ticket/15542#comment:6>
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/groups/opt_out.
