It just breaks the brain! 
unnamed.gh (7.4 KB)
might be an int/string type issue, i usually test with a-b === 0 rather than comparing them
the problem is grasshopper hides a lot of the programmatic nuances, such as data types, making weird behaviour like this, very similar to the same issues found in something like javascript
solution: replace the equals component with subtraction, then see if the result equals zero. alternatively you can replace the text component zero with a slider zero (this may bring out other issues like int/double type).
As @thriceashians mentioned above, a lot of secondary details are hidden by Grasshopper, in order to make it more straightforward to use (?) and computationally efficient (?).
The downside to this is that there sometimes emerge problems like yours, where the source seems to be quite obscure.
However, in my opinion, you’re not dealing with a problem concerning int/string type conversion.
Your y-coordinate is simply NOT equal to 0, but that fact was hidden by document tolerance or something else at component level.
These are the real y-values (highlighted by python):
- 4.26325641456e-14
- -6.03961325396e-14
They’re written in E-notation, a type of scientific notation, commonly used by calculators and computers to represent numbers to big or small to be described in decimal.
For instance, 4.26325641456e-14 is the same as 4.26325641456 * 10^{-14}.
Now, in order to circumvent this issue, you can simply round your numbers to integers.
The downside to this is that you lose the decimal data.
An other approach would be to refine your comparison to 0, by introducing your own tolerance value.
1 Like
It has been asked and answered a lot.
Ah yes this makes sense. What i do here is put both values into a function that finds the difference in absolute value, then if this value is smaller than say 0.00001 then it outputs true.
Exactly, or as I showed above.
@diff-arch, and the Expression component is surprising! 
I somehow did not think about this! Can I get acquainted with all the possibilities somewhere?
In general, I understand the current case … Can I somehow protect myself from this? Can I somehow see the real values (numbers) using already existing GH functions (if desired)?
Logic … The program shows 0, but in fact there is not quite 0, but if you rely on the document tolerance, there will be 0. And the component must take the tolerance into account and work with 0, and not with something somewhere VERY small! I am wrong?
This is the formula. if abs(A-B)<tolerance
Pufferfish has a “Equality within Tolerance” component for this.
1 Like
Well thank you!
This would be the default in GH 