Drawing line segment start point is outside of view.

[MTheDesigner]

I have some code that tries to find the most left and most bottom point in a drawing to set up origins for ordinate sets. The code favors things to the bottom left. So for example if  I am looking for the lowest X value and I find 2 that are the same, I take the one with the lower Y value. however my code sometimes doesn't pick the correct point. While i was troubleshooting I found that even though the line should be exactly horizontal, that some of the points are 0.000000000000001 lower than the others. It is also technically outside of the bottom of the drawing view. This has made me have to put fuzzy logic in my code, which I don't like very much. Fuzzy logic makes the code more imprecise and can have rounding errors. Is there any way to remove this error or any way to handle it that doesn't involve me using Round() on every X and Y value?

[JelteDeJong · Accepted solution]

Inventor saves values (like X or Y coordinates) as floating points/doubles. They are stored as binary fractions. This means they cannot hold an exact representation of any quantity that is not a binary fraction (of the form k / (2 ^ n) where k and n are integers). For example, 0.5 (= 1/2) and 0.3125 (= 5/16) can be held as precise values, whereas 0.2 (= 1/5) and 0.3 (= 3/10) can be only approximations.

Because of this imprecision, there is always the risk that you get unexpected results when comparing floating points. The Microsoft documentation has suggestions on how you can handle this kind of problem.  But conveniently enough iLogic has a built in function that can help you to overcome this problem. “DoubleUtil.DoublesAreEqual(value1, value2)”. This function will tests if two numbers are equal within 6 decimal digits. If we use this function in the previous rule then you will see all results are correct. Try it.

[MTheDesigner]

Thanks, I was unaware of the DoubleUtil.DoublesAreEqual() command . I assumed that if there was any error in the line inventor would simply have the same error for all points in the line. I don't understand why it can get a slightly different answer given the digital nature of binary.