Opened 7 years ago
Closed 7 years ago
#15542 closed defect (wontfix)
Rounding weirdness when increasing the precision of a real number
Reported by: | mmezzarobba | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | numerical | Keywords: | |
Cc: | zimmerma | Merged in: | |
Authors: | Reviewers: | Jeroen Demeyer | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
This is not correct:
sage: Reals(200)(RR(1.0e-20)) 1.0000000000000000000000000000000000000000000000000000000000e-20
since RR(1.0e-20)
is actually equal to 6646139978924579·2^{-119}, and indeed:
sage: Reals(200)(RR(1.0e-20).exact_rational()) 9.9999999999999994515327145420957165172950370278739244710772e-21
Also note that the following related examples work:
sage: Reals(200)(RDF(1.0e-20)) 9.9999999999999994515327145420957165172950370278739244710772e-21 sage: ComplexField(200)(CC(1.0e-20)) 9.9999999999999994515327145420957165172950370278739244710772e-21
Change History (12)
comment:1 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-duplicate/invalid/wontfix
- Reviewers set to Jeroen Demeyer
- Status changed from new to needs_review
comment:2 Changed 7 years ago by
- Status changed from needs_review to positive_review
comment:3 follow-up: ↓ 4 Changed 7 years ago by
I find this "feature" quite inconsistent with what is done for other fields:
sage: ComplexField(200)(CC(1.0e-20)) 9.9999999999999994515327145420957165172950370278739244710772e-21 sage: RealIntervalField(100)(RIF("1.0e-20")) [9.9999999999999994515327145420957e-21 .. 1.0000000000000000956165483594624e-20]
Moreover:
sage: Reals(200)(RR(1.0e-20)) 1.0000000000000000000000000000000000000000000000000000000000e-20 sage: Reals(200)(RR("1.0e-20")) 9.9999999999999994515327145420957165172950370278739244710772e-21
Paul
comment:4 in reply to: ↑ 3 Changed 7 years ago by
Replying to zimmerma:
I find this "feature" quite inconsistent with what is done for other fields:
I agree, but that's not the topic of this ticket. You could consider creating 3 new tickets for the inconsistencies below (but I personally don't care enough to fix them).
sage: ComplexField(200)(CC(1.0e-20)) 9.9999999999999994515327145420957165172950370278739244710772e-21 sage: RealIntervalField(100)(RIF("1.0e-20")) [9.9999999999999994515327145420957e-21 .. 1.0000000000000000956165483594624e-20] sage: Reals(200)(RR("1.0e-20")) 9.9999999999999994515327145420957165172950370278739244710772e-21
comment:5 follow-up: ↓ 6 Changed 7 years ago by
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).
Paul
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 10 Changed 7 years ago by
Replying to 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-21Since 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
!
comment:7 Changed 7 years ago by
At least the behaviour is intentional, so it's by definition not a bug. Perhaps it's a bad design decision. But if you want to argue for that, please do it on sage-devel
, not this ticket.
comment:8 Changed 7 years ago by
At least the behaviour is intentional, so it's by definition not a bug.
then it should be documented somewhere. Where?
Also:
sage: a=RealField(53)(1.0e-20) sage: a.exact_rational? ... Returns the exact rational representation of this floating-point number.
thus either a
is exactly 10^(-20)
, and then exact_rational
should return that
value, or it is not, and Reals(200)(a.exact_rational())
should return 6646139978924579/664613997892457936451903530140172288
Paul
comment:9 Changed 7 years ago by
If you care about this, please discuss it on sage-devel
.
comment:10 in reply to: ↑ 6 Changed 7 years ago by
Replying to mmezzarobba:
1.0e-20
should be preparsed to something else than an element ofRR
!
To clarify, I don't really care whether Reals(200)(1.0e-20)
yields 1.0000000000000000000000000000000000000000000000000000000000e-20
or 9.9999999999999994515327145420957165172950370278739244710772e-21
. I find RealLiteral
s confusing, but the way Reals(200)(1.0e-20)
works is not a bug by itself.
The way Reals(200)(RR(1.0e-20))
works is a more serious problem, however. In other words, unless we simply get rid of RealLiteral
s (as Paul just suggested on sage-devel), they should be elements of some ad hoc that coerces into real fields (or perhaps even of QQ
), not of real fields themselves!
comment:11 Changed 7 years ago by
I'm closing this ticket, please direct any future discussion to sage-devel thread at https://groups.google.com/d/msg/sage-devel/c2Ih4uglTgQ/iGSIpTwuoBsJ
comment:12 Changed 7 years ago by
- Resolution set to wontfix
- Status changed from positive_review to closed
Feature, not a bug.
This is done such that
RealField(200)(1.0e-20)
would work as expected.