glm::float_distance algorithm run-time not acceptable

[dustin-biser]

Feature enhancement request is in reference to the super slow algorithm to compute distances between floats:
https://github.com/g-truc/glm/blob/0.9.5/glm/gtc/ulp.inl
line 280
GLM_FUNC_QUALIFIER uint float_distance(T const & x, T const & y)

The current algorithm is unacceptable for use in any real-time application due to the incremental stepping to subsequent floats and plethora of function calls.

Please refer to the constant time algorithm proposed by Bruce Dawson
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

// Usable AlmostEqual function
bool AlmostEqual2sComplement(float A, float B, int maxUlps)
{
    // Make sure maxUlps is non-negative and small enough that the
    // default NAN won't compare as equal to anything.
    assert(maxUlps > 0 && maxUlps < 4 * 1024 * 1024);
    int aInt = *(int*)&A;
    // Make aInt lexicographically ordered as a twos-complement int
    if (aInt < 0)
        aInt = 0x80000000 - aInt;
    // Make bInt lexicographically ordered as a twos-complement int
    int bInt = *(int*)&B;
    if (bInt < 0)
        bInt = 0x80000000 - bInt;
    int intDiff = abs(aInt - bInt);
    if (intDiff <= maxUlps)
        return true;
    return false;
}

[Groovounet]

It seems to me that it should be possible to compute offline or at initialization an epsilon value using glm::next_float and use that value with the epsilonEqual.

Regardless, there might be use cases where maxUlps have to be dynamic making the proposed feature relevant.

Thanks,
Christophe

[dustin-biser]

I agree that glm::next_float is useful, and that there should be an added function for computing the distance between two floats in constant time with respect to the distance between the floats.

[Groovounet]

Better 5 years later than never... this issue is fixed in dev branch and should reach master branch for GLM 0.9.9.3 release.

Thanks for contributing!