Vedran Čačić <ved...@gmail.com> added the comment:
I think you don't know what paraphrasing means. Or maybe I don't know it, but
in any case, I'm well aware what Von Neumann said, and how it is usually
misunderstood in today's society. "Living in the state of sin" is simply an
emotionally powerful metaphor, and it pertains to the philosophical
impossibility of something, whether or not there are strong reasons to "do it
anyway" and even good methods of faking/approximating it. Same as "detecting
infinite loops programmatically", "passing objects by value", or "having side
effects in a referentially transparent language". :-)
I agree that Python is a language where practicality beats purity, and as I
said, there is a sensible interface for the implementation about which we agree
(except for a detail: I'd actually _force_ people to import the rounding modes
from decimal module, to at least hint to them what exactly they are doing and
what the preferred approach is). But I still think that arguments for that are
very weak.
First, yes, there is a very small probability of calculations _randomly_ ending
with abc.de50000...0 (in the Platonic sense) [so it actually manifests as a
problem], but there is much greater probability (though still small) that
calculations _theoretically_ ending with abc.de5 actually end with
abc.de49999...7 [and thus are rounded down anyway, despite your insistence on
modes]. People _will_ think "hey, I did the right thing by specifying the
mode--why does it still acts funny?"
"there are reasonable use-cases for different rounding modes even when using
floats.": absolutely. But they are _binary_ rounding modes! I think you should
read the standard. It is actually two standards, one for binary and one for
decimal arithmetic. (The second one is implemented fairly faithfully in the
decimal module; the first one is, through libc, the one that Python floats are
based upon).
The [binary] standard says, more or less, that the result should be as if the
value was calculated with the infinite number or extra [binary] digits (of
course, in practice it should just be some extra precision, but again, of
_binary_ digits), and then, when fitting that value into a smaller [binary]
register with smaller available number of [binary] digis, all extra [binary]
digits are discarded (not stored) and some ending [binary] digits retained are
modified according to the value of some of the discarded [binary] digits and
the rounding mode. For example:
"""
The 24-bit significand will stop at position 23, shown as the underlined bit 0
above. The next bit, at position 24, is called the round bit or rounding bit.
It is used to round the 33-bit approximation to the nearest 24-bit number
(there are specific rules for halfway values, which is not the case here). This
bit, which is 1 in this example, is added to the integer formed by the leftmost
24 bits.
"""
You see it speaks about _bits_, not decimal digits. In the same way, _decimal_
rounding would take a value calculated with some extra precision of _decimal_
digits, and when storing them with the smaller number of _decimal_ digits,
discard extra... blah blah as above. But you cannot round binary numbers to
decimal digits. It's as if you tried to round 0.45 to one trinary digit after
the integer point. The answer is 0.1 in base 3, but it isn't expressible in
decimals. And it doesn't work:
>>> Decimal('0.45').quantize(Decimal(1/3))
decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]
because the authors of quantize have thought about that. The documentation says
"""Unlike other operations, if the length of the coefficient after the quantize
operation would be greater than precision, then an InvalidOperation is
signaled.""" In effect, rounding cannot increase the number of significant
digits. And it would do that if you're rounding to an incompatible base,
whether 2 to 10 or 10 to 3.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41598>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
