uPython calculation (division) accuracy

[eljots]

I need double precision, and in the meantime it turns out that division in uPython has 8-bit precision(?).
For example, in uPython 9000000000/6400010 = 1406.184082 but the exact value (e.g. from the system calculator) is 1406.184085121. Unfortunately, for programming the Si5351 generator I need the exact value of the fraction from the division, i.e. 0.184085121, which is then multiplied by hudge numbers (hundreds of thousands or millions) and generates unacceptable errors when calculated by uPython. How can I improve the precision of division in uPython or get around this problem?

[GitHubsSilverBullet]

Not 8 bit precision.
It's a regular float. IEEE754 explains it in detail.

[GitHubsSilverBullet]

How can I improve the precision of division in uPython or get around this problem?

Use a FixPoint library setup for an arbitrary precision.

[robert-hh]

Use a board that supports double float with 15 digit precision with MicroPython instead of 7.5. Like PYBD or Teensy 4.x.

[eljots]

Thank you all for quick response.
Unfortunately I have ESP32 (WROOM) and the ESP32_GENERIC-20230426-v1.20.0 image at my disposal.
About "Use a FixPoint library setup for an arbitrary precision.", could you tell more about?

[GitHubsSilverBullet]

About "Use a FixPoint library setup for an arbitrary precision.", could you tell more about?

Sure. Take a look at »spfpm« Simple Python Fixed-Point Module, for instance.
https://github.com/rwpenney/spfpm

Works perfect on a pico or pico2. Pure Python. One can reduce the code and strip away the things one doesn't need.

[eljots]

As a small workaround, instead of simple division a/b, I used the operation int(a/b) + fmod(a,b)/b, which improves the result several times in position 10exp-6.
For the previously given example of division 900000000/640030 (sorry, I wrote 640010 by mistake), I get the value 1406.1840851 with the workaround. For comparison, direct division gives 1406.184082 and the result from the calculator is 1406.184085121.
I also did an additional analysis of the accuracy of the algorithm and it seems that with the current calculation accuracy I will achieve the required value of the si5351 frequency with the assumed error.
Nevertheless, it is a surprise to me that the implementation of uPython on different processors gives different accuracy in calculations, which I have to take into account in subsequent projects. Thank you again for the explanations.

[robert-hh]

Nevertheless, it is a surprise to me that the implementation of uPython on different processors gives different accuracy in calculations,

It depends on the floating point hardware of the MCU. If it supports double, double precision is used. Otherwise, single precision. In that case, software double precision could be used at the cost of speed and code size.

[GitHubsSilverBullet]

In case you need a tiny bit of higher precision… ;-)

from spfpm import FXfamily, FXnum
fam = FXfamily(1000)
result = FXnum(900000000, fam) / FXnum(640030, fam)
print(result)
1406.18408512100995265846913425933159383153914660250300767151539771573207505898
1610237020139680952455353655297407934003093604987266221895848632095370529506429
3861225255066168773338749746105651297595425214443072980954017780416542974548068
059309719856881708669906098151649141446494695561145571301345249441432

[eljots]

I'm really impress about this accuracy:
1406.18408512100995265846913425933159383153914660250300767151539771573207505898
1610237020139680952455353655297407934003093604987266221895848632095370529506429
3861225255066168773338749746105651297595425214443072980954017780416542974548068
059309719856881708669906098151649141446494695561145571301345249441432
I think it's enough for me and this is a great conclusion to this discussion ;-).