The bug seems to be in mp_parse_num_decimal which parses 1000.4 as 1000.4000000000001.

What platform do you use? MicroPython leaves floating-point handling to the platform (which means your FPU if you have that, or somebody's software floating-point library if you don't).

To get ahead with this, you would need to provide binary (i.e. hexadecimal) values of the FP numbers you get, that's the only way to assess correctness/incorrectness of it. (Well, approach being able to assess, the actual assessment is a work on its own.)

We've tested that behavior on different platforms (ARM v7m, x86_64), so this bug is not platform-dependent. The bug really is early in the process, at the parsing level: 1000.4 is improperly parsed as 0x408f433333333334 instead of 0x408F433333333333.

To get ahead with this, you would need to provide binary (i.e. hexadecimal)

To be more specific, we should implement float.hex() (guarded by config option, default off - which are the usual rules) to be able to debug there comfortably.

1000.4 is improperly parsed as 0x408f433333333334 instead of 0x408F433333333333.

@EmilieNumworks , good research, thanks. I'm sure @dpgeorge will look into this as his time permits.

As you can see, mp_parse_num_decimal() does iterative float multiplications, a recipe for rounding error. I don't know how other folks do it, perhaps keeping to integer value for as long as possible? Worth research too.

At least the line dec_val *= MICROPY_FLOAT_C_FUN(pow)(10, exp_val); is buggy.

For example, when parsing 1000.4, it tries to do dec_val = 10004.0 * 0.1 which yields an incorrect result because of a rounding error. Indeed, in IEEE754 world, 1000.4 != (10004.0*0.1).

See #4133 for a possible fix. Uses the same logic as some implementations of strtod(3).

The behaviour of float parsing was improved in b768cc6