Step back a bit from the discussion, based on this discussion, I would propose that Euler angles to quaternion conversions are a very good example of the type of functionality we should not have in the IMP API. The reasons I say this are
1) it doesn't interact with any other IMP data structures in a non-trivial way (we just have to make sure that the Rotation3D functions to and from quaternion are well documented). So anyone could implement it the same way we did.
2) we don't have any particular expertise in implementing it (we have to scrounge code from places to implement it)
3) we don't really use it (the only reason it came up at all was because a test failed, not because someone used it), so no one really cares about it
4) it kind of sucked, yet no one complained, so it is unlikely that anyone else was really using it
5) it doesn't have any solid relation to IMP's mission
6) the original justification, that lots of people would like using euler angles better than the alternatives doesn't seem to have panned out. Axis/angle and other ways of representing rotations have been used instead.
That said, since it is there, we need to decide what to do with it (for each block). We can
1) deprecate it.
2) remove it. We can stick the removed code into a github gist so that we can simply point anyone who was hurt by the removal at that and they can, in less time than this discussion took, patch their code by providing a definition near the use.
3) we can attempt to make the code better, but since, in my understanding, no one uses it or directly cares about this, it is a bit of a dubious exercise (since without clear use cases, it isn't really clear what amount of better is worth the effort).
I think we should try the more stable implementation. if it works, we can keep this functionality.
_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev