Not sure what levels are acceptable in these cases, but it’s also something fundamental everything that deals with floating point numbers has. (And also the reason that money calculations are never done with floating point numbers).
You can observe similar behaviour in any other software - autocad, revit, inventor, excel.
A lot of software uses floating points - because they’re fast, and accurate enough for most applications. But floating point numbers are only accurate up to 15-16 digits.
As a seperate problem: certain operations will have larger deviations than others. Offsets, solid booleans, curve and surface intersections will most of the time be an approximation (that’s where the angle and absolute tolerances come in).
As a programmer, I’ve come to accept this as a fact of life. Every floating number has a finite amount of precision. That’s why in software you often don’t check if a number is exactly one, but if it’s really close to one.
Floating-point error mitigation is the minimization of errors caused by the fact that real numbers cannot, in general, be accurately represented in a fixed space. By definition, floating-point error cannot be eliminated, and, at best, can only be managed.
The main problem here is that those unwanted deviations happen during moving or rotating of objects with whole numbers, or when setting the origin of a CPlane via Grid snap. For example, when I move an object by 120 mm, the expectation is that it will really move by the same distance instead of some random number such like 119,999999999952 mm.
The same goes for building a bounding box from an object with a pretty simple shape and size of a whole number. If my object is 20x20x20 mm large, it’s against any logic that its bounding box is slightly larger or smaller.
I had cases where I copy circles to other CPlanes, then I figured out that the copies were no longer true circles as their diameter was variable.
Sometimes I also notice that making curve fillets will produce a slight discontinuity between the fillet and the original curves. It’s like 0,000000009 degrees, but is still there. This happens mostly on CPlanes. Another way to produce deviations of this type is to use the ! _Line _Tangent _Pause command.
There was some other topic where I pointed that deviation in the past and thankfully it was quickly fixed for 99% of the cases, but the bug is still there from time to time.
Most decimal fractions cannot be represented exactly as binary fractions. Thus, the decimal floating-point numbers you enter are only approximated by the binary floating-point numbers actually stored in the system. Fortunately, the deviation is usually very small and well within any reasonable tolerance.
About 3 years ago Rhino 7’s Gumball displayed 16 digits behind the decimal comma (dot) for the distance for moving the objects by its arrows. now it shows only up to 7 digits behind the decimal comma (dot). I wish that the Display precision from the “Rhino options > Units” menu could be set to 16 digits, too.
It really doesn’t matter if you’re using whole numbers or decimal numbers. You’re always using floating point arithmetic if that’s what the underlying software has chosen to do. It seems like the implementation of CPlanes has included a few extra floating point operations somewhere and introduced some infinitesimal level of error. That’s the trade-off we all make to do things in the digital realm, we just have to make do with the fact that the numbers 0.1 and 18,014,398,509,481,983 are unrepresented using float64.
Wow, it’s crazy that I just created an object using Grid snap and now that you introduced that test command, I figured out that Rhino is still doing some sort of secret deviation. Here is a comparison between both modes:
It appears there are two different types of issues reported in this thread, one directly linked to the limitations of double precision floating point values and math, and the other having an unrelated cause.
The first issue is discrepancies in the 14th, 15th or 16th digits between the reported and expected values of coordinates, measurements, and related, with the modeling using custom Cplanes. An example is
These discrepenencies are almost certainly due to a combination of the use of double precision floating point values and math, and the coordinate transformations which occur when custom Cplanes are used. I discussed this in post #8 above. (Note that if higher precision values and math were used, such as Quadruple-precision floating point, there would continue to discrepencies with exact values in the least few decimal digits.)
The second issue is discrepencies in the 5th, 6th or 7th digit after the decimal between measurements made with or the boxes created using the BoundingBox command and the expected values. These discrepencies are too large to be caused by the use of douple precision precision values and math. However the discrepencies appear to be small than the absolute tolerance setting used. Similar discrepencies have been previously reported; for example Finding the lowest and highest points in a surface - #25 by davidcockey
Based on tests described below It appears that BoundingBox uses an approximate method for curved objects, likely involving mesh repesentationw of the objects, and the current accuracy of this method is better than 0.0001. It may be possible to improve this accuracy at the expense of increased computational time and possibly memory use for complex objects and sets of objects.
To test BoundingBox I created geometry with pairs of rectangular blocks, one pair with sharp edges and the other pair with filleted edges. The blocks were created using the World coordinate system, and then copied and oriented on a custom Cplane. BoundingBox test DC01.3dm (2.2 MB)
This issimilar to what Gjis used as an example in https://mcneel.myjetbrains.com/youtrack/issue/RH-81124.
I used BoundingBox to obtain the overall dimensions of the pair of sharp edge boxes and the pair of filleted edge boxes results in the dimensions for both pairs of boxes in both orientations.
The result for the sharp edge pair of boxes oriented on the World Cplane is exact. The result for the filleted edge pair on the World Cplane is within the expected accuracy of double precision floating point arithmetic as is the sharp edge pair on the custom Cplane. Discrepencies are in the 15th, 1th or 17th decimal digit.
The result for the filleted edge pair on the custom Cplane have discrepencies in the 5th digit after the decimal. This is much larger than discrepencies associated double precision floating point values and math. This is likely due to BoundingBox using an approximate method for curved objects, likely involving mesh repesentationw of the objects, and the current accuracy of this method is better than 0.0001. It may be possible to improve this accuracy at the expense of increased computational time and possibly memory use for complex objects and sets of objects.
The discrepencies in the results of BoundingBox can be large enough to become significant in some situations when modeling with a tolerance of 0.0001 or similar.
The discrepencies due to the use of double precision floating point values and math will never have any effect on any real world geometry. A discrepency in the 14th decimal digit is equivalent to an discrepency on the order of 0.0001 mm in the distance from New York to London. An error of 0.0000000001 mm or 1/10000 of a nanometer is 1/4000000 of the wavelength of light.
Note that the “far from origin” display problems which have occured with previous versions of Rhino are due to the use of single precision values in the graphics pipeline, are not related to the accuracy of the underlying geometry which is double precision.
Yes, sort of. BoundingBox includes everything including the render meshes, and since these are single precision, the result is less precise than what you expect.
Rhino supports both single and double precision meshes. But there are a few places that single has to be used.
Even with double precision the math can get odd as @davidcockey points out above. If the number has to be squared those reliable significant digits can get even less.
That is one of the real reasons for a settable tolerance. The tolerance needs to be set to keep the model and the calculations within 8-12 significant digits.
Bounding box is primarily used for modeling and engineering purposes (and also getting overall dimensions, align objects, distribute objects), hence it must be very accurate, even if that means that the calculations will be a bit slower (like 1 second slower).
Due to these issues with incorrect coordinates in Rhino caused by the limitations of the decimal numbers and the bounding box, I will repeat my proposal for creating a new “Snap to nearest coordinate” tool, which I posted in this topic:
