Precision issue

[Stephen Horne]

On Fri, 10 Oct 2003 13:26:27 -0400, "Terry Reedy" <tjreedy at udel.edu>
wrote:

>
>"Stephen Horne" <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote
>in message news:odcdovgdf7mib8emi9g7qhrnjv53r9bmcs at 4ax.com...
>> My impression has always been that 'repr' gives a representation of
>> the value which, when parsed (using 'eval', for instance),
>> reconstructs the original value. In this respect, '3.4' is just as
>> good as '3.3999999999'.
>
>Not just *a* representation, but the *most accurate*.  '3.4' is (as
>you show below) less accurate, or that would have been chosen instead.
>The internal value is what it is, regardless of whether it results
>from this literal or that literal or from calculation.  Why the
>opposition to having a way to get the closest 17-digit decimal
>approximation?

I'm not strongly opposed - in fact, I'm not really opposed at all. I
didn't start the discussion, I just countered an argument which I
still believe is simply wrong.

Even so, what is so advantageous about using the closest 17-digit
decimal approximation? That doesn't seem to me to be particulary
suited to the purpose of repr - alternative schemes for choosing the
repr may potentially be better suited.

Certainly it is *not* the most accurate representation possible.

>I presume that 17 in the minimum necessary
>to guarantee a unique, back-convertible prepresentation for every
>float.

In other words, the choice of 17 digits precision is supporting the
goal of a sufficient (ie not overkill) backward-compatible
representation.

The given result is not the optimum in either sufficiency or
precision. If precision is the goal, the result should be
'3.399999999999999911182158029987476766109466552734375'. If
sufficiency is the goal, the result should be '3.4'.

This isn't a criticism of the current system - a balance between
extremes is often appropriate, and in this case the key advantage is
presumably a simpler and faster algorithm. But it may well be valid to
discuss alternate schemes and their rationales.

>> Out of curiosity, I wrote the function at the bottem of this post to
>> convert a Python float into two string representations - a rational
>> and a decimal - both having precisely the same value as the float. I
>> got the following results starting with 3.4...
>>
>> Rational : 7656119366529843/2251799813685248
>> Decimal  : 3.399999999999999911182158029987476766109466552734375
>
>If this is correct, then rounding up to 3.4 would be like rounding .11
>to 1 instead of 0.

Yes, if the logic *must* be about rounding. But that isn't necessarily
the best scheme given the purpose of repr. As I said, there are other
possible rationales that give different best representations - the
ones relevant here being 'most precise possible' (which Benn Finney
wrongly seemed to think repr provides - the whole point of my reply)
or 'sufficient'.

Using the representation '3.4' instead of '3.399999...' has advantages
both for human readers and for use in files/data packets - in the
latter case, for instance, it saves bytes. 'Sufficient' does not mean
providing 17 digits of precision when two will do.

Of course, I wouldn't mind a function which could give me the exact
level of precision I want. At present, the '%' operator gives the
closest thing to this, but even that refuses to give more digits
precision than those 17 (or whatever) that repr gives - extra digits
just get filled in as zeros irrespective of the precise value.

Whether there is a need for this, of course, is a different thing.

If I were to argue against, my argument would be that there is the
risk of introducing bugs - either in the repr function itself
(conversion to decimal can be more fiddly than some people realise,
especially when optimised) or in code which relies on the way the repr
function currently works (which I believe has been fixed since Python
prehistory).

The truth is, however, that I really don't care much either way. Just
because I disagree with an argument made by one clan, that doesn't
automatically mean I've joined the other clan. I was simply pointing
out what I see as an error - not taking sides.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk