glm.clamp(float64) always converts to float32 internally possibly because of bug in PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf

[Cazadorro]

I was testing np.clip(-0.010945739779012037, -1.0, 1.0) vs glm.clamp(-0.010945739779012037, -1.0, 1.0) and I get -0.010945739779012037, and -0.010945740155875683, when both should just be -0.010945739779012037. This appears to be because glm.clamp is doing a f32 conversion, which it shouldn't be doing.

Looking at the code I see this on line 27487:

PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf(clamp)

Looking at PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf shows:

#define PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf(NAME)\
static PyObject*\
NAME##_(PyObject*, PyObject* args) {\
	PyObject *arg1, *arg2, *arg3;\
	PyGLM_Arg_Unpack_3O(args, #NAME, arg1, arg2, arg3);\
	if (PyGLM_Number_Check(arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(PyGLM_Number_FromPyObject<float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(1, float, arg1) && PyGLM_Vec_Check(1, float, arg2) && PyGLM_Vec_Check(1, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<1, float>(arg1), unpack_vec<1, float>(arg2), unpack_vec<1, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(2, float, arg1) && PyGLM_Vec_Check(2, float, arg2) && PyGLM_Vec_Check(2, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<2, float>(arg1), unpack_vec<2, float>(arg2), unpack_vec<2, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(3, float, arg1) && PyGLM_Vec_Check(3, float, arg2) && PyGLM_Vec_Check(3, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<3, float>(arg1), unpack_vec<3, float>(arg2), unpack_vec<3, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(4, float, arg1) && PyGLM_Vec_Check(4, float, arg2) && PyGLM_Vec_Check(4, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<4, float>(arg1), unpack_vec<4, float>(arg2), unpack_vec<4, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(1, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<1, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(2, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<2, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(3, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<3, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(4, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<4, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	PyErr_SetString(PyExc_TypeError, "invalid argument type(s) for " #NAME "()");\
	return NULL;\
}

There's not a single reference to double, so it seems apparent that this macro is not capable of handling double precision code arguments. I'm not sure exactly what this is doing, and it makes it difficult to contribute since it is one giant file, but I assume if everything here is just copied again but with double as the parameter it should just work? All the other similar macros appear to reference double, so presumably anything that uses that macro is going to have this same bug.

[Zuzu-Typ]

Yupp, you are correct. It should support float and double and not float only.
Currently, clamp is the only function using this macro.
Fixing this should be quite simple.

I know how cumbersome it is to deal with this one large file, however, it is not possible to use multiple source files due to the way C++ handles static variables (they are unique for every source file) and the Python C-API requires basically everything to be static.
The macros are already making it easier to solve problems and reduce the likeliness of making new ones.

The only way you could split up the huge file would be into header files and that wouldn't really help either.