Tim Peters <t...@python.org> added the comment:
[Mark] > If we do this, can we also persuade Guido to Pronounce that > Python implementations assume IEEE 754 format and semantics > for floating-point? On its own, I don't think a change to force 53-bit precision _on_ 754 boxes would justify that. That's just changing oddball boxes that already implement 754 to do so in the way most other 754 boxes currently do it (and in the way all future 754 platforms are expected to do it). To go beyond that seems to require addressing bigger questions, like: - _Are_ there currently, or expected to be, non-754 Python platforms? There have been in the past. - What does "754 semantics" actually mean? For example, as these bug reports point out, 754 is silent about whether the possibility of double rounding - even in primitive atomic operations - is "a bug" or "a feature" :-( Would we insist that Python may not work on platforms that flush denorms to 0? Etc. - What, concretely, would change in CPython if the Pronouncement were made? As I recall, we inherit most fp behaviors from the platform C compiler and libraries. That is, how would the Pronouncement benefit CPython? For example, do we have significant blobs of code that are trying to cater to non-754 boxes? Not that I'm asking for answers here. If there's something to be pursued here, I'd suggest it's better as a topic in python-ideas or python-dev. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24567> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
