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

[zimmermann6]

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)?

Component: basic arithmetic

Issue created by migration from https://trac.sagemath.org/ticket/22797

[zimmermann6]

comment:1

An answer to my side question:

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

[jdemeyer]

Replying to @zimmermann6:

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)

[zimmermann6]

comment:3

2. why does RDF output one more digit than RR (and two less with the str method)?
   See Real/Complex number str() method: do not truncate by default and allow specifying number of digits #21124.

this does not answer my question.

[jdemeyer]

comment:4

Replying to @zimmermann6:

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)

[zimmermann6]

comment:5

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

[jdemeyer]

comment:6

Replying to @zimmermann6:

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 :-)

[jdemeyer]

comment:9

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.

[jdemeyer]

comment:10

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

[zimmermann6]

comment:11

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