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 jdemeyer

  • Milestone changed from sage-6.1 to sage-duplicate/invalid/wontfix
  • Reviewers set to Jeroen Demeyer
  • Status changed from new to needs_review

Feature, not a bug.

This is done such that RealField(200)(1.0e-20) would work as expected.

comment:2 Changed 7 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:3 follow-up: Changed 7 years ago by zimmerma

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 jdemeyer

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: Changed 7 years ago by 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).

Paul

comment:6 in reply to: ↑ 5 ; follow-up: Changed 7 years ago by mmezzarobba

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-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!

comment:7 Changed 7 years ago by jdemeyer

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 zimmerma

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 jdemeyer

If you care about this, please discuss it on sage-devel.

comment:10 in reply to: ↑ 6 Changed 7 years ago by mmezzarobba

Replying to mmezzarobba:

1.0e-20 should be preparsed to something else than an element of RR!

To clarify, I don't really care whether Reals(200)(1.0e-20) yields 1.0000000000000000000000000000000000000000000000000000000000e-20 or 9.9999999999999994515327145420957165172950370278739244710772e-21. I find RealLiterals 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 RealLiterals (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 vbraun

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 vbraun

  • Resolution set to wontfix
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.