On Jul 10, 2009, at 12:33 AM, Daniel Russel wrote:

> Comments: > - The names should be more the questions that come up for me are > (1) if it is coordinate RMSD, are the molecules rigidly aligned > before it is computed (and with the hierarchies case, are they all > aligned together or separately) yes - this is a very simple function that assumes correspondence between the two structures. Solving the correspondence problem should be handled n a different function > > (2) is it coordinate RMSD or distance RMSD (maybe I've just been > around Vijay's lab too long, does anyone else use dRMSD?) this is RMSD. probably a dRMSD would be useful as well > > (3) it's not really clear what the distance between two collections > of Hierarchies (when do you average). > I think the most important distinction is (1). And I'm not sure > what the best way to convey it. Are there some conventional modifiers > that someone knows? "structural" and "positional"? > > - it probably should go in a new header distance.h as there are > likely to be many such functions along the way. It definitely > shouldn't be in pdb.h as they don't have to do with pdbs. > > - Also, they should probably return doubles instead of Float (since > that is just the storage type for attributes and doubles should always > be used for computations). > ok - I'll add these functions in distances.h and return doubles > > On Thu, Jul 9, 2009 at 2:09 PM, Keren Laskerkerenl@salilab.org > wrote: >> hi, >> >> are you all ok with me adding a function >> MPATOMEXPORT Float rmsd(const Hierarchy& m1 ,const Hierarchy& m2); >> IMPATOMEXPORT Float rmsd(const Hierarchies& mh1 ,const Hierarchies& >> mh2); >> >> to pdb.h or utility.h in IMP::atom ? >> >> thanks, >> Keren. >> _______________________________________________ >> 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

It does not matter. rmsd is going to give you a number no matter if the molecules are aligned or not. The thing is how you interpret the number, so discussing about alignment does not apply for implementation, only for interpretation. Correspondence does apply. If not addressed, fine with me :)

Correspondence and rigid alignment are different questions. > Correspondence is hard enough to solve that I figured it was clearly > not being solved. Rigid alignment is trivial so it is not unreasonable > to assume it is done (but unclear whether or not it is). > _______________________________________________ >

I suggest this interface, since it is better defined:

IMPATOMEXPORT Float rmsd(const XYZs& m1 ,const XYZs& m2);

On Thu, Jul 9, 2009 at 3:31 PM, Daniel Russeldrussel@gmail.com wrote: > 2009/7/9 Javier Ángel Velázquez Muriel javi@salilab.org: >> It does not matter. rmsd is going to give you a number no matter if the >> molecules are aligned or not. The thing is how you interpret the number, so >> discussing about alignment does not apply for implementation, only for >> interpretation. Correspondence does apply. If not addressed, fine with me :) > Sure. But for the API, all we really care about is interpretation :-) > I think the name had better make clear which interpretation is > correct. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >

On Thu, Jul 9, 2009 at 3:42 PM, Keren Laskerkerenl@salilab.org wrote: > makes sense btut less convinate. If we agree on xyz I'll put in it in > algebra. I has the advantage of avoiding the questions of what happens when you don't have all the atoms (or any of them).

Plus, it isn't that much less convenient and does it make quite clear what you are computing the rmsd of.

rmsd(XYZs(get_leaves(m0)), XYZs(get_leaves(m1));

BTW, it can't go into algebra since algebra can't use core types due to linking issues. As a result, I would leave it in atom.

All clear here !

2009/7/9 Ben Webb ben@salilab.org

> On 07/09/2009 03:54 PM, Daniel Russel wrote: > >> BTW, it can't go into algebra since algebra can't use core types due >> to linking issues. As a result, I would leave it in atom. >> > > Agreed. It doesn't really make sense to go in algebra anyway. > > 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 >

On 07/09/2009 03:44 PM, Javier Ángel Velázquez Muriel wrote: > I agree with Dina, and still don't see why rmsd has to assume anything. > What you do before computing rmsd is your business. It is like sqrt(), > or cos(), or whatever. Provided the arguments are correct, the way you > interpret the result of the function is your business again.

Yes, Dina's interface looks like a good one to me (except that it should return double, and go in a separate header, as Daniel said). But it should definitely be stated in the function description that the size of the two XYZs need to be the same (as, presumably, they do), that a 1:1 correspondence is used, and (just to make it absolutely clear) that no kind of fitting is done before calculating the RMSD. I agree with Javi - calculating the RMSD, performing a superposition, and making an alignment are three separate things - but we should clarify it just to be sure.

Whenever I've seen RMSD used, it means coordinate RMSD. We routinely also use DRMSD in Modeller, of course.

Ben