For an example of a number that did not parse correctly before this PR, but parses correctly now, consider 74e46. This used to parse to b'\xee\xad\xa0\xec\xd73\xe0I' but now parses correctly to b'\xef\xad\xa0\xec\xd73\xe0I' (note LSB). And getting this correct is hard because 74 can be represented exactly in a double, so the error is introduced by applying the exponent, ie the multiplication by 10**46. This exponent cannot be represented exactly on its own so pow(10, 46) is inexact, and then doing the multiplication 74 * pow(10, 46) propagates the error.

The way this number is parsed in this PR is:

• 74 parsed as a big-int, with exponent 46 parsed as a machine int
• 5**exp computed as a big-int
• 74 * 5**exp computed as a big-int (still exact)
• normalisation of 74 * 5**exp which does correct rounding (this step is not strictly needed though)
• convert 74 * 5**exp to a float, no longer exact but as close as possible to the true value (due to IEEE properties of FP)
• multiply byt 2**exp by: ldexp(float(74 * 5**exp), exp) which is an exact FP operation (basically just adjusts the FP exponent of 74 * 5**exp)

This looks really good. Didn't check the code in detail but the logic is sound and if tests pass the code should be correct :) With that in mind: it's probably worth adding as much 'speical' cases as needed to cover a good range. Then if the performance isn't abysmal this is the way forward I think.

With that in mind: it's probably worth adding as much 'speical' cases as needed to cover a good range.

Not sure what you mean by this, which "special cases"?

The ones which don't parse correctly now like in your previous comment. And picked across the whole range of doubles, i.e. also very large and very small ones.

Aah, I see, you mean add specific tests. Yes indeed.

For 32-bit parsing it should be possible to test every value (although not as part of the test suite, it'd take too long).

If you would like some additional 'special case' double-precision tests, feel free to use these (or feel free to bin them - won't hurt my feelings :-) )

(All cases refer to 17-digits-of-precision decimal inputs (sans trailing zeros), with expected results expressed as (little-endian) IEEE-754 binary64 values.)

Overflow/largest double boundary:
1.7976931348623159e308 (should overflow, 0x000000000000f07f )
1.7976931348623158e308 (should yield the max double, 0xffffffffffffef7f )

Normalized/denormalized double boundary
2.2250738585072012e-308 (should yield smallest normalized double, 0x0000000000001000 )
2.2250738585072011e-308 (should yield largest denormalized double, 0xffffffffffff0f00 )

Shortest (up to) 17-digit input that converts to smallest denormalized double:
5e-324 (should yield smallest denormalized double, 0x0100000000000000 )

Closest 17-digit input to the smallest denormalized double:
4.9406564584124654e-324 (should yield smallest denormalized double, 0x0100000000000000 )

The next boundary will depend on how good the ldexp implementation is on the target platform:
Smallest denormalized double/underflow boundary:

2.4703282292062328e-324 (should yield smallest denormalized double, 0x0100000000000000 )
(Note that this value is greater than 2**-1075 and therefore should round up. 64-bit CPython 3.7.5 on win32 gets this right. Your mileage may vary, since the 54 most significant bits of the result are 0b1.00000000000000000000000000000000000000000000000000000 x 2**-1075.)

2.4703282292062327e-324 (should underflow to zero: 0x0000000000000000 )
(Note that this value is less than 2**-1075 and therefore should round down to zero.)

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:  +448 +0.052% standard
      stm32:  +140 +0.036% PYBV10
     mimxrt:  -728 -0.195% TEENSY40
        rp2:  +288 +0.031% RPI_PICO_W
       samd:  +128 +0.048% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:  +182 +0.040% VIRT_RV32

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.54%. Comparing base (9bde125) to head (e4af676).

@@           Coverage Diff           @@
##           master    #6024   +/-   ##
=======================================
  Coverage   98.54%   98.54%           
=======================================
  Files         169      169           
  Lines       21941    21968   +27     
=======================================
+ Hits        21621    21648   +27     
  Misses        320      320           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.