Sorry if this is a basic question, but I cannot find the solution
On a Lopy I am trying to do a calculation. I noticed when using a big number, the amount of digits behind the dot are capped off:
Python: (77.04876/360)+2451545 result 2451545.2140243333
Micropython: (77.04876/360)+2451545 result 2451545.0
When calculate with 2 instead of 2451545:
(77.04876/360)+2 result 2.214024
Is there a way to get the same output (number of digits behind the dot) as in Python?
Calculating with high precicion
Re: Calculating with high precicion
On MicroPython, floating point numbers are only 32-bit floats. On regular python, they're 64-bit.
Integers can be arbitrarily large.
Integers can be arbitrarily large.
-
- Posts: 3
- Joined: Tue Apr 05, 2016 7:49 pm
Re: Calculating with high precicion
Thank you for the reply!
When I add the calculation to a variable. Will the real value be used on further calculations or the rounded value?
When I add the calculation to a variable. Will the real value be used on further calculations or the rounded value?
Re: Calculating with high precicion
32 bit floats consist of 24-bits of mantissa (only 23 bits are stored), 1 bit sign and 8 bits of exponent.
24 bits can store about 6 significant digits (base 10).
So when you do: 77.04876/360 you'll get 0.2140244 When you then add 2451545 you're essentially throwing away your first result since 2451545 requires seven significant digits.
Just to further demonstrate. The number 9451541.0 will lose the last digit:
For a more detailed explanation, you should probably read:
https://docs.oracle.com/cd/E19957-01/80 ... dberg.html
24 bits can store about 6 significant digits (base 10).
So when you do: 77.04876/360 you'll get 0.2140244 When you then add 2451545 you're essentially throwing away your first result since 2451545 requires seven significant digits.
Just to further demonstrate. The number 9451541.0 will lose the last digit:
Code: Select all
>>> 9451541.0
9451540.0
https://docs.oracle.com/cd/E19957-01/80 ... dberg.html
-
- Posts: 3
- Joined: Tue Apr 05, 2016 7:49 pm
Re: Calculating with high precicion
Thanks again!
I was using this for calculating sunset and sunrise (for streetlights). Reading all this I think it is much better to make a dictionary with sunset/sunrise times on my pc for one year, and use that instead (using Ephem). I understood there are some variations per year, but there is no problem when the table is a few minutes wrong.
I was using this for calculating sunset and sunrise (for streetlights). Reading all this I think it is much better to make a dictionary with sunset/sunrise times on my pc for one year, and use that instead (using Ephem). I understood there are some variations per year, but there is no problem when the table is a few minutes wrong.
Re: Calculating with high precicion
You can also do the calculations in scaled (fixed-point) integers -- they can be arbitrarily large.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Calculating with high precicion
Astronomical calculations use a lot of trig and do tend to require high precision. I think a small dictionary or list generated on a PC is the best way (perhaps producing a JSON or Pickle file), with interpolation done on the microcontroller.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.