double precision float on ESP8266

[glubuluck]

Hi all,
i'm planning to realize an astronomical clock (to compute moon, planets positions, rises and sets and so on..)
I definitely need to use 64bit double precision math functions, since the equations are running on long times. (big angles in sinus, cosinus...)
i firstly planned to use a raspberry pi 1 (in python), but i recently discovered the esp8266, and, compared to the RPI, i'm really attracted by it cause of :
- the really low power need (since it'll be on power, night and day)
- the fast booting time (the clock has to be ready quickly if unpowered)
(i don't need network. the clock (time) setting is done by a gps module.)

But i found out that micropython doesn't support 64bit double prec float...
Is that a soft or hard limitation ? is there is a way to workaround it ?

Thanks a lot for answering
Matthieu, Brussels

[ThomasChr]

Hardware floating point only means "floating point in hardware". Micropython can do any floating point in software. This will be considerably slower for a CPU, but as a human you won't notice any difference in speed.

[jimmo]

Hardware floating point only means "floating point in hardware". Micropython can do any floating point in software. This will be considerably slower for a CPU, but as a human you won't notice any difference in speed.

It's true that if you use "double" in C even without hardware support for double precision (or even any hardware float at all) the C compiler will fill in for you.
However on ESP8266, MicroPython sets MICROPY_FLOAT_IMPL to use float (not double), so everything will be done in single precision. (i.e. mp_float_t is typedef'ed to float)

[Roberthh]

Even trying to compile the firmware with double precision fails. However, the firmware for ESP32, PyBoard and Pybord D can be built with double precision floats.

[glubuluck]

Ok,
so i guess i have to give up with esp8266.
for the esp32, i don't think i have enough knowledge to do it.. i'll stick with the RPI as a starting point.
thanks for answering
Matthieu

[Roberthh]

Micropython for ESP32 is not different to that for ESP8266. It is only faster and has more RAM. Only you have to build the firmware with double precision float yourself, since there are not suitable pre-built images. People (like me) here can help you to get such an firmware image.

[glubuluck]

Micropython for ESP32 is not different to that for ESP8266. It is only faster and has more RAM. Only you have to build the firmware with double precision float yourself, since there are not suitable pre-built images. People (like me) here can help you to get such an firmware image.

Just to be sure to understand: it's possible to compile the firmware with double precision float for ESP8266 or 32, but it'll fail on the 8266 because of the lack of RAM/Flash, that's it ?

[Roberthh]

It is NOT possible to compile the firmware for the ESP8266 with double precision floats, at least with the actual repository.
It IS possible to compile the firmware for the ESP32 with double precision floats. I did that before I sent my fist response, just to be sure. One the build environment is set up, building and flashing take about a minute. And you do not have to do that often.

[ThomasChr]

Just a question: Why do you think you need double precision?
I think most calculation are accurate enough with single precision floating point.

[glubuluck]

Roberthh :
ok then i'll purchase an esp32 to try this. Thanks for helping!

ThomasChr :
actually i first planned to do this using arduino. And i found out that "single" float was really not enough. That made me move for Python.
For example, in astronomical computing, the date/time are expressed in "julian day" https://en.wikipedia.org/wiki/Julian_day. In this unity, January 1, 2000 12hUTC, is 2 451 545.0
Since 32bit float has only 7 significative digits, the precision is around 1 day... and i need the second at least.
The problem occurs also for big angle computation where the error is growing up with time.
And also, there is a lot of successive calculations, with error added to the previous and again...