## Arduino vs Significant Figures: Floating Point Calculations

Herewith, to nail down the reasons why you can’t (or, perhaps, shouldn’t) use Arduino `float` variables, a small collection of DDS-oid calculations.

Remember that `float` and `double` variable are both IEEE 754 single-precision floating point numbers:

```Size of float: 4
double: 4
```

The Arduino floating-point formatter gags on some values, although they calculate correctly:

```2^24: 16777216.000
printf:        ?
2^32: ovf or ovf
2^32: ovf
2^32 / 256: 16777216.000
```

Don’t add values differing by more than seven orders of magnitude and suspect any results beyond the first half-dozen significant figures:

```Oscillator steps: HzPerCt
Oscillator: 125000000.00
-25 -> 0.02910382461
-24 -> 0.02910382461
-23 -> 0.02910382461
-22 -> 0.02910382461
-21 -> 0.02910382461
-20 -> 0.02910382747
-19 -> 0.02910382747
-18 -> 0.02910382747
-17 -> 0.02910382747
-16 -> 0.02910382747
-15 -> 0.02910382747
-14 -> 0.02910382747
-13 -> 0.02910382747
-12 -> 0.02910382747
-11 -> 0.02910382747
-10 -> 0.02910382747
-9 -> 0.02910382747
-8 -> 0.02910382747
-7 -> 0.02910382747
-6 -> 0.02910382747
-5 -> 0.02910382747
-4 -> 0.02910383033
-3 -> 0.02910383033
-2 -> 0.02910383033
-1 -> 0.02910383033
+0 -> 0.02910383033
```

The Arduino source code as a GitHub Gist:

1. #1 by scruss2 on 2017-05-23 - 11:33

… all the above, plus the huge amount of memory that the Arduino FP library uses. Adding relatively small numbers is always a great way of gaining fuzz with any finite-precision FP implementation.

You can use “long long” to get 64 bit integers on AVR. But there are no I/O routines that work with them. ARM Arduino uses 64 bit FP, but if you need 5 V analogue I/O, nae luck there pal.

2. #2 by scraimer on 2017-05-24 - 01:12

There’s some great stuff about this in John Farrier’s talk from CppCon 2016 Demystifying Floating Point. I think my favorite bit of information is how he breaks down the number of distinct values in various ranges (slide 28):

There are 1,036,831,949 values between 0.0 and 0.1
There are 8,388,608 values between 0.1 and 0.2
There are 8,388,608 values between 0.2 and 0.4
There are 8,388,608 values between 0.4 and 0.8
There are 8,388,608 values between 0.8 and 1.6
There are 8,388,608 values between 1.6 and 3.2

Notice how the ranges keep doubling in size but the number of distinct values remains the same? For simplicity, I’ll round 8,388,608 to be 10 million. So 10 to the power of 7. Or 7 decimal digits.

But between 1.6 and 3.2, if I wanted to show all the number with 7 decimal places, I’d run into trouble. Just between 2.0000001 and 2.9999999 there are ten million distinct numbers with 7 decimals. I’ve used up all of my precision, and I still haven’t covered the ranges 1.6 to 2.0 and 3.0 to 3.2!

• #3 by Ed on 2017-05-24 - 19:50

The float spacing thing turns up with depressing regularity on the OpenSCAD mailing list, when folks think floats would represent solid geometry better than the current library’s arbitrary-precision numbers. The grid defined by possible floating point numbers gets larger as the coordinates get farther from the origin, so you can’t exactly represent some vertex positions. That gets worse after a few rotations, whereupon even a model with exactly correct coordinate becomes non-manifold.

Integers don’t work, either, even when you use microns: the true vertex coordinates stop being integers after one rotation, the approximations diverge, and the model falls apart.

Floats may be faster, but there just aren’t enough of them for solid modeling!