I think that I mentioned this before, but the message went to Barak
only: em2d uses some functionality from IMP related to Euler angles.
If you remove the code entirely em2d won't work. em2d/internal
contains stable versions to go back from quaternions to Euler angles
that never failed to me, in case anyone cares. You can do as you
please with the other versions. Whatever you decide, just make sure
that my code works.

just to make it clear, the conversion from
euler angles to quaternion is used in several places. this
conversion is not problematic and should indeed stay.

I should be a little clearer. There are two separate
questions:

1) whether code to do conversions should be available to
existing code

2) whether the code should be available as part of the
supported IMP API (eg should it be in the documentation as
non-deprecated and something we support for users outside of
the repository)

There is (and should be) a lot more of 1 than 2 in any
project, including IMP and there are lots of ways that we can
provide 1:

- public API

- examples

- via internal APIs for code in the IMP repository

Clearly, we need to make sure that existing code isn't
broken badly. But we don't want to have things in central
places in the IMP API simply because there are useful/used
somewhere. The code being their imposes real costs, this
discussion being an example.

General guidelines that I have seen are for what should be
in an IMP tend to include, most importantly

1) can't easily be implemented by someone on top of
functionality we already provide

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).

Does anyone use Euler
angles? The related
functions don't work too
well (numerical instability)
so let us know if you need
them / feel
like fixing them / ok with
getting rid of them /
marking then as dangerous