Question on arithmetic



  • machine.freq()[0] returns 80000.03 which is OK.
    machine.freq()[0] / 1000 / 1000 returns 80.00003 which is OK

    But

    machine.freq()[0] / 1000000 returns 8.181962e-07

    which doesn't look the right result

    machine.freq()[0] / 1000000.0
    machine.freq()[0] / 1e6

    returns the same. What is wrong?



  • @daniel said in Question on arithmetic:

    Hello,

    Sorry for the delay. The problem is caused by a compiler bug that Espressif has identified and a fix is on the way. Please see details here:

    https://github.com/espressif/esp-idf/issues/96

    Cheers,
    Daniel

    Hi Daniel

    thanks for the info. Looking forward the fixed firmware, hope they will fix it shortly.

    Regards... Béla



  • Hello,

    Sorry for the delay. The problem is caused by a compiler bug that Espressif has identified and a fix is on the way. Please see details here:

    https://github.com/espressif/esp-idf/issues/96

    Cheers,
    Daniel



  • The bug doesn't appear on my pyboard, so it has something to do with how they're handling floats on this port.



  • After three and half weeks still waiting for a fix of this floating point bug. It has nothing to do with LoRa, WiFi, Bluetooth it is a core MicroPython issue. For me it is a main blocking factor, as I can't trust the MicroPython implementation at all if there are such bugs.



  • I also just found what might be the same bug. I triggered it by doing 100000000.0/1, which it said returns 0.0. I'm running 0.9.2.b2.



  • It's planned for the release of next week Friday. I agree that it's a big issue.



  • @daniel

    Can you provide an ETA for fix? A buggy arithmetic in core is really a problem. According to reports it works correctly on original MicroPython boards.

    This issue was already discussed several month ago at the upstream MicroPython GitHub issue tracker and fixed there as far as I remember.



  • Thanks for the report.
    It's indeed a bug inside MicroPython. Doing the same calculations in pure C returns the correct value: 80.000000, so it's definitely in the way MicroPython handles floating point numbers. We'll add this one to the list...



  • Confirming this error. It happens for 5e5=500000 and up. Multiplication doesn't trigger it (freq*1e-6 is OK) and integer floor division is OK (freq//1000000). Looks like a floating point division bug in MicroPython.


Log in to reply
 

Pycom on Twitter