Opened 5 years ago

# Inconsistencies in printing elements of RDF and RR = RealField(53)

Reported by: Owned by: zimmerma minor sage-8.0 basic arithmetic N/A

Consider the following:

sage: a = RDF(pi)
sage: a              # Same as repr() of a Python float: shortest string that will evaluate back to the same float
3.141592653589793
sage: a.str()        # Same as str() of a Python float
'3.14159265359'
sage: RR(a)          # mpfr_get_str() with less digits than default
3.14159265358979
sage: RR(a).str()    # mpfr_get_str() with 0 digits
'3.1415926535897931'

Questions:

1) why does a not give the same output as a.str() (without the quotes)?

2) why does RDF output one more digit than RR (and two less with the str method)?

### comment:1 Changed 5 years ago by zimmerma

An answer to my side question:

sage: a=RDF(pi); a
3.141592653589793
sage: a.__repr__()
'3.141592653589793'

### comment:2 in reply to: ↑ description Changed 5 years ago by jdemeyer

2) why does RDF output one more digit than RR (and two less with the str method)?

See #21124.

Side question: how can I obtain (in a program) the string '3.141592653589793' corresponding to the first output?

repr(a)

### comment:3 follow-up: ↓ 4 Changed 5 years ago by zimmerma

2) why does RDF output one more digit than RR (and two less with the str method)? See #21124.

this does not answer my question.

### comment:4 in reply to: ↑ 3 Changed 5 years ago by jdemeyer

this does not answer my question.

Sorry, I misread your question. The problem is that there are various things here: repr(x) vs. x.str() vs. str(x) (which you didn't mention but could be relevant) and RR vs. RDF.

So your question 2) is about the difference in repr(x) between RR and RDF.

For RDF, we use the repr function from Python floats. This returns the shortest decimal expansion which will give the original number back when doing RDF("the string"). In particular, 2 different numbers are guaranteed to have diffent string representations.

For RR, we arbitrarily decide to show a little bit less digits to avoid too many questions about rounding issues. You know, things like

sage: 0.1 + 0.2
0.300000000000000
sage: RDF(0.1) + RDF(0.2)
0.30000000000000004

There is a comment in the code

# This avoids the confusion a lot of people have with the last
# 1-2 binary digits being wrong due to rounding coming from
# representing numbers in binary.

and the feature was added in

commit c9e2428ea87990d7c578dfc34d33df07bfcdeb45
Author: William Stein <wstein@gmail.com>
Date:   Sat Oct 28 13:28:44 2006 -0500

Made _assign_names something only do once; new inject_variables system; lots of documenation

(i.e. a commit totally unrelated to decimal representations of real numbers)

### comment:5 follow-up: ↓ 6 Changed 5 years ago by zimmerma

in my opinion, it would be better if RR would also print 16 significant digits, for two reasons:

1) consistency with RDF

2) like for RDF, we could write RR("the string") to get back the number, and two

different numbers would be guaranteed to have different string representations.

Besides, note that the 0.1 + 0.2 issue still happens:

sage: 1.2-1.1
0.0999999999999999

Paul

### comment:6 in reply to: ↑ 5 Changed 5 years ago by jdemeyer

Besides, note that the 0.1 + 0.2 issue still happens:

sage: 1.2-1.1
0.0999999999999999

Of course. I only answered the "why" question, I didn't say I agreed with it :-)

### comment:7 Changed 4 years ago by jdemeyer

• Description modified (diff)
• Summary changed from inconsistencies between RDF and RR = RealField(53) to Inconsistencies in printing elements of RDF and RR = RealField(53)

### comment:8 Changed 4 years ago by jdemeyer

• Description modified (diff)

### comment:9 Changed 4 years ago by jdemeyer

Side question: how can I obtain (in a program) the string '3.141592653589793' corresponding to the first output?

Use repr(foo) to get the display representation of foo.

### comment:10 Changed 4 years ago by jdemeyer

I'm a bit confused here. I can answer all your questions but I don't know whether there remains a bug or not...

### comment:11 Changed 4 years ago by zimmerma

thank you for answering 3). It remains 1) and 2) which show inconsistent behaviour in my opinion.

Note: See TracTickets for help on using tickets.