frexp and ldexp definitions: return a pair?

[devernay]

I think the frexp and ldexp functions should take a single argument and return a pair, just like the standard python version https://docs.python.org/3.5/library/math.html#math.frexp, because python parameters are passed by value. That's more python-friendly.

Another solution would be to pass an array of ints as the second parameter.

[Zuzu-Typ]

No, I try to maintain compatibility with glm, which does in fact not return a pair.
Instead, it stores one part in the returned object and the other in the second argument.

I'm not sure I've tried the function, but it should work as intended looking at the code.

[devernay]

the problem is that the second argument should be passed as reference, which is not possible in python unless it is an array. Note that these are the only functions in GLSL that have an "out" parameter.
I don't see how it would work. And actually when you compile it it doesn't call any implementation in glm. Do a "nm" on the shared library, you'll see that the frexp symbols are undefined.

[Zuzu-Typ]

Ah yeah right, sorry about that.
There was an error in the original glm, where the forward reference to frexp and ldexp were incorrectly defined.
I mentioned the issue on their issue tracker and it did get fixed by now, however, I didn't update the PyPI yet.
Hence the missing functions.

Anyway what your saying is not true.
The only objects in Python that are not passed to functions by reference are numbers and strings.
Otherwise if you used a class object as an argument of a function, that is meant to do some changes to that very object, it would only edit a copy, which is not the case.

[devernay]

Agreed, class objects are passed by reference, so it would work for vectors of int (remember that the second argument must be an integer type as per the definition, so no vec2, vec3 or vec4), but not with integers.
One of the uses of frexp is:
y = frexp(x, e)
where x is a float/double and e is an int. You cannot do that in Python without changing the way e is returned. Since the second argument is not even used as input, it makes much more sense to return a pair.

And, by the way, I had to comment out the definitions of frexp and ldexp in the current version of PyGLM, because it resulted in undefined symbols (check with nm). The resulting shared object would load fine on Linux, because symbols are resolved when executing them, but not on macOS, where symbols are resolved when loading the shared object:
https://github.com/devernay/PyGLM/tree/disable-frexp-ldexp

[Zuzu-Typ]

I'm working on a future version of PyGLM right now, that does support additional types, including integer types. It will take a while to finish though.
The current version of PyGLM (if it did compile) uses a workaround, which uses a temporary integer vector as e and puts the contents of the temporary vector into the actual vector that you supplied to the function.
Although not a perfect solution, it should still work and comply with glm (more or less).
Nevermind, apparently I never pushed this change, so currently it wouldn't work.
Let me try fixing that really quick.

The reason why it doesn't compile is because there was an issue in glm itself, where the forward declarations were missing (see g-truc/glm#895).
I haven't yet updated the glm version in this repository.

[Zuzu-Typ]

Okay. It should work now.