Limiting floating point checks

[nkyriazis]

GLM is templetized over the type of scalar. Static checking of whether scalar type is float acts on the opposite direction of templetization.

e.g.

GLM_STATIC_ASSERT(detail::type<T>::is_float, "'dot' only accept floating-point inputs");

Personally, I don't get why these checks are there. They are preventing me (so I had to comment them out) to use the glm math with scalar types that are not single precision, or actual scalars for that matter. By removing the checks I have successfully used the math libraries, in conjunction with dual numbers algebra, to e.g. compute derivatives of math routines, using OO autodiff.

This also means that some hard coded numbers here and there should be converted to T. For example, glm::mat3_cast should be changed to (notice the T() wraps around numbers)

    template <typename T> 
    GLM_FUNC_QUALIFIER detail::tmat3x3<T> mat3_cast
    (
        detail::tquat<T> const & q
    )
    {
        detail::tmat3x3<T> Result(T(1));
        Result[0][0] = T(1) - T(2) * q.y * q.y - T(2) * q.z * q.z;
        Result[0][1] = T(2) * q.x * q.y + T(2) * q.w * q.z;
        Result[0][2] = T(2) * q.x * q.z - T(2) * q.w * q.y;

        Result[1][0] = T(2) * q.x * q.y - T(2) * q.w * q.z;
        Result[1][1] = T(1) - T(2) * q.x * q.x - T(2) * q.z * q.z;
        Result[1][2] = T(2) * q.y * q.z + T(2) * q.w * q.x;

        Result[2][0] = T(2) * q.x * q.z + T(2) * q.w * q.y;
        Result[2][1] = T(2) * q.y * q.z - T(2) * q.w * q.x;
        Result[2][2] = T(1) - T(2) * q.x * q.x - T(2) * q.y * q.y;
        return Result;
    }

[denniskb]

Dear @Groovounet, I'm a computer vision researcher at FORTH (Foundation of Research and Technology Hellas) and work together with @nkyriazis. We're fond users of glm. However, the design choice outlined in this issue is very unfortunate for us as we deal with many data types that, while they are not, behave like floats. This prevents us from using many of the algorithms inside glm.

Is this something on your radar? Or are we perhaps missing a deeper motivation behind restricting template arguments to single types? Many thanks in advance!

[Groovounet]

The purpose of these asserts is purely to limit the behavior differences between GLSL and GLM.

Some extensions implement integer flavors of code functions. I could also add a define to avoid these checking.

[denniskb]

@Groovounet A define would be awesome. Thanks for looking into this.

[Groovounet]

This issue should be more or less fixed in GLM 0.9.8 branch for GLM 0.9.8.3 release and master branch.
Use #define GLM_FORCE_UNRESTRICTED_GENTYPE to enable this behavior.

There is very likely many places missing, please just open new issues if you need additional cases.

Thanks,
Christophe

[eugeneko]

@Groovounet Well, I think the subject (dot) shall be guarded with GLM_FORCE_UNRESTRICTED_GENTYPE too.

[elliotwoods]

Looking here:
https://github.com/g-truc/glm/blob/0.9.8/glm/detail/func_geometric.inl#L78

The static asserts are still there with no workaround.
Can you clarify?

I'm also having issues with auto-differentiators with glm