Title: Add more fields to sys.float_info
Type: Stage:
Components: Extension Modules Versions: Python 3.10
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: corona10, mark.dickinson, rhettinger, tim.peters
Priority: normal Keywords:

Created on 2020-09-21 01:01 by rhettinger, last changed 2020-09-23 01:40 by rhettinger.

Messages (5)
msg377237 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-09-21 01:01
Consider adding new non-sequence fields to sys.float_info: doubling_rounding and ieee_754.

The code in test_math defines a useful constant:

   # detect evidence of double-rounding: fsum is not always correctly
   # rounded on machines that suffer from double rounding.
   x, y = 1e16, 2.9999 # use temporary values to defeat peephole optimizer
   HAVE_DOUBLE_ROUNDING = (x + y == 1e16 + 4)

There is another useful value in a float.__getformat__ which is hard to find and only documented for internal use:

   >>> float.__getformat__('double')
   'IEEE, little-endian

Making this information available would make it easier for users to do what we do in test_math:

       "fsum is not exact on machines with double rounding")
    def testFsum(self):
msg377256 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-09-21 14:29

I like the idea to add more informative information,

However, since the type is the structsequence the change can cause the
ValueError: too many values to unpack when the variable is used as a tuple.

But the if such use case is not often used, it will be okay
msg377284 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-09-21 21:04
[Dong-hee Na]
> However, since the type is the structsequence the 
> change can cause the ValueError: too many values 
> to unpack when the variable is used as a tuple

Structseq also allows named fields that aren't part of the tuple.  That is why I suggested, "consider adding new non-sequence fields ..."

For example, the Posix stat result struct seq has optional fields (
st_blksize, st_blocks, st_rdev, and st_flags) that are available as attributes only.
msg377341 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2020-09-22 17:20
Double rounding is a property of how operations on floats are carried out, rather than being a property of the float format itself; I'm not sure that it belongs in float_info. It's also potentially ill-defined. Right now, as far as I *know*, it seems to be the case that our builds of CPython on x86 or x64 either consistently use x87+extended precision for all floating-point operations, or they consistently use SSE2 for all floating-point operations, but there's no reason that a build couldn't use SSE2 in some cases and x87+extended precision in others. (There are also subtle differences between x87+53-bit precision setting and IEEE 754-following SSE2.)

We also don't have any _reliable_ way to tell whether floats use IEEE 754, though we do have some ad-hoc ways that seem to work in practice (at least for now).
msg377353 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-09-23 01:40
Given that reliable checks aren't possible, it would still be nice (to have flags suchas non_ieee754_detected and double_rounding_detected.  If the flag is False it provides no firm guarantees, but it if it is true, it is meaningful.
Date User Action Args
2020-09-23 01:40:17rhettingersetmessages: + msg377353
2020-09-22 17:20:06mark.dickinsonsetmessages: + msg377341
2020-09-21 21:04:37rhettingersetmessages: + msg377284
2020-09-21 14:29:45corona10setnosy: + corona10
messages: + msg377256
2020-09-21 01:01:54rhettingercreate