# Include tolerances on geometry helper functions

In my code, I use the viktor.Geometry.point_is_on_bounded_line()
I have a point, and loop through some lines to see if the point is on the line, simple.
Noiw, the function kept returning False eventhough I knew the point was on the line.

Snippet of my code:

``````    # Loop through lines in wireframe and check if point is on line
for staaf in wireframe.Staven:
p1: Point = wireframe.Knopen[staaf.Knoop1]
p2: Point = wireframe.Knopen[staaf.Knoop2]
line = Line(p1, p2)
print(f"if point: {checkpoint}")
print(f"is on line from start: {line.start_point}")
print(f"is on line to end: {line.end_point}")
print(f"result is: {point_is_on_bounded_line(checkpoint, line, False)}")

if point_is_on_bounded_line(checkpoint, line, False):
print(f"FOUND THE LINE!")
``````

The loop that should return true prints this info:
if point: Point(1.153e+01, 1.868e+01, 0.000e+00)
is on line from start: Point(1.153e+01, 1.935e+01, 0.000e+00)
is on line to end: Point(1.153e+01, 1.852e+01, 0.000e+00)
result is: False

Note that it is a vertical line with x = 1.153e+01
The Y of the line sits between 1.852e+01 and 1.935e+01 so the value of the point 1.868e+01 falls nicely between the ends.

I also used the function for these values, testing them hardcoded, and that does return true:

``````print(f"literal input: {point_is_on_bounded_line(Point(11.53, 18.85), Line(Point(11.53, 19.35), Point(11.53, 18.52)))}")
``````

So, either it is linked to this 3d Space error (Viktor.geometry.point_on_bounded_line not correct in 3D space, but this bug is old and reported to be fixed). And the z-dimensions are 0. Or it is due to the mathematical notation. But Iâ€™m not sure if that is just how the Point prints its float, or that that it actually supports a different notation.

Using SDK 14.2, Connector v5.21.0 and CLI v0.30.6

I did manage to find the fix, it was a very stupid thing i overlooked, decimals.
The extrapoint X-value was 11.529 where the line was on 11.5289119 etc.

Lets rephrase my question, is there a way allow a small tolleration?

Hi Johan,

I looked into it quite a bit at the time, so here is my take on it:

The old bug was only because 3D space wasnâ€™t supported, but I suspect this could well be a problem with numerical precision. I assume that with â€śmathmatical notationâ€ť you actually mean â€śscientific notationâ€ť?

A quick check would be (in this case) to check (in code) `print(p1.x==p2.x)` if that is not the case than you have the culprit.

In this particular function I would actually expect a â€śprecisionâ€ť parameter, because comparing floats (especially in 3d space) will results in problems like this, when switching to a different environment (say from Windows to Linux) the behavior may change again. So always write unittest to catch these issues!

At the time I implemented my own function for this check, which takes numerical precision into account (and is a parameter of the function).

Hope this helps,
Wichard

1 Like

Yes, this precision parameter would be a very sensible addition to this function.
Can anyone from Viktor shine their light on the matter?

Hi Johan, I think being able to tweak the tolerances makes perfect sense. This probably holds for a lot of other helper functions in the `geometry` module.

I see @khameeteman also already added it in our internal issue tracker. Iâ€™ll also switch this topic to a Feature Request so that people can submit their votes on it

*also changed the title to reflect the feature a bit better