Improving REPR_C float accuracy

[yoctopuce]

I have made a few experiments to check how we could improve the accuracy of REPR_C, which currently drops the two lowest mantissa bits.
I came out with the solution below, simpler than current 32bit nanboxed version:

// A MicroPython object is a machine word having the following form:
//  - xxxx...xxxx1 : 31-bit fp (last mantissa bit is lost)
//  - xxxx...xx010 : 29-bit small int, bits 3 and above are the value
//  - xxxx...x0110 : a qstr, bits 4 and above are the value
//  - xxxx...x1110 : an immediate object, bits 4 and above are the value
//  - xxxx...xxx00 : a pointer to an mp_obj_base_t

The resulting code size on ARM4F architecture currently appears to be 600 bytes smaller than current REPR_C, and we get one more mantissa bit on floats. The trade-off is that we loose two bits of immediate smallints, there are still enough to represent a millisecond ticks_diff covering several days.

I would think this is worth running more tests, what do you think ?
Should I try to submit a pull request amending REPR_C ? Or make a new REPR_E ?

[robert-hh]

IMHO, loosing two bits on smallints is a major problem.

[yoctopuce]

Which use-case in particular do you have in mind ? I had the impression that between 30b it+sign or 28 bit + sign it would not make a big difference: It is anyway not enough to avoid switching to bigger ints when dealing with 32bit external interfaces, , but it is large enough to deal with everyday numbers

[robert-hh]

1. It's a breaking change. One simply does not know how much code relies on small INTs being 31 bits. This is not only a matter of number range, but also of allocations and runtime.
2. I do not know what you call everyday numbers.
3. Some ports + boards do not support float. The will loose the larger range without any benefit.
4. The application for floats I see usually deal anyhow with imprecise data. Thus getting two more low order bits usually does not improve things. If you want to do high precision number crunching, use a suitable board or machine.

[yoctopuce]

I think there is a misunderstanding: the intent is not to change the size of smallints for all of MicroPython, the scope is only one specific OBJ_REPR model.

1. Using 28+1 bits as smallints does no cause a major issue with MicroPython core. The size of smallints MicroPython core is already fully parametric.

• OBJ_REPR_A uses 30+1 bits
• OBJ_REPR_B uses 29+1 bits
• OBJ_REPR_C uses 30+1 bits
• OBJ_REPR_D uses 46+1 bits
  The only problem I can foresee is that mpy files produced by mpycross are typically compiled for 30+1 bit smallints, unless a different size is specified at compile time. If someone would distribute such mpy files, which would currently work only with REPR_A and REPR_C, they would not work anymore with REPR_C. Hence my suggestion to make this a new REPR than changing REPR_C.

2. By everyday numbers I mean sizes, durations, counts, typically used in an embedded applications, in particular those that I care about in my job (small automation based on sensors and actuators).

3. REPR_C already has a requirement to have floats enabled. Nobody would choose REPR_C without using floats.

4. I have disagree here. If this discussion was about double-precision floats, I would not care. But with single-precision floats, loosing two bits instead of one at every intermediate result of a computation makes a visible difference at the end.

[dhalbert]

CircuitPython uses OBJ_REPR_C for all its 32-bit ports. Our original port to SAMD21 was on a RAM-starved processor, so we didn't opt for boxed floats. Please do not change OBJ_REPR_C, as our library code, and some internal code, is cognizant of that choice. We don't care if you make an OBJ_REPR_E, but I'm not sure who would use it.

ulab uses mp_float_t internally, which is float, so full 32-bit float arithmetic is available, though I don't know if anyone taken advantage of that to improve the accuracy of some calculation.