precision error - region union

Hi everyone,

I have found one of the problems with my pattern-producing script. There appears to go something wrong with the precision of a region union.

I have tried changing tolerances/units of the Rhino file, but that does not seem to help

Before union, both curves have sides of 10.0. After union, there is one side that is 10.0000001. This get worse when putting the placement script through hoopsnake and after a while prevents tiles from joining because all the sides are slightly different.

My drawing is in meters

Absolute tolerance 0.01

Relative tolerance 1

Angle tolerance 1

Attachments:

120515 girih rhino4.3dm, 55 KB
union_precision.gh, 3 KB

Replies to This Discussion

Permalink Reply by lucas cañada on May 18, 2012 at 3:14pm

Hi Anja! works fine in my pc. Wich is your gh version? ;)

Permalink Reply by Hannes Löschke on May 18, 2012 at 6:48pm

Actually this is one for the FAQ...

Floating point numbers are able to store only a finite amount of significant digits. This is about 6 for single precision (some Rhino mesh commands might use this) and about 16 decimal digits for double precision floats (default GH numbers).

There are some numbers, that binary floating point can store accurately. Like 1/3 in decimal cannot be written with a finite number of digits, 0.1 can only be approximated in binary. So regardless of your definition the will always be a source for round off errors.

Tolerance is a way to cope with those limited numbers of digits. Just round off anything below a certain threshold. The Rhino manual says never to use tolerances smaller than 0.0001. So any less significant digit should be ignored from a Rhino point of view. (your document tolerance is at 0.01 so you should ignore any digit smaller than that)

GH's numerical display (GH numbers in general) doesn't take the Rino tolerance into account. So you have to adjust for tolerance yourself. Round off everything according to your acceptable tolerance. If you want to check for equality, test the difference against tolerance instead.

If you do not round your values, slight mistakes might carry through. Say, there is an error of 0.001 at a tolerance 0f 0.01. Actually, everything is fine. Still there is some error below the threshold of 0.01. If you would multiply this value by 10 in the next iteration, this error will show up.... Same for every little mistake. After a sufficient number of iterations the error will show up above the tolerance. There really is no way around this, except carefully adjusting and readjusting for toerance in every iteration.

Permalink Reply by Anja on May 21, 2012 at 1:31am

@Lucas: That's strange? I'm using version 0.8.0066. I'll check if there's a newer one?

@Hannes: I think that where it goes wrong is when I try to align the next tile to one side of the base crv. Also, in the vectors, there is a small tolerance error. Instead of 0, a number becomes 3.24*E-17. If I round that to 0, the tile will not fit the base shape anymore, where I get errors with finding intersection later on.... (unfortunately, I see that the iterations change when I restart Rhino...I'm afraid this might be quite hard to simulate again on someone else's computer...)

Does anyone have a clue how I can fix this? Right now, all the tiles need to fit exactly in order for the script to calculate if it's possible to put this (or the next) tile.

I've added the script. There's a random seed slider below the hoopsnake component. For seed 0, the script works for quite some tiles. (And then get's stuck at a spot where it's not possible to put another tile, I need to fix that...) For seed 1, it already get's stuck at the second tile, because it overlooks an intersection and then decides that the next tile won't fit.

Attachments: