Add more fields to sys.float_info

[rhettinger]

BPO	41823
Nosy	@tim-one, @rhettinger, @mdickinson, @corona10

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-09-21.01:01:54.389>
labels = ['extension-modules', '3.10']
title = 'Add more fields to sys.float_info'
updated_at = <Date 2020-09-23.01:40:17.721>
user = 'https://github.com/rhettinger'

bugs.python.org fields:

activity = <Date 2020-09-23.01:40:17.721>
actor = 'rhettinger'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2020-09-21.01:01:54.389>
creator = 'rhettinger'
dependencies = []
files = []
hgrepos = []
issue_num = 41823
keywords = []
message_count = 5.0
messages = ['377237', '377256', '377284', '377341', '377353']
nosy_count = 4.0
nosy_names = ['tim.peters', 'rhettinger', 'mark.dickinson', 'corona10']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue41823'
versions = ['Python 3.10']

Linked PRs

• gh-85989: deprecate float.__getformat__() class method #146400
• gh-85989: move HAVE_DOUBLE_ROUNDING check to test.support #150219

[rhettinger]

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:

    @requires_IEEE_754
    @unittest.skipIf(HAVE_DOUBLE_ROUNDING,
       "fsum is not exact on machines with double rounding")
    def testFsum(self):
        ...

[corona10]

@rhettinger

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

[rhettinger]

[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.

[mdickinson]

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).

[rhettinger]

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.

[skirpichev]

I agree with Mark, that sys.float_info is not a best place for those additions. Probably it's better to keep such stuff in the Lib/test/support/:

1. several test files (3+) now share HAVE_DOUBLE_ROUNDING check, lets move this to Lib/test/support/
2. float.__getformat__() now can be only "IEEE, big/little" for the CPython. Lets deprecate this semi-private API and move this check to Lib/test/support/. This was implemented by: gh-85989: deprecate float.__getformat__() class method #146400

N.B. see also recent attempt to provide access to the __STDC_IEC_559__ macro.