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!

]]>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!

]]>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.

]]>