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