Precision issue

[Terry Reedy]

"Duncan Booth" <duncan at NOSPAMrcp.co.uk> wrote in message
news:Xns9410970CA71AAduncanrcpcouk at 127.0.0.1...
> Ben Finney <bignose-hates-spam at and-benfinney-does-too.id.au> wrote
in
> news:slrnbodbq6.2fj.bignose-hates-spam at rose.localdomain.fake:
> > Because '3.4' is what str(3.4) returns.  If repr(3.4) lies about
the
> > value stored, what function will you leave us to discover the
actual
> > value?
>
> In what way is 3.3999999999999999 any more the value than 3.4?

In the same way that 0 is a better approximation of .3 than 1, and
vice versa for .7.  repr(<float>) attemps to return closest 17 digit
decimal, or perhaps closest that will yield same binary when evaled.
Sometime adding or substracting 1 to or from last digits will give a
decimal that also evals to same, sometimes not.

Let's turn question around.  Suppose you started with
a=3.3999999999999999
Now, would you want repr(a) to be number entered, or less accurate
3.4?

Or suppose 'a' resulted from calculation rather than entered literal.
Why should repr() do anything but report closest approximation
possible?  Especially given that one can explicitly choose any level
of rounding one wants.  As Ben said, if repr() fudged output, then we
would need another function to replace it.  But we already have
round(), formats, and str() to do fudging.

Terry J. Reedy