On Apr 29, 2013, at 12:39 PM, Dina Schneidman <duhovka@gmail.com> wrote:
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 code2) 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 repositoryClearly, 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 importantly1) can't easily be implemented by someone on top of functionality we already providebut also2) form coherent chunks of functionality3) are, or are believed likely to be, widely used
_______________________________________________
On Mon, Apr 29, 2013 at 12:03 PM, Daniel Russel <drussel@gmail.com> wrote:
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 are1) 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 it4) it kind of sucked, yet no one complained, so it is unlikely that anyone else was really using it5) it doesn't have any solid relation to IMP's mission6) 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 can1) 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).
On Apr 29, 2013, at 11:15 AM, Dina Schneidman <duhovka@gmail.com> wrote:
I think we should try the more stable implementation. if it works, we can keep this functionality._______________________________________________
On Mon, Apr 29, 2013 at 10:30 AM, Barak Raveh <barak.raveh@gmail.com> wrote:
So what's the final verdict on this?
Daniel, I invalidated the tests in algebra, but that's not necessary for functions we're gonna remove - should we remove the two tests that fail ("Check Euler ZYZ conversions" and "test conversion of euler angles") or do we need to keep part of them?--
On Fri, Apr 26, 2013 at 8:55 AM, Javier Velazquez-Muriel <javi@salilab.org> wrote:
em2d/internal contains more stable versions.
On Wed Apr 24 14:56:45 2013, Barak.raveh wrote:
_______________________________________________Does anyone use Euler angles? The related functions don't work too<mailto:notifications@github.com>> wrote:
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
On Apr 24, 2013, at 2:53 PM, drussel <notifications@github.com
Should probably just remove the functions. They are numerically<https://github.com/salilab/imp/issues/303#issuecomment-16970820>.
unstable and no one has any interest in fixing them.
—
Reply to this email directly or view it on GitHub
_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev
Barak
_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev
_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev
_______________________________________________ IMP-dev mailing list IMP-dev@salilab.org https://salilab.org/mailman/listinfo/imp-dev