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

@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

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

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

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.