Espruino kind of does 64 bit - when you do something with two 32 bit integers it's done in 64 bits and then if it doesn't fit in a 32 bit int, a 64 bit double is used - so you won't get overflow.
In the calculations they're using ints because they don't want to use floating point, but we don't care. A lot of that random multiply/divide stuff could actually be taken out since it's only there to preserve accuracy when done on an integer system.
I guess it's possible that the calculations are actually relying on the fact that 32 bit integers will clip the number? Do you think it's possible that you could find the calibration and gas_res_adc/gas_range values that the Python code uses to get a certain result - and then we could feed those into the Espruino module and see where it goes wrong.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Espruino kind of does 64 bit - when you do something with two 32 bit integers it's done in 64 bits and then if it doesn't fit in a 32 bit int, a 64 bit double is used - so you won't get overflow.
In the calculations they're using ints because they don't want to use floating point, but we don't care. A lot of that random multiply/divide stuff could actually be taken out since it's only there to preserve accuracy when done on an integer system.
I guess it's possible that the calculations are actually relying on the fact that 32 bit integers will clip the number? Do you think it's possible that you could find the calibration and gas_res_adc/gas_range values that the Python code uses to get a certain result - and then we could feed those into the Espruino module and see where it goes wrong.