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
On Apr 24, 2013, at 2:53 PM, drussel notifications@github.com wrote:
> Should probably just remove the functions. They are numerically unstable and no one has any interest in fixing them. > > — > Reply to this email directly or view it on GitHub.
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 > 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 > mailto:notifications@github.com> wrote: > >> Should probably just remove the functions. They are numerically >> unstable and no one has any interest in fixing them. >> >> — >> Reply to this email directly or view it on GitHub >> https://github.com/salilab/imp/issues/303#issuecomment-16970820. >> > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
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 conversionshttps://salilab.org/internal/imp/nightly/results/?test=1490&plat=1" and "test conversion of euler angleshttps://salilab.org/internal/imp/nightly/results/?test=1532&plat=1") or do we need to keep part of them?
On Fri, Apr 26, 2013 at 8:55 AM, Javier Velazquez-Muriel javi@salilab.orgwrote:
> 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 >> 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 >> <mailto:notifications@github.**com notifications@github.com>> wrote: >> >> Should probably just remove the functions. They are numerically >>> unstable and no one has any interest in fixing them. >>> >>> — >>> Reply to this email directly or view it on GitHub >>> <https://github.com/salilab/**imp/issues/303#issuecomment-**16970820https://github.com/salilab/imp/issues/303#issuecomment-16970820 >>> >. >>> >>> >> >> ______________________________**_________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >> > ______________________________**_________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >
On Mon, Apr 29, 2013 at 10:30 AM, Barak Raveh barak.raveh@gmail.com wrote:
> So what's the final verdict on this? > I don't see have conversions in only a single direction as a coherent enough set of functionality that it makes sense to support in IMP. So I think if we drop conversion in one direction, we should drop it in both, otherwise, if anyone actually uses it, we will have to revisit this question in the future. The code in question is nicely self-contained, so it is pretty straight forward for it to be dropped into anywhere that it is actually needed (so if there is code that we don't know about that uses it, it could be very quickly patched more or less by pasting the code we removed from IMP into it in much less time than has already been spent discussing it :-).
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 conversionshttps://salilab.org/internal/imp/nightly/results/?test=1490&plat=1" > and "test conversion of euler angleshttps://salilab.org/internal/imp/nightly/results/?test=1532&plat=1") > 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 >>> 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 >>> <mailto:notifications@github.**com notifications@github.com>> wrote: >>> >>> Should probably just remove the functions. They are numerically >>>> unstable and no one has any interest in fixing them. >>>> >>>> — >>>> Reply to this email directly or view it on GitHub >>>> <https://github.com/salilab/**imp/issues/303#issuecomment-**16970820https://github.com/salilab/imp/issues/303#issuecomment-16970820 >>>> >. >>>> >>>> >>> >>> ______________________________**_________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >>> >> ______________________________**_________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >> > > > > -- > Barak > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >
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).
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 > 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 > mailto:notifications@github.com> wrote: > > Should probably just remove the functions. They are numerically > unstable and no one has any interest in fixing them. > > — > Reply to this email directly or view it on GitHub > https://github.com/salilab/imp/issues/303#issuecomment-16970820. > > > > _______________________________________________ > 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
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.
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 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). > > 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.comwrote: > >> 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 conversionshttps://salilab.org/internal/imp/nightly/results/?test=1490&plat=1" >> and "test conversion of euler angleshttps://salilab.org/internal/imp/nightly/results/?test=1532&plat=1") >> 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 >>>> 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 >>>> <mailto:notifications@github.**com notifications@github.com>> wrote: >>>> >>>> Should probably just remove the functions. They are numerically >>>>> unstable and no one has any interest in fixing them. >>>>> >>>>> — >>>>> Reply to this email directly or view it on GitHub >>>>> <https://github.com/salilab/**imp/issues/303#issuecomment-**16970820https://github.com/salilab/imp/issues/303#issuecomment-16970820 >>>>> >. >>>>> >>>>> >>>> >>>> ______________________________**_________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >>>> >>> ______________________________**_________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/**listinfo/imp-devhttps://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 > >
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 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 but also 2) form coherent chunks of functionality 3) 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 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). > > 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 >> 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 >> mailto:notifications@github.com> wrote: >> >> Should probably just remove the functions. They are numerically >> unstable and no one has any interest in fixing them. >> >> — >> Reply to this email directly or view it on GitHub >> https://github.com/salilab/imp/issues/303#issuecomment-16970820. >> >> >> >> _______________________________________________ >> 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
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.
On 4/29/13 2:02 PM, Daniel Russel wrote: > > On Apr 29, 2013, at 12:39 PM, Dina Schneidman <duhovka@gmail.com > mailto: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 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 > but also > 2) form coherent chunks of functionality > 3) are, or are believed likely to be, widely used > > >> >> >> On Mon, Apr 29, 2013 at 12:03 PM, Daniel Russel <drussel@gmail.com >> mailto: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 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). >> >> On Apr 29, 2013, at 11:15 AM, Dina Schneidman <duhovka@gmail.com >> mailto: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 mailto: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 >>> https://salilab.org/internal/imp/nightly/results/?test=1490&plat=1" >>> and "test conversion of euler angles >>> https://salilab.org/internal/imp/nightly/results/?test=1532&plat=1") >>> or do we need to keep part of them? >>> >>> >>> On Fri, Apr 26, 2013 at 8:55 AM, Javier Velazquez-Muriel >>> <javi@salilab.org mailto: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 >>> 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 >>> mailto:notifications@github.com >>> mailto:notifications@github.com >> mailto:notifications@github.com>> wrote: >>> >>> Should probably just remove the functions. They >>> are numerically >>> unstable and no one has any interest in fixing them. >>> >>> --- >>> Reply to this email directly or view it on GitHub >>> https://github.com/salilab/imp/issues/303#issuecomment-16970820. >>> >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org mailto:IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org mailto:IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> >>> >>> -- >>> Barak >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org mailto:IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org mailto:IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org mailto:IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org mailto: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
participants (5)
-
Barak Raveh -
Barak.raveh
-
Daniel Russel -
Dina Schneidman -
Javier Velazquez-Muriel