fix angle_vectors_signed

[robin-oval]

trafficstars

fix angle_vectors_signed - the check to reverse the angle was always True

bug fix in a backwards-compatible manner

[tomvanmele]

can you add a test and an entry in the changelog?

[jf---]

@tomvanmele seems an important fix +1!

[tomvanmele]

@jf--- i can't resolve the conflicts and @robin-oval is unresponsive. will fix in a separate PR and close this one...

[jf---]

@tomvanmele wonderful, we discussed a Precision class ( akin to that of opencascade ). The threshold variable in @robin-oval's fix is a good candidate for use of such a class. In the past I ran into numerical stability issues in a Quaternion class, here sys.float_info.epsilon came in very useful to overcome those. I think that a (multiple) of sys.float_info.epsilon could be a good foundation for such a class?

[tomvanmele]

:) we have a dev meeting tomorrow and the precision module is one of the topics...

[tomvanmele]

just FYI, i am planning to use a default precision of 1e-12, since there are some differences between the behaviour of IPY CPY at higher precisions...

[tomvanmele]

the precision module will also be the new home for compas.geometry.close and compas.geometry.allclose, and similar functions.

[tomvanmele]

could you elaborate a bit on how you used floating point precision to overcome those numerical instabilities you mentioned?

[jf---]

just FYI, i am planning to use a default precision of 1e-12, since there are some differences between the behaviour of IPY CPY at higher precisions...

Ah interesting! But so that's sys.float_info.epsilon would resolve that?

could you elaborate a bit on how you used floating point precision to overcome those numerical instabilities you mentioned?

Comparing angles in Quaternion is pretty sensitive -- the sign of the angle can flip a problem when comparing to math.pi/2. sys.float_info.epsilon helped to resolve that robustly

[jf---]

the precision module will also be the new home for compas.geometry.close and compas.geometry.allclose, and similar functions.

right, a compas.precision seems terrific

---

That said, a required precision for angles is very different from those of vertices or point ( see Precision.Confusion )

Therefore an allclose function is too broad I think.

Therefore the suggestion to model the class on OCC, and adopt similar angular, confusion, intersection and parametric methods

[tomvanmele]

Therefore the suggestion to model the class on OCC, and adopt similar angular, confusion, intersection and parametric methods

cool will have a look

[tomvanmele]

@jf--- done here #1174

[jf---]

Nice! The default for angles in OCC is 1e-7 IIRC, 1e-3 is quite a low threshold I think. Moreover a future refactor where numerical precision is handled in a central class is a nice idea. For now clearly this is progress. Shall I sum up this thread as an issue / feature? #1174 closed this issue?

[tomvanmele]

Shall I sum up this thread as an issue / feature?

yup, sounds good!