This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients cykerway, mark.dickinson, steven.daprano
Date 2021-12-24.17:11:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1640365912.24.0.184601737216.issue46173@roundup.psfhosted.org>
In-reply-to
Content
Yes, exactly: Python's intentionally following the normal IEEE 754 rules for rounding a value to the binary64 format using the round-ties-to-even rounding rule, as formalised in section 7.4 of IEEE 754-2019 (and quoted by @cykerway). These are the exact same rules that are followed for conversion from str to float (where we return `inf` rather than raise `OverflowError` for large values, but the overflow boundary is the same), or conversion from Fraction to float, or conversion from Decimal to float, etc.

> the python float doc might better say "If the *rounded* argument is outside..."

Docs are hard. I think there's a danger that that word "rounded" would cause more confusion than it alleviates - to me, it suggests that there's some kind of rounding going on *before* conversion to float, rather than *as part of* the conversion to float. This isn't a language specification document, so it's not reasonable to give a perfectly accurate description of what happens - the actual meaning would be lost in the mass of details. (In this case, it would also be rather hard to be precise, given that we have to allow for platforms that aren't using IEEE 754.) I'm not seeing an obvious way to improve the docs here.
History
Date User Action Args
2021-12-24 17:11:52mark.dickinsonsetrecipients: + mark.dickinson, steven.daprano, cykerway
2021-12-24 17:11:52mark.dickinsonsetmessageid: <1640365912.24.0.184601737216.issue46173@roundup.psfhosted.org>
2021-12-24 17:11:52mark.dickinsonlinkissue46173 messages
2021-12-24 17:11:52mark.dickinsoncreate