Point Z value test


I’m not sure what happened here.

I try to test Z value of set of points to take only those that have Z = 0, but if i directly test Z value ( first path) my result is wrong because it takes only one out of two points that have Z=0 in the list.

Instead my result is correct if i put a panel between point deconstruct and equality test, it’s only a pass through, apparently nothing happens here but at the end the result is as i expected.

Maybe I’m missing something, can someone explain what happens here??

Thanks in advacne.

Test.gh (10.1 KB)


most probably a rounding problem, as grasshopper displays only a rounded number.
due to the tolerance, the output of pDecon can be 0.0000000000001 or something, that isn’t zero mathematically, but not displayed in grasshopper.

Panel converts your values to strings, so there’s another comparision.

It looks like you only have N numbers, so try to plug in your values to a “int” element to convert before comparing, this should work as well.

as expected, your second point shows: Point at (-355,0,4.28626e-15). in the details. so mathematically it is not 0, but within rhino tolerances it is 0.

for N numbers convert to int before you compare them

for R numbers, try and round them to an acceptable tolerance

hope this helps


I replaced the standard Equals component with a cluster I created and keep as a “User Object”: isEqual. It has a ‘T’ (Tolerance) input that defaults to 0.0001 but can be overridden.

isEqual_2021_Jun21a.gh (16.8 KB)

The isEqual cluster:



Thanks Ben for your reply.

I hadn’t noticed that some point not have Z=0.

However, have the same issue using similar component with Threshold value set 99% (100% value A is always equal to B). That’s why I’m not convinced it’s just a tolerances isse.

My points became by intersection between line and Crv and my line is built with z=0. Can’t uderstand why reuslting points have that Z value.

Thanks, Joseph.

This definitely works.
This post was just a way to get to know Grasshopper better and how to get around these issues. :wink:

@Joseph just proofed I was right… nice workaround Joseph!

Mathematical calculations or evaluations always have some jitter, there’s no way around that. it’s definitively due to tolerance.

as @benedict suggests, passing the very same values through a “number” parameter (that keeps their “invisible” decimal values) and through a “integer” parameter (that trims their “invisible” decimal values rounding them to the closest integer) is the key

if you find any mismatch in the final patterns (like in this case) then it’s always because of the rounding :slight_smile:

1 Like