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: ```python assignee = None closed_at = None created_at = labels = ['extension-modules', '3.10'] title = 'Add more fields to sys.float_info' updated_at = user = 'https://github.com/rhettinger' ``` bugs.python.org fields: ```python activity = actor = 'rhettinger' assignee = 'none' closed = False closed_date = None closer = None components = ['Extension Modules'] creation = 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'] ```

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