> > > 2009/5/4 Daniel Russel drussel@gmail.com > >> We already have constructing a Rotation3D from your choice of Euler >>> angles (and you can get a matrix from that if you want). So there isn't much >>> reason to be passing them around at all. >>> >>> No, that is not true. Given that no convention was established, there is >>> freedom to use anyone. >>> >> Yes, there is no convention for which types of Euler Angles to use. There >> is a convention that all rotations be represented using a Rotation3D (which >> can be created from many things). >> >> Sure, the question is more whether it should be part of the API or in an >>> internal header or .cpp file where it is used. So far I don't see anything >>> that justifies creating an alternative rotation passing convention (which >>> would require lots of functions to be eventually duplicated to support >>> both)._______________________________________________ >>> >>> I will be happy hearing about any improvement in the API. I'm worried >>> though about project(). It should work at least as it is working now, and >>> respecting my choice of angles and rotation interface requesting a matrix, >>> because that function is at the core of my project and I want that >>> performance. If it can be improved, I gladly will acknowledge any >>> contribution. As long as the function is able to access what requires, I >>> don't mind the way it is done. I can provide stringent tests that I decided >>> not to finally put in actual tests. >>> >> Given a relatively narrow interface, performance is generally pretty easy >> to achieve given a benchmark to test changes. The narrow interface is >> important since it means that you don't have to improve up too much code (eg >> having several Rotation classes means improvements to one are not available >> to functions which use another). >> > I agree. > >> >> As I mentioned, we can always add an internal cache of the matrix values >> in Rotation3D if we find that such speeds things up. My suspicion is that >> the compiler would cache the results for us if you are applying the >> rotations in an inner loop and that the memory accesses would overwhelm the >> reduced number of multiplications if it is not, but it is easy to test once >> a benchmark is set up. For this, a benchmark of just rotating a matrix of >> random numbers would probably do and be very easy to set up. > > I will be very happy to hear from that. > >> >> >> It seems to me the old interface with >> - Rotation3D which has a rotate function >> - functions to create Rotation3Ds from various Euler angles (including >> ZYZ, if it is not already there) >> - possible caching of the rotation matrix in Rotation3D if that does speed >> things up >> covers everything that is needed without the addition of any of the new >> classes and conflicting conventions. Is this right? >> > > No. I tried building a Rotation 3D and using it and it didn't work with > project(). I can provide the details of what was failing, and maybe somebody > can find what I couldn't after fighting for some weeks. It would be very > helpful. > > >> Then anyone can, upon reading Euler angle values (of whatever convention) >> create a Rotation3D. This Rotation3D can be used to perform rotations in an >> efficient manner. And we don't have to worry about some functions take one >> representation for rotations, and some another. > > > Fine, as long as project() can be accessed the way I want/need and works > after the changes, I don't mind the internal way it calls rotations. > > > >> >> _______________________________________________ >> >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > >
> It seems to me the old interface with > - Rotation3D which has a rotate function > - functions to create Rotation3Ds from various Euler angles > (including ZYZ, if it is not already there) > - possible caching of the rotation matrix in Rotation3D if that does > speed things up > covers everything that is needed without the addition of any of the > new classes and conflicting conventions. Is this right? > > No. I tried building a Rotation 3D and using it and it didn't work > with project(). I can provide the details of what was failing, and > maybe somebody can find what I couldn't after fighting for some > weeks. It would be very helpful.
Please do. Please always report any such problems, whether or not you work around them some other way. And report them immediately rather than fighting for a while as other people are more familiar with that code and so might have good ideas how to fix it. Otherwise, they won't get fixed and someone else will run into the same thing. The best thing is to provide a simple example of incorrect behavior and stick it in the bug tracker or email it to the list.
> Fine, as long as project() can be accessed the way I want/need and > works after the changes, I don't mind the internal way it calls > rotations.
It is a great advice. Sounds good. I just thought that reporting problems with my own function would not be very helpful to anybody. Instead, I created the functionality that I needed and was not there.
2009/5/5 Daniel Russel drussel@gmail.com
> It seems to me the old interface with >> - Rotation3D which has a rotate function >> - functions to create Rotation3Ds from various Euler angles (including >> ZYZ, if it is not already there) >> - possible caching of the rotation matrix in Rotation3D if that does speed >> things up >> covers everything that is needed without the addition of any of the new >> classes and conflicting conventions. Is this right? >> >> No. I tried building a Rotation 3D and using it and it didn't work with >> project(). I can provide the details of what was failing, and maybe somebody >> can find what I couldn't after fighting for some weeks. It would be very >> helpful. >> > > Please do. Please always report any such problems, whether or not you work > around them some other way. And report them immediately rather than fighting > for a while as other people are more familiar with that code and so might > have good ideas how to fix it. Otherwise, they won't get fixed and someone > else will run into the same thing. The best thing is to provide a simple > example of incorrect behavior and stick it in the bug tracker or email it to > the list. > > > Fine, as long as project() can be accessed the way I want/need and works >> after the changes, I don't mind the internal way it calls rotations. >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
If you can't manage to construct a Rotation3D from your Euler angles and rotate things, which us all the classes are doing, then that is a problem with Rotation3D or its docs as such should be simple enough :-)
Also, the 2D rotation should be Rotation2D by symmetry. Whether it is stored as a matrix or not is just an implementation detail.
I'll be in shortly.
On May 5, 2009, at 8:38 AM, Javier Ángel Velázquez Muriel <javi@salilab.o rg> wrote:
> > It is a great advice. Sounds good. I just thought that reporting > problems with my own function would not be very helpful to anybody. > Instead, I created the functionality that I needed and was not there. > > 2009/5/5 Daniel Russel drussel@gmail.com > It seems to me the old interface with > - Rotation3D which has a rotate function > - functions to create Rotation3Ds from various Euler angles > (including ZYZ, if it is not already there) > - possible caching of the rotation matrix in Rotation3D if that does > speed things up > covers everything that is needed without the addition of any of the > new classes and conflicting conventions. Is this right? > > No. I tried building a Rotation 3D and using it and it didn't work > with project(). I can provide the details of what was failing, and > maybe somebody can find what I couldn't after fighting for some > weeks. It would be very helpful. > > Please do. Please always report any such problems, whether or not > you work around them some other way. And report them immediately > rather than fighting for a while as other people are more familiar > with that code and so might have good ideas how to fix it. > Otherwise, they won't get fixed and someone else will run into the > same thing. The best thing is to provide a simple example of > incorrect behavior and stick it in the bug tracker or email it to > the list. > > > Fine, as long as project() can be accessed the way I want/need and > works after the changes, I don't mind the internal way it calls > rotations. > > _______________________________________________ > 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
Following the discussion, I made the following changes: - there is now code to create a Rotation3D from ZYZ euler angles (moved from the old Euler ange class). Javi needs to fill out the documentation of this method to make it as well specified as the other Euler angle methods (ie are the axis fixed or not) as I don't know the answers to all the necessary questions and they weren't previously documented - the project.h code uses Rotation3D - Rotation3D caches the rotation matrix since it made rotations about 20% faster and memory seemed unlikely to be an issue. There is a benchmark for this. - the 2D rotation class is now Rotation2D - all tests still pass
If I remember correctly, I said that I *****NEED***** and prefer the 3 euler angles to be specified for project(). Therefore the new version of project is not helpful, and I am going to go back to the version that satisfied my needs. I can always document everything as much as needed.
2009/5/7 Daniel Russel drussel@gmail.com
> Following the discussion, I made the following changes: > - there is now code to create a Rotation3D from ZYZ euler angles (moved > from the old Euler ange class). Javi needs to fill out the documentation of > this method to make it as well specified as the other Euler angle methods > (ie are the axis fixed or not) as I don't know the answers to all the > necessary questions and they weren't previously documented > - the project.h code uses Rotation3D > - Rotation3D caches the rotation matrix since it made rotations about 20% > faster and memory seemed unlikely to be an issue. There is a benchmark for > this. > - the 2D rotation class is now Rotation2D > - all tests still pass > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >
Well, neither the code nor the test cases require it. And you also said that if it could be easily made to work with Rotation3D that would be a good thing. It works very easily.
The changes don't add any complexity to using project with euler angles and it doesn't add as second, incompatible convention for passing angles to IMP.algebra (which is the most important thing).
2009/5/7 Javier Ángel Velázquez Muriel javi@salilab.org
> > If I remember correctly, I said that I *****NEED***** and prefer the 3 > euler angles to be specified for project(). Therefore the new version of > project is not helpful, and I am going to go back to the version that > satisfied my needs. I can always document everything as much as needed. > > 2009/5/7 Daniel Russel drussel@gmail.com > >> Following the discussion, I made the following changes: >> - there is now code to create a Rotation3D from ZYZ euler angles (moved >> from the old Euler ange class). Javi needs to fill out the documentation of >> this method to make it as well specified as the other Euler angle methods >> (ie are the axis fixed or not) as I don't know the answers to all the >> necessary questions and they weren't previously documented >> - the project.h code uses Rotation3D >> - Rotation3D caches the rotation matrix since it made rotations about 20% >> faster and memory seemed unlikely to be an issue. There is a benchmark for >> this. >> - the 2D rotation class is now Rotation2D >> - all tests still pass >> >> _______________________________________________ >> 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 > >
Javier Ángel Velázquez Muriel wrote: > If I remember correctly, I said that I *****NEED***** and prefer the 3 > euler angles to be specified for project(). Therefore the new version of > project is not helpful, and I am going to go back to the version that > satisfied my needs. I can always document everything as much as needed.
The best way to ensure that something you need works is to write a test case for it. Then anybody that changes it will break your test, and we can all yell at them.
There are several people that can help you (myself included) to work with Rotation3D. But it doesn't make sense to have other classes to work with rotations, since nobody will know which is the "right" one and it is harder to test multiple code paths. And it's pretty much universally acknowledged these days that if you really *have* to choose one way of representing a rotation, three Euler angles is most definitely not the way to do it (gimbal lock and the order of the angles being the most obvious problems).
Ben
I'm not that unreasonable, or at least I like to think that. I can accept the quaternions. Can somebody please add then a function to come back from a rotation3D to a set of angles?
After finding a good rotation I need to spit to the stupid user (i.e., me) the proper angles, because that is what everybody uses de facto in the field. Help!
2009/5/7 Ben Webb ben@salilab.org
> Javier Ángel Velázquez Muriel wrote: > > If I remember correctly, I said that I *****NEED***** and prefer the 3 > > euler angles to be specified for project(). Therefore the new version of > > project is not helpful, and I am going to go back to the version that > > satisfied my needs. I can always document everything as much as needed. > > The best way to ensure that something you need works is to write a test > case for it. Then anybody that changes it will break your test, and we > can all yell at them. > > There are several people that can help you (myself included) to work > with Rotation3D. But it doesn't make sense to have other classes to work > with rotations, since nobody will know which is the "right" one and it > is harder to test multiple code paths. And it's pretty much universally > acknowledged these days that if you really *have* to choose one way of > representing a rotation, three Euler angles is most definitely not the > way to do it (gimbal lock and the order of the angles being the most > obvious problems). > > Ben > -- > ben@salilab.org http://salilab.org/~ben/http://salilab.org/%7Eben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
I'll look around.
On May 7, 2009, at 3:32 PM, Javier Ángel Velázquez Muriel <javi@salilab.o rg> wrote:
> I'm not that unreasonable, or at least I like to think that. I can > accept the quaternions. > Can somebody please add then a function to come back from a > rotation3D to a set of angles? > > After finding a good rotation I need to spit to the stupid user > (i.e., me) the proper angles, because that is what everybody uses de > facto in the field. Help! > > 2009/5/7 Ben Webb ben@salilab.org > Javier Ángel Velázquez Muriel wrote: > > If I remember correctly, I said that I *****NEED***** and prefer > the 3 > > euler angles to be specified for project(). Therefore the new > version of > > project is not helpful, and I am going to go back to the version > that > > satisfied my needs. I can always document everything as much as > needed. > > The best way to ensure that something you need works is to write a > test > case for it. Then anybody that changes it will break your test, and we > can all yell at them. > > There are several people that can help you (myself included) to work > with Rotation3D. But it doesn't make sense to have other classes to > work > with rotations, since nobody will know which is the "right" one and it > is harder to test multiple code paths. And it's pretty much > universally > acknowledged these days that if you really *have* to choose one way of > representing a rotation, three Euler angles is most definitely not the > way to do it (gimbal lock and the order of the angles being the most > obvious problems). > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > 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
But I need a better description of what you need as there are a variety of varients of zyz depending on which rotations are done with a body frame axis and which are fixed. If you fill in the docs on the rotation_from function then it will be clearer. Thanks.
On May 7, 2009, at 3:32 PM, Javier Ángel Velázquez Muriel <javi@salilab.o rg> wrote:
> I'm not that unreasonable, or at least I like to think that. I can > accept the quaternions. > Can somebody please add then a function to come back from a > rotation3D to a set of angles? > > After finding a good rotation I need to spit to the stupid user > (i.e., me) the proper angles, because that is what everybody uses de > facto in the field. Help! > > 2009/5/7 Ben Webb ben@salilab.org > Javier Ángel Velázquez Muriel wrote: > > If I remember correctly, I said that I *****NEED***** and prefer > the 3 > > euler angles to be specified for project(). Therefore the new > version of > > project is not helpful, and I am going to go back to the version > that > > satisfied my needs. I can always document everything as much as > needed. > > The best way to ensure that something you need works is to write a > test > case for it. Then anybody that changes it will break your test, and we > can all yell at them. > > There are several people that can help you (myself included) to work > with Rotation3D. But it doesn't make sense to have other classes to > work > with rotations, since nobody will know which is the "right" one and it > is harder to test multiple code paths. And it's pretty much > universally > acknowledged these days that if you really *have* to choose one way of > representing a rotation, three Euler angles is most definitely not the > way to do it (gimbal lock and the order of the angles being the most > obvious problems). > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > 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
doc updated. Nothing invented : usual zyz convention
2009/5/7 Daniel Russel drussel@gmail.com
> But I need a better description of what you need as there are a variety of > varients of zyz depending on which rotations are done with a body frame axis > and which are fixed. If you fill in the docs on the rotation_from function > then it will be clearer. Thanks. > > > > On May 7, 2009, at 3:32 PM, Javier Ángel Velázquez Muriel < > javi@salilab.org> wrote: > > I'm not that unreasonable, or at least I like to think that. I can accept > the quaternions. > Can somebody please add then a function to come back from a rotation3D to a > set of angles? > > After finding a good rotation I need to spit to the stupid user (i.e., me) > the proper angles, because that is what everybody uses de facto in the > field. Help! > > 2009/5/7 Ben Webb < ben@salilab.orgben@salilab.org> > >> Javier Ángel Velázquez Muriel wrote: >> > If I remember correctly, I said that I *****NEED***** and prefer the 3 >> > euler angles to be specified for project(). Therefore the new version of >> > project is not helpful, and I am going to go back to the version that >> > satisfied my needs. I can always document everything as much as needed. >> >> The best way to ensure that something you need works is to write a test >> case for it. Then anybody that changes it will break your test, and we >> can all yell at them. >> >> There are several people that can help you (myself included) to work >> with Rotation3D. But it doesn't make sense to have other classes to work >> with rotations, since nobody will know which is the "right" one and it >> is harder to test multiple code paths. And it's pretty much universally >> acknowledged these days that if you really *have* to choose one way of >> representing a rotation, three Euler angles is most definitely not the >> way to do it (gimbal lock and the order of the angles being the most >> obvious problems). >> >> Ben >> -- >> ben@salilab.orgben@salilab.org http://salilab.org/%7Eben/ >> http://salilab.org/~ben/ http://salilab.org/%7Eben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.orgIMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> 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 > >
participants (3)
-
Ben Webb -
Daniel Russel -
Javier Ángel Velázquez Muriel