Hello helpful people,
This should be a fairly easy one:
I’ve used the script in the attached document many times and it’s never given me the problem that’s shown in the picture. Clearly, for some reason I do not understand, grasshopper is omitting the last division in the curve on the top, but not on the bottom.
Why is this happening specifically with this curve when it’s worked perfectly fine with so many others?
Hello- this looks like a bug to me so far. At any other division distance (so far) the numbers are equal. I’ll put it on the pile, thanks for the report…
RH-75581 Divide Distance Discrepancy
-Pascal
Dear @saa109
I found the following stuff - none should be responsible for the problem:
(1) moving the initial curve to the origin - the problem is gone.
(but it is only arround 600 units away from origin - should not generate those issues)
(2) The curve has a length of
Length = 10.7000205 meters
to see this go to documentProperties → units
and increase the display precision
(3) flipping the direction _dir the problem is inverted - grasshopper does not find all points on the lower curve.
(4) redrawing the line and entering precise numbers for the segment lengths
2.5
3.2
3.2
1.8
the new polyline does not have the problems (same start-point)
(5) List / coordinates
ON_PolylineCurve: domain = [0,10.7]
point[ 0] = (42.978203527420675, 616.93982536491171, 5.2560000000178597), 0
point[ 1] = (40.478203527420646, 616.93982536491171, 5.2560000000178597), 2.5
point[ 2] = (40.478203527420646, 620.13982536491164, 5.2560000000178597), 5.7
point[ 3] = (43.678203527420692, 620.13982536491164, 5.2560000000178597), 8.9
point[ 4] = (43.678203527420692, 618.33980483674088, 5.2560000000178597), 10.7
my guess - the noise at the last digits causes the issue.
because of some limitations of Floating Point Arithmetic and how to represent decimal numbers as binary …
(6)
entering .0999999 instead of 0.1 also makes the problem disappear…
which somehow supports my guess of floating-point-representation-glitch causing the error.
my advice:
redraw the polyline and if you don t get the problem again - forget about it.
if the problem occurs more often - you have to adapt the grasshopper definition and use some threshold / epsilon regarding the number of division points.
if you need more attention to this topic, change the category to grasshopper.
kind regards - tom
Yep, apparently it’s a bug. Thank you.
I learned so much with this reply I wasn’t expecting… thanks for the thorough response!
