BLI_math 'compare' cleanup & enhancements.

This commit:
* Adds a 'compare_ff' function for absolute 'almost equal' comparison of floats.
* Makes 'compare_vxvx' functions use that new 'compare_ff' one.
* Adds a 'compare_ff_relative' function for secured ulp-based relative comparison of floats.
* Adds matching 'compare_vxvx_relative' functions.
* Adds some basic tests for compare_ff_relative.

See https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

Note that we could replace our python/mathutils' EXPP_FloatsAreEqual() by BLI's compare_ff_relative
(using a very small absolute max_diff), but these do not have exact same behavior...
Left a comment there for now, we can do it later if/when we are sure it won't break anything!

1 files changed, 9 insertions, 0 deletions

diff --git a/source/blender/python/mathutils/mathutils.c b/source/blender/python/mathutils/mathutils.c
index 361fbc8a005..8e14319e258 100644
--- a/source/blender/python/mathutils/mathutils.c
+++ b/source/blender/python/mathutils/mathutils.c
@@ -348,6 +348,15 @@ int mathutils_any_to_rotmat(float rmat[3][3], PyObject *value, const char *error
 /* Utility functions */
 
 /* LomontRRDCompare4, Ever Faster Float Comparisons by Randy Dillon */
+/* XXX We may want to use 'safer' BLI's compare_ff_relative ultimately?
+ *     LomontRRDCompare4() is an optimized version of Dawson's AlmostEqual2sComplement() (see [1] and [2]).
+ *     Dawson himself now claims this is not a 'safe' thing to do (pushing ULP method beyond its limits),
+ *     an recommands using work from [3] instead, which is done in BLI func...
+ *
+ *     [1] http://www.randydillon.org/Papers/2007/everfast.htm
+ *     [2] http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
+ *     [3] https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ instead
+ */
 #define SIGNMASK(i) (-(int)(((unsigned int)(i)) >> 31))
 
 int EXPP_FloatsAreEqual(float af, float bf, int maxDiff)