Accuracy of Extrusions

[JimCarruthers]

@Joe_Garcia

While I appreciate your concern I am doing this as more of an experiment because these errors will pile on. Even if it only affects only the 8th decimal place, scaling to other units does make these issues more apparent. I just want the assurance and peace of mind that my model is as precise as the computer will allow.

No they won’t pile up, are you going to be round-tripping geometry millions of times? And don’t think the methods you’re using to try to measure these infinitesimal “errors” are actually finding them, they’re just showing you their limitations. Don’t forget the numbers all have to be converted from base-10 to base-2 and back, and that varies in accuracy wildly across the number space.

Some incredibly major CAD systems used to just model everything internally with a fixed units and tolerances and pretend to offer units options. Rhino’s as accurate as anything.

[Joe_Garcia]

They actually might. Let’s say I modelled in meters and got a length in the editor of 100.00000 when the actual length is 100.0000099999999. So then let’s say I convert to millimeters. You’ll get a value around 100000.001 which is far less accurate now.

Edit: It appears that I reached my maximum number of replies on this thread for today but thought I would mention this before I am able to post here again. I’m interested in solutions. I don’t really feel like debating the practicality, we are working with a computer and if it can handle the operation I desire with 15 digits of accuracy, I would like to keep that.

Edit 2: Well it appears like your advice conflicts with the other solution which was offered here. I understand what floating point errors are, but if Rhino is using the full 15 digits in calculations which are only accurate up to 8 digits because of the extrusion I mentioned, then that will just be added to the inaccuracy. I understand operations like complex intersections aren’t going to use that full double precision and that’s fine. I am not doing something complex, it’s just an extrusion. Additionally, Rhino does support these 15 digit values, it just changes once the extrusion happens. That’s the issue, I am looking for a solution, deflections don’t help.

Edit 3: Replying to Raymond’s reply in this slowing growing mega message. I was under the impression that Rhino considers 15 digits as the maximum number of significant digits. This is backed up by a script I made that bypasses the maximum display precision and will display above 8 digits. That would mean the numbers aren’t technically equal, even though they fit within the tolerance, the curves internally aren’t. Rhino can be accurate up to 15 digits which I have tried many times comparing results from a high precision calculator to the length given by the script, it only changes it’s accuracy when an extrusion happens. Anything past 8 digits once extruded is just gibberish and doesn’t match the previous result from the script or high precision calculator. I have been using extract wireframe but I could try using that other command, maybe extract wireframe obeys only 8 digits of tolerance?

Edit 4: I thought I should give some ‘proof’ about the precision just to settle the debate. I recreated my example just for the fun of it. Not a rounding error, those numbers are definitely different and Rhino does use the full double floating point value in calculations.

As for extract wireframe; I will try the other method now.

Edit # who cares anymore: Good and bad news, I found the problem. The good news: the issue is with ExtrudeCrv + Cap it rounds whatever the 15 digit value is up to 8 digits and replaces the remaining 7 digits with noise (or whatever it really is ). The bad news is that this is a problem with the tool itself, are there any work arounds to force it to use 0.0 as the tolerance, I think it is built into the tool and doesn’t adopt the user set tolerance? Interestingly, this only happens with polysurfaces, solids are actually perfectly accurate. I tried it with a rectangle and the numbers check out for the solid, rounding is only with the polysurface.

[JimCarruthers]

You’re missing the point. It’s not gonna “actually” be off by whatever, that measurement will be a rounding error from converting to and from base-2. You’re fretting over meters to mm and completely missing that, which happens to absolutely every single number with every single operation.

There’s no “solution,” you are chasing ghosts. Rhino is as accurate as any other CAD system, and unlike many of them lets you actually set the actual modeling tolerances.

[RaymondH]

Those two numbers are equally precise in that they have the same number of significant digits. I mean they’re the same number since 0.999… is exactly equal to 1, so there’s literally no issue there in that example. And if you consider both numbers to represent some physical quantity like length, just in different units, they still both express the same quantity.

Also… Correct me if I’m wrong I’ve never used it before but… Is extractwireframe grabbing the render mesh edge? What happens if you get the length by dupedge?

[jsb.walker]

I have no particular dog in the race regarding this accuracy issue, however I did want to point out that the command extractwireframe could actually be extracting geometry off of the render mesh which is an approximation of the actual geometry.

[davidcockey]

@RaymondH

Also… Correct me if I’m wrong I’ve never used it before but… Is extractwireframe grabbing the render mesh edge? What happens if you get the length by dupedge?

@jsb.walker

however I did want to point out that the command extractwireframe could actually be extracting geometry off of the render mesh which is an approximation of the actual geometry.

Based on the results of the List command which outputs the parameters of the selected objects: the input circle, the result of DupEdge for the edge of the extrusion coinciding with the input circle and the circle from ExtractWireFrame are exactly the same to 15 decimal digits in the test I did.

[John88 (John)]

Interesting, I’ve been following this thread and am interested in where it goes. Am I missing something? The list command only gives a few decimal places? How do I see all of them?

[dale (Dale Fugier)]

How accurate is Rhino?

[davidcockey]

@Joe_Garcia Please post a .3dm file with your geometry including the input circle and the extracted wireframe. Also please post your Python script used for obtaining the full 15 digits. Is that script applied separately to obtain the length of the input circle and the length of the wireframe circle, or does it obtain both in a single application?

@Joe_Garcia

The bad news is that this is a problem with the tool itself, are there any work arounds to force it to use 0.0 as the tolerance, I think it is built into the tool and doesn’t adopt the user set tolerance?

This has nothing to do with the absolute tolerance setting. The absolute tolerance setting does not affect how numbers are stored in Rhino, nor the accuracy of the mathematical operations. The absolute tolerance setting only affects how many control points Rhino uses when it needs to determine an approximate solution because an exact solution is not possible using NURBS. That is not the situation here.

[davidcockey]

@John88

The list command only gives a few decimal places? How do I see all of them?

I am looking at the coordinates of the center, start point and end point of the circles which are given to 15 digits. Results from my test for the input circle, circle from DupEdge and circle from ExtractWireframe:

Rhino object: curve
DEVELOPER DEBUGGING INFORMATION ONLY
Use the Rhino “What” command.
Runtime serial number: 312
name: “”
id: 527C82BA-8BB6-4502-B066-96945A13B863
layer index: 1
render material index: -1 (from layer)
ON_ArcCurve: domain = [0,75.3982]
center = (-92.099084111225679, 100.98308466768073, 0)
radius = 12
length = 75.3982
start = (-80.099084111225679, 100.98308466768073, 0)
end = (-80.099084111225679, 100.98308466768073, 0)

Rhino object: curve
DEVELOPER DEBUGGING INFORMATION ONLY
Use the Rhino “What” command.
Runtime serial number: 2767
name: “”
id: EFA36893-0B47-4326-A1AD-B244835A3156
layer index: 6
render material index: -1 (from layer)
ON_ArcCurve: domain = [0,75.3982]
center = (-92.099084111225679, 100.98308466768073, 0)
radius = 12
length = 75.3982
start = (-80.099084111225679, 100.98308466768073, 0)
end = (-80.099084111225679, 100.98308466768073, 0)

Rhino object: curve
DEVELOPER DEBUGGING INFORMATION ONLY
Use the Rhino “What” command.
Runtime serial number: 2781
name: “”
id: FB2ECD9F-327F-4362-9C15-5D3FFBD4F34A
layer index: 7
render material index: -1 (from layer)
ON_ArcCurve: domain = [0,75.3982]
center = (-92.099084111225679, 100.98308466768073, 0)
radius = 12
length = 75.3982
start = (-80.099084111225679, 100.98308466768073, 0)
end = (-80.099084111225679, 100.98308466768073, 0)

[John88 (John)]

I think the start and end values are just where you positioned the arc upon activating the tool. if you move the arc tool and lock it to an axis and type a distance you will see those values match. I think the main issue is with the length value.

[davidcockey]

@John88

I think the start and end values are just where you positioned the arc upon activating the tool. if you move the arc tool and lock it to an axis and type a distance you will see those values match.

One arc/circle is the input circle which I created. The others were obtained from the extruded object. If the extruded object is only single precision then the circles derived from it would have slightly different start and end points.

[John88 (John)]

That’s an interesting way of going about it actually. Is there anyway to measure the length? OP mentioned a script??

[davidcockey]

@John88

That’s an interesting way of going about it actually. Is there anyway to measure the length? OP mentioned a script??

He uses a script, but has not posted it yet, nor his geometry.

[JimCarruthers]

@Joe_Garcia

The good news: the issue is with ExtrudeCrv + Cap it rounds whatever the 15 digit value is up to 8 digits and replaces the remaining 7 digits with noise (or whatever it really is ). The bad news is that this is a problem with the tool itself, are there any work arounds to force it to use 0.0 as the tolerance

That’s not what’s going on at all. The dimensions of extrusions are not “rounded off” to 8 digits, that makes no sense, why would it do that? That’s not even how single-precision works, they’re like not-quite-7 digits.

What you’re seeing are just rounding errors going between base-10 and base-2(the accuracy of which is NOT CONSTANT! Some numbers work better than others!) that aren’t quite small enough to get just rounded to 0(based on an internal “0” tolerance you can’t change)in that report.

Please select appropriate units and tolerances at the beginning of your project so that you are working with at most about 7 or 8 significant digits, and do not willy-nilly change from M to MM as that’s just kinda dumb, there’s no reason to do that for any purpose, the output can be whatever units you want.

The ability to see umpteen digits in normal measurements was taken away exactly because of misunderstandings like this generating spurious support requests. Math on a computer is not, in fact, exact. It’s not as exact as “15 digits” looks, at all. Get over it.

[davidcockey]

Notice - The following is informed speculation based on the results of experiments in Rhino.
It may be partly or completely incorrect.

Rhino has a special object type for arcs and circles. Arcs and circles can also be represented exactly by rational NURBS. When the Arc or Circle command is used the result is an arc/circle type object.

What may be going on is Rhino using different methods for length calculations for the length of the input circle vs the length of the extracted edge. The length of an arc/circle the length can be calculated directly by formulas. The length of a general NURBS curve requires quadrature (numerical intergration). The latter method in general will be approximate with the accuracy dependent on the number of increments/increment size. Speculation - The accuracy of this method of length calculation may have the accuracy hard coded to eight decimal points or so.

Rhino can store the results of results of ExtrudeCrv, etc. as either regular NURBS surfaces/polysurfaces, or as “Extrusions” (aka “Lightweight Extrustions”). The geometry and precision is exactly the same. The difference is the size of the storage space. The Extrusion type takes advantage of the way an extrusion is defined.

UseExtrusions determines if the result of ExtrudeCrv, etc will be stored as a regular NURBS surface/polysurface, or as an Extrusions. Extrusions can be converted to NURBS surfaces/polysurfaces using ConvertExtrusions.

It appears that the when the edge of an Extrusion is extracted by DupEdge or ExtractWireframe the result is a rationale NURBS curve object, not an arc/circle object. The rational NURBS curve object has exactly the same geometry as the arc/circle type object. Length calculations for this type of object will be approximate.

It appears that in some instances when the edge of a NURBS surface/polysurface which is exactly an arc or a circle is extracted the result is an arc/circle type object. Length calculations for this type of object can be “exact” (within the limitations of double precision floating point arithmetic.)

[John88 (John)]

I think you should hop off this thread if you can’t keep your cool about this. Excusing a technical issue by saying “that’s just kinda dumb” isn’t being all that helpful or productive, and is incredibly condescending. I found this thread and was curious about it, but what people have shown is that it isn’t just base-10 to base-2 rounding errors. I don’t see how digits past 8 can be converted into meters and can be seen in the new calculations if the computer just doesn’t care about those values. Also, floating point errors usually account for really small values, like 3.000000000000001 or 2.999999999999998 or so on. I haven’t seen many that got past this range. What would be a rounding error is if, according to Joe’s example, got 100.00001. I recreated the same process and value and that is exactly what i got when i extruded the curve. If the computer can’t possibily be exact, why does it have accurate values up to 15 digits but then changes once an extrusion is intruduced? Other tools don’t behave this way besides complex operations that require more intricate calculations. This is just a box in this example.

[JimCarruthers]

@John88

I think you should hop off this thread if you can’t keep your cool about this. Excusing a technical issue by saying “that’s just kinda dumb” isn’t being all that helpful or productive, and is incredibly condescending. I found this thread and was curious about it, but what people have shown is that it isn’t just base-10 to base-2 rounding errors. I don’t see how digits past 8 can be converted into meters and can be seen in the new calculations if the computer just doesn’t care about those values

How about you actually post your file and code that’s apparently showing this “technical problem.” If no one can reproduce it, no one can fix it.

In the meantime, here’s Tom Scott talking about floating-point math.

Floating Point Numbers - Computerphile

[Joe_Garcia]

Alright folks as promised here is a demonstration of what is happening here.

I think @davidcockey makes a very interesting theory about this subject. In regards to floating point errors @JimCarruthers mentioned, there is a slight error on the extracted wireframe, ranging from very small values that shouldn’t change the value that much. Here is one point value, 23.999999999999989, which represents the greatest difference between any of the other points values. It’s intended to be 24 mm and keep in mind, the original circle does have this at exactly 24 mm. What I find most interesting is that the 8 significant digits stays consistent across all other circle sizes. The original circle retains the full 15 digits of precision which is expected.

Here is the file:
demonstration.3dm (82.0 KB)

And here is the Python script (not a developer so excuse any mistakes):
curve_length.py (292 Bytes)

I appreciate everyone commenting trying to resolve this.

[Willem (Willem Derks)]

Hi Joe

I tested your file and script output.
My observations:
Creating an extrusion and extracting the wireframe → No difference in length

Creating the extrusion, capping it and extracting the wirefame → different:

75.3982238595306000
75.3982236861550000

that is a difference of

00.0000001733755539

To put that in perspective, it represents ( if my calculations are correct) about 92 mm of the total earth’s circumference (40.075.000.000 mm)

That is a really tiny fraction.

What happens is that the Cap functionality creates a new polysurface, where the cap is created by a planar rectangular surface. That surface is being trimmed and a new edge is created representing the edge where cylinder and cap touch. That edge is off by a factor of ~0.0000000023 from the original edge.

-Willem