Accuracy

Every now and then we get nervous about the results we see in schedules or in dimensions. I received an email a few months ago asking about an error they observed in the length of a wall. They exported from Revit so they could examine the model against others with Navisworks. They saw a wall that is 10 meters long reported a length of 10.000000000001 meters in Navisworks. That extra one would need a lot of friends to add up to something we could actually see with our eyes. It's still worrying?

A thread at RFO today popped up regarding the accuracy that dimensions were showing. In this case the project units were adjust to 12 decimal places too. The dimension was reporting extra info in the 12th digit too. I replied there that it's a floating point math issue. I also wrote that I believed that Revit only calculates to six digits places but limits displaying values to 12 digits. I was wrong and you'll see what Leonid explains if you follow the link in a moment.

Chris replied with some great links, one of which I remembered reading but couldn't recall where (AUGI naturally) at the time. This is one where Leonid and Irwin weigh in on Accuracy (Revit Founders).

Regarding that thread at AUGI I particularly liked Irwin's explanation of the magnitude of the error being discussed. He wrote:

...The difference you are seeing is approximately one part in 10 to the 14th power -- it is around one ten thousandth of the diameter of a hydrogen atom. Revit uses double precision numbers for all calculations (as do all CAD systems), and they are only good to around 14 or 15 digits.

Regarding your concern about angles, if an error of this magnitude were introduced into the angle between two walls, and the length of the walls was the distance from the Earth to the Sun, then the error in the distance between the ends of the walls would be around 1 mm...

These are the other links that Chris shared:

Lahey - Floating Point
Double Precision floatin Point format - Wikipedia
What Every computer Scientist should Know about Floating-Point Arithmetic. Warning Chris says it may hurt your head!

From the Lahey site I found this snippet interesting (with my added emphasis):

...Floating-point representations and arithmetic are inexact, but I don't believe that is particularly troublesome to most programmers. Many input values are measurements, which are inherently inexact, so the question about the output values isn't whether there is error, but how much error should be expected...

And this (keeping in mind these are written from a programmer's viewpoint):

1. Only about 7 decimal digits are representable in single-precision IEEE format, and about 16 in double-precision IEEE format.
2. Every time numbers are transferred from external decimal to internal binary or vice-versa, precision can be lost.
3. Always use safe comparisons.
4. Beware of additions and subtractions that can quickly erode the true significance in a result. The computer doesn't know what bits are truely significant.
5. Conversions between data types can be tricky. Conversions to double-precision don't increase the number of truely significant bits.Conversions to integer always truncate toward zero, even if the floating-point number is printed as a larger integer.
6. Don't expect identical results from two different floating-point implementations.

My general observation is that it is much more complicated than we think it is to codify the stuff we take for granted, so called simple things like a dimension of 4'-0" or an area value like 12.53 SF.