Hello.
I notice a problem in rhino 8 when i use large coordinates.
In my example i start a simple polyline at point with coords: 474350,4203130 but when i evaluate my point i get: 474350.00000047,4203130.000004201
Why?
precesion_lost.3dm (47.3 KB)
1 Like
Great link!
I thought rhino makes double precision float calculations.
Thus I donât make any Mathematik operation here. I just start a line with integer coordinates at starting point.
It does store everything as double-precision.
Itâs still a rounding error going from base-10 to base-2 and back, the accuracy of that conversion is NOT what you expect, it varies. Itâs just noise, it means nothing.
People getting hung up on this issue is the reason that every other 3D app either secretly rounds this off, or works with a fixed maximum âworldâ size. Rhino is NOT âless preciseâ than anything else.
1 Like
Still donât understand why in a simple key in of integers I take floating numbers. No calculations take place here. In fact I can afterwards move by -0.00000047 and -0.000004201 and get the Integer numbers I need.
I am waiting for an answer from mcneel about this.
I think youâll get the same answerâŚ
2 Likes
Rhino only uses floating point numbers.
But 4,200,000 should be well inside the range of integers that double precision floating point can store accurately.
Iâm confused too ⌠
EDIT:
Unless youâre not using the World CPlane.
AFAIK, Rhino always stores World coordinates.
If your CPlane is different, than those numbers have to be transformed and they may change a little.
Thatâs why Rhino doesnât show you âfull precisionâ anymore, to avoid these questions about what is just noise, which every other program just hides from you.
Look up how to convert base-10 numbers into binary double-precision floating-point. MANY calculations take place.
Well, if I take the X coordinate
474350.00000047
and I try to find what part of the whole the last .00000047 is by dividing
0.00000047 / 474,350
I get about 1e-12.
Rhinoâs âZero toleranceâ is 2.3283064e-10 i.e. quite a bit larger than that.
https://developer.rhino3d.com/api/rhinocommon/rhino.rhinomath/zerotolerance
On the other hand, 1e-12 is still bigger than Rhinoâs âEpsilonâ value:
2.2204460492503131e-16
https://developer.rhino3d.com/api/rhinocommon/rhino.rhinomath/epsilon
what type of calculation rhino does when i key in an integer like 474350?
how its translated to 474350.00000047?
Points are still saved with double type.
If your document tolerance is say 0.0001 then it is still within tolerance.
It is all down to arithmetics with floating points, be they single or double float, and how computers can express those numbers in memory.
For fun do in Python using _ScriptEditor:
zerodotthree = 0.1 + 0.1 + 0.1
print(zerodotthree == 0.3)
This topic has been floating in this forum for a long time already, if you do a search for precision and floating point numbers and such youâll find many threads.
The Python snippet I posted is my favourite to quickly show that you should not rely on absolute equality when it comes to computers.
Your numbers are in the computer world, for all intents and purposes, exactly 474350 and 4203130.
Yes absolutely correct.
I made a copy of the line .00000002 meters to the right and then moved that copy .00000004 meters upward and then exported both lines as IGES format
This is the X,Y,Z data contained in the IGES file for those 2 lines.
474350.00000002D0,42003130.00000004D0,0.0D0,
474350.0D0,42003130.0D0,0.0
x.igs (2.3 KB)
Anybody that says Rhino canât report the data for those lines correctly is wrong.
Why Rhino reports the correct data when making an IGES file but reports the wrong data when queried by the user is obviously a bug.
When you analyze the start point of the line in Rhino it gives both the World and Cplane coordinates. Both are identically the same erroneous numbers for the X and Y coordinates.
1 Like
i am having same troubles. getting imprecise coordinates when working with whole numbers and even when close to origin.
Let me leave this with you.
Then please read thoroughly through Floating-point arithmetic - Wikipedia and come to understand that there are numbers that cannot be represented, especially after computation done on them, like evaluation of points.
Also, 1e-12 in say a millimeter model is⌠quite small. Even in a meter model that would be more precision than most construction methods will be able to give you.
I import the file in MicroStation and i report coords.
I get zeros in the 8 decimal place.
The i go boc to rhino and move the line by -0.00000047 in x and by -0.000004201in y. Now rhino reports all decimal as zeros
I import again in MicroStation and i report coord.
But in MicroStation i see the differences of -0.00000047 in x and -0.000004201in y.
Isnât obvious that rhino when i key in integers, correct store integers but wrong report floats?
The evaluate point report wrong coords on large numbers.
There is a possibility we have a bug in our code that attempts to convert a large number into a piece of text with a bunch of values after the decimal point. Weâll get this on our list to take a look.
Change your code to this:
zerodotthree = 0.1 + 0.1 + 0.1
print(zerodotthree - 0.3)
The printed result demonstrates that Rhino is capable of reporting numbers with precision more than a billion times more accurately than the error that the OP is complaining about.
Yes its obvious that this is a bug. Hopefully the bug is confined to just the reporting of the analysis tools
That misses the point.
Just do then: print(0.1+0.1+0.1). Not 0.3, is it? Besides:
Still not 0