# How much numerical precision can the ESP8266 achieve?

Background: I am trying to port this solar tracker code by Gabriel Miller to run on the ESP8266. Now I'm not a particularly great coder, but I'd like to give it an honest try.

As of recently, the ESP8266 can be natively programmed using the Arduino IDE and code base. Which is pretty convenient.

SO. The solar tracker code written by Gabriel works on the Arduino Uno and the Arduino Mega. The Mega version of the code has a high-precision calculation library called 'BigNumber' to calculate the Sun's position in the sky to a pretty precise degree. My question is:

From what I've read, the ESP8266 is supposed to be a 32-bit microprocessor, so (I assume?) it should be able to handle high-precision numbers without using the BigNumber library; so, how do I check what's the highest numerical precision that the ESP8266 can support? That way I could theoretically just copy the equations over to the ported program rather than having to rewrite the BigNumber library.

• If anyone with a better grasp of C code and Arduino and such wants to give it a shot, be my guest. Give a shoutout to the code author Gabriel Miller for creating a pretty awesome bit of Arduino code. – Boloar Jul 23 '15 at 11:29

I ported the BigNumber library to the Arduino in 2012. The BigNumber library is based almost entirely on the GNU "bc" library. What it does is store numbers with arbitrary precision (ie. as large as you like, and with as many decimal places as you like).

For example, on the Uno you can calculate 3160 like this:

``````3^160 = 21847450052839212624230656502990235142567050104912751880812823948662932355201
``````

Or, the square root of 2 to 100 decimal places:

``````sqrt(2) = 1.4142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727
``````

It's up to you how many decimal places you want. However the trade-off is RAM and speed. The more precision, the more RAM and the slower it is.

A normal precision float (like on the Uno/Mega) has around 7 decimal digits of precision. A double float has around 16 decimal digits of precision. See Wikipedia - Floating point.

If the ESP8266 has a C++ compiler then you could probably convert the BigNumber library without too many issues. However if it supports double-precision floats you may not need to.

How do I check what's the highest numerical precision that the ESP8266 can support?

You may want to ask on the ESP8266 Community Forum - they may be able to give you a more helpful answer.

### Reference

• Hey, Nick, thanks for your reply! I believe it is a C++ compiler since it uses the Arduino code base, but I don't know the C language well enough to effectively port the library on my own. I tried including the BigNumber library in an empty arduino sketch and compiling and it put out about 8 errors in a single file “numbers.c” saying "undefined reference to ‘exit'" and “undefined reference to ‘ctype_ptr’”. That's all of the errors. I'm not sure how to clear that up. – Boloar Jul 24 '15 at 9:40
• I've posted in the ESP8266 forums. Waiting for a reply. – Boloar Jul 24 '15 at 9:45
• I asked at the ESP8266 forums and somebody got it working. All good! But, according to the creator of a solar tracker code, it might not really be necessary if the ESP8266 compiler is built to handle double-precision numbers. At any rate: Success! – Boloar Jul 30 '15 at 17:07

There's not really any difference in numerical precision. What you do get with 32-bit though is faster operations on larger data types.

For instance, to add two 32-bit numbers together (uint32_t) would take many operations on an 8-bit CPY, whereas on a 32-bit CPU it would just take a couple (only one to do the actual addition - a couple to load/save the values to memory).

One key difference, though, is that (to save space) the AVR system has double precision float values turned off and aliased to single precision float values. This is purely a software feature and has nothing really to do with the hardware. On 32-bit systems that is normally not done, so you can use `double` instead of `float` to increase precision.

However: While `double` is more accurate than `float`, it is still not precise. All floating point values, regardless of precision, are only ever an approximation. For that reason it is often preferred to use integer mathematics, and that is where libraries like BigNumber come in handy. They allow you to (as the name suggests) work with much bigger numbers, which is good when dealing with integers when you want a high precision.

For instance, you could measure distance in km. Say something is 18.329846283746km away. You could store that as a single precision floating point value and it would end up as 18.329845428467. As a double precision it would end up as 18.3298462837, which is closer, but still not right.

So you could represent it as meters instead of km. So your 18.329846283746km would be 18329.846283746m.

Say, why don't we go smaller? Micrometers? 18329846283.746µm

I don't like that decimal point still. What's smaller than µm? nanometers of course! That would be 18,329,846,283,746nm.

Oh look, we have an integer value. However that integer value is too big to fit in a 32-bit number even, which has a maximum of 4,294,967,295. You could try using a 64-bit number (uint64_t) if the compiler you have supports it, which on both 8-bit and 32-bit systems would need multiple operations to work with (though less on the 32-bit), or you could use a library like BigNumber to deal with it all for you.

By using that method you start out by stating "I want to work in this fixed resolution and I want 100% precision within that resolution", rather than saying "I want to work with these values and I hope you'll get it vaguely right", which is far from ideal.

Also working with integer values is generally considerably faster than working with floating point values unless the CPU has a floating point unit available to do the heavy work for you.

So the difference between an 8-bit and a 32-bit system has nothing to do with the precision that is available to you, but everything to do with how fast operations at different precisions take to perform.

• Clearly my learning material was lacking. This makes sense, I'd never thought about it like this. I generically assumed more bits = more precision which I guess is technically true but clearly not as simple as I thought. Thanks. – Boloar Jul 24 '15 at 9:29