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.
How about if you represented it as mm instead? 18329846.283746mm
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.