Wrong dimensions

[Newdoji]

Hallo everybody,

I have a issue with dimensions. I draw a 113,5 x 78 mm rectangle then i did the extrusion command. When i take the measure tool it give me 113,500000000000142 mm (with all decimals on).

 I am verifying all my sketches and they have all that problems so everything i did over the last weeks is wrong.....

Does anyone have an idea.?

[TheCADWhisperer]

What manufacturing process will you use to hold tolerance?

What measuring instruments will you use in the real world?

If you know that you have modeled correctly- then ignore.

If you are not sure - then Attach the file here.

[chrisplyler]

If it's less than one and a half TRILLIONTHS of a mm off, then I would probably just go with it, produce it, and then use a hand-held grinder to bring it back into tolerance before painting it.

Okay, I still AM curious why Fusion can't keep a nice, round number in its database, when a nice, round number was entered by the user.

[jeff_strater · Accepted solution]

@Newdoji - Fusion is a mathematical computer program.  Parts of the program use iterative algorithms when solving geometric operations.  In order to prevent those algorithms from running for extremely long periods of time, we have to insert the notion of tolerance into those algorithms.  Basically, we have decide when it's "good enough".  Because Fusion is intended for objects that are manufactured and are within a given range of sizes (it does not handle nano-scale or city-scale objects), we picked tolerances for those range of physical objects.  For the sketcher, that is 1.0E-6 CM, for BRep operations, it is 1.0E-9 CM.  If I counted zeros correctly, the discrepancy here is 1.0E-13.  You're getting nearly to the limits of machine precision at that point.  I think the mistake, here, is in reporting results to greater precision than Fusion can reasonably achieve.

I think you should listen to both @chrisplyler and @TheCADWhisperer and not worry about this level of discrepancy, as it doesn't really matter in the real world.  Oh, and @chrisplyler - you must be really good with that hand-held grinder...  I don't think I could get to trillionths of a mm accuracy with that tool 😀 

[chrisplyler]

The secret is a good, solid stance. If you don't have a good stance, it's going to be sloppy.

Oh...and make sure to have your assistant hold your beer.

[TheCADWhisperer]

---

@chrisplyler wrote:

Oh...and make sure to have your assistant hold your beer.

---

I'll hold the doughnuts while you concentrate on your work.

[lichtzeichenanlage]

Have you drawn the dimension or have you entered the value? The first might results like you have. 

[laughingcreek]

@jeff_strater , an observation and a question.

the observation-I thinks it's interesting that this effect happens when you enter a value with a decimal. (at least that's what it's doing for me.) so entering 78 returns the value 78, but entering 78.5 returns results like what the op is reporting.

and the question.  is there any chance of this causing the "near tangent/near planer" conditions that sometimes causes problems with certain commands like "combine"?

[jeff_strater]

@laughingcreek - "is there any chance of this causing the "near tangent/near planer" conditions that sometimes causes problems with certain commands like "combine"?".  In theory, no, because everything should be to those tolerances.  There are some that might be caused by the discrepancy between the sketch tolerance and the modeling tolerance, to be honest, but we have not seen very many cases where this is actually the case.  Especially in the "near tangent" cases, the modeling tolerance for tangency is pretty much the same as the sketcher, so we are generally OK for that.  But, of course, there  are always those corner cases...

[Newdoji]

Hallo

Thank you all very much for the answers. That's right, I  doesn t need the precision of a trillion of a mm, but I was scared that this will cause problems when I build assemblies where components depend on one another.
Now I know that  it will not impact my drawings and that's Ok for me

Again, thanks a lot for that great support:)

[chrisplyler]

I'm wondering if these discrepancies will stack? If each extrusion is off by 1.5 trillionths of a mm, and you stack up a trillion such components, will the height of the tower be 1.5 mm off?

And also, I still don't understand why the error exists. I get that there are algorithms in place to establish a tolerance. But why is the result spit out by those algorithms adding 0.0000000000000143 to a user input value that is a real number with a lot less significant digits?

[GRSnyder]

---

@chrisplyler wrote: I still don't understand why the error exists. I get that there are algorithms in place to establish a tolerance. But why is the result spit out by those algorithms adding 0.0000000000000143 to a user input value that is a real number with a lot less significant digits?

---

Because Fusion 360 represents everything with IEEE floating point. It's not an arbitrary-precision arithmetic system such as, for example, Python. Floating point has many counterintuitive features. For example, it can't represent the value of 0.1 exactly. 0.100000001490116119384765625 is as close as you can come.

Floating point values sometimes look "weird" this way because they're being displayed in base 10. Internally, they're stored in base 2, split into a value portion (the "mantissa") and a scale portion (the exponent). It's a lot like standard scientific or engineering notation, but in binary (e.g., "6.02 x 10^23"). Some things that are nice round numbers in base 10 are repeating decimals when converted to base 2, so they have to be rounded to be stored.

The underlying issue is performance. Arbitrary-precision arithmetic is orders of magnitude slower than IEEE floating point because CPUs and GPUs implement floating point in hardware.

[chrisplyler]

Okay, that makes sense. Thank-you.