Use radians instead of degrees about joml HOT 8 CLOSED

Agreed. You make a very good point

from joml.

You are right. We lose 'a very tiny bit' (i.e. the tinies bit that is possible, actually) of precision, and not "a lot of" :) when converting.
And since I wanted to know exactly how much that was, I conducted an experiment randomly taking 100 billion floating point values and running them through toDegrees(toRadians(x)) two times in a chain.
The result: 89.80% of the values will remain exactly identical to the input.
And for the remaining 10%, the error is within 1 ULP, so as small of a difference as it can be before being identical (IEEE 754 requires all operations to be within 0.5 ULP).
So the error is pretty small and in my opinion quite negligible compared to the other precision errors we get everywhere else such as with sin/cos/tan operations and matrix multiplications.
Having said that, one of JOML's design goals was to reflect the semantics of existing APIs such as OpenGL/GLU as closely as possible, which use degrees.
This is to make adoption and translation from and to those other APIs as seemlessly as possible. And that's where JOML left off. Maybe that was a wrong decision from the start.
So I would be very happy to accept a Pull Request with all JavaDocs and method semantics changed to radians, so that we could have that in a separate "radians" branch of JOML.
It's just that I do not want to throw away the existing degrees methods altogether.

from joml.

There wouldnt be much point in having a separate branch just for radians... We would have to decided on one or the other for the whole project. And @httpdigest seems to have made it quite clear that there is no point in using radians only since the goal was to easily integrated with existing APIs

from joml.

This seems interesting. http://stackoverflow.com/questions/2146884/why-does-opengl-use-degrees-instead-of-radians

from joml.

I agree that the error is small, and while I don't think too much optimization is good, making such changes would not be much work. Like @z3t0 I don't think creating a separate branch would be useful. However, it won't be too difficult to add separate methods for degrees and radians. For example:

public void someMethodRad(float angle) {
    // Implementation using an angle in radians
}

public void someMethod(float angle) {
    someMethodRad(Math.toRadians(angle));
}

public float someMethodRad() {
    // Implementation returning an angle in radians
}

public float someMethod() {
    return Math.toDegrees(someMethodRad());
}

Users who want to use degrees can then just use someMethod() like before, which implicitly handles degrees-radians conversions. But users who want to have some more control over these conversions can use someMethodRad().

from joml.

It was indeed not a big amount of work regex-replacing the uses of Math.toRadians and the JavaDocs.
As a start, I committed c71e726 and changed the semantics of all methods and fields, that are about angles, from degrees to radians.
Please tell me what you think about this change. From what I heard also of people over at JGO, most users would prefer radians anyways, so I guess we can live with this solution now.
Trying to reflect the OpenGL/GLU API by using degrees was based on an assumption of mine that it would make life easier for people. But maybe that assumption has no real basis, because I have yet to hear from someone who actually likes using degrees in those methods. :)
Whether we need additional overloads with 'deg' can be discussed.
An updated 1.3.5-SNAPSHOT with these changes is deployed to sonatype.

from joml.

This solution seems great. Overloads are probably not needed because they would only clutter up the API.

The Javadocs tell that the methods now use radians, but it might be missed by some, so a section on the Design wiki page would be useful.

from joml.

Yes, JOML already has a high overloadedness factor, because of vector vs. primitive parameters, working on this vs. defining a dest parameter and convenience methods such as Matrix4f.rotateX. Adding another dimension to this cross-product would increase the API too much. So, unless someone else objects, I would leave it this way.
Wiki has also been updated.

from joml.