Maybe I'm misinterpreting the IsAlmostEqualTo method. I want to establish if two points are within 4 inchs of each other (0.3333 feet). I though the following code would do that:
XYZ a = new XYZ(41.7, -76, 0); XYZ b = new XYZ(4.7, -76, 0); bool almostEqual = a.IsAlmostEqualTo(b, 0.333);
But even though in this example the two points are 37 feet apart IsAlmostEqualTo returns true. Am I misunderstanding the tolerance part of the method?
Solved! Go to Solution.
Dear Graham, Happy New Yerar to you and thank you for this very valid question. I submitted it to the development team as SPR #233706 [fix or document XYZ IsAlmostEqual tolerance] asking them either to document or fix this. If you need to know urgently, then the most efficient way to find out is to write a test command yourself, of course. Define two points four inches apart and iteratively and adaptively modify the tolerance until it fails, or succeeds, whichever way you choose to go. Cheers,
it is useful to develop a Utils or Math helper class which contains one's most used helper methods.
As of me, I've implemented an AlmostEqual method on my own, with a tolerance parameter.
Also, I use something like AlmostEqualIn2D.
And so on.
This way, there is absolute no need for the BuiltIn- XYZ.AsAlmostEqualTo() method.
Here is the simple explanation:
IsAlmostEqualTo is basically for vector comparison, not point comparison, and is mostly designed around small tolerances. The default for IsAlmostEqualTo with no tolerance input is 1e-09. At small tolerances, points and vectors are more interchangeable, so I would use the default IsAlmostEqualTo to find "equivalent" points too.
Because this is a directional comparison, not a distance one, 0.333 for the epsilon means to check if the two vectors are within a significant angular range of each other, which the example inputs actually pass. Even if the points are treated as vectors and normalized, they will still pass the comparison because of the wide epsilon permitted.
If you want to compare points with a non-tiny epsilon using the allowed distance between them, use XYZ.DistanceTo.
That is probably what Revitalizer' suggestions are based on, and so are my point and other object comparison methods in the Util.cs module of The Building Coder samples.
I hope this explains.
thanks for clarifying this.
I usually use XYZ for both vectors and points.
I'm glad to learn more about the internals.
In fact, I think there could be more issues like this one.
Why does Revit API behave just the way it behaves...?
Knowing more about the internals would clearify unexpected behaviour and prevent users to consider it as a bug.
Yes, of course, you have no choice whatsoever, you must use XYZ for both points and vectors.
At the same time, as in this case, you must be aware what context which methods are appropriate in.
And there is always something new to learn.
Thanks Jeremy (and to Revitalizer for input) for clarifying this. I did end up writing my own helper method for this and the DistanceTo method you mentioned here will simplify it even further so thanks. I have used IsAlmostEqualTo successfully in other areas of my projects - to compare points - using the default tolerances which is probably why I've not hit on the issue before now (having used higher tolerances). If I need to compare points with anything other than a non tiny tolerance in the future I will use my method which is now barely 3-4 lines of code using the DistanceTo method.
Onwards and upwards we go...