IMP-dev November 2008

imp-dev@salilab.org

7 participants
23 discussions

Re: [IMP-dev] 2D geometry
by Daniel Russel 12 Nov '08

12 Nov '08

On Nov 12, 2008, at 3:58 PM, Javier Ángel Velázquez-Muriel wrote: > - Vector2D is already done but I am fine with changes Lets make a unified ND vector. I have wanted 4D a bunch of times. > > - I am building a templated version of matrix for 1,2,3D. I didn't > know about matrix3d until yesterday If you want nice constructors (from lists of values) you can use the boost static assert functionality to make sure, at compile time, that the correct constructor is called for the correct dimensional vector/ matrix. > > - Images are going to be 2D matrices and header. BTW, have you looked at Boost.GIL? It is a general C++ image library in boost (which we are already linked against, in theory). > > > > 2008/11/12 Daniel Russel <drussel(a)gmail.com>: >> Or vector and matrix can be replaced by a single version templated >> on the >> dimension. We definitely don't want separate code bases for the 2 >> and 3D >> versions as it will be a pain to keep the set of operations in sync. >> >> On Nov 12, 2008, at 10:50 PM, Keren Lasker wrote: >> >>> Javi, >>> >>> For your 2D geometry classes (Vector2D, Matrix2D ...) - why not just >>> using the corresponding 3D classes and keeping Z fixed? >>> I think it is not too bad in performance and will save you a lot of >>> coding/debugging time. >>> >>> Keren. >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev(a)salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >>

2 1

Re: [IMP-dev] IMP-dev Digest, Vol 13, Issue 5
by Javier Ángel Velázquez Muriel 12 Nov '08

12 Nov '08

Hi, some comments here: 1) I am writing the 2D classes for vector, matrix , image, and image headers these days. image and imageheader will be part of the em module. the others, wherever you suggest. If you plan to do something similar, Keren, let me know. 2) It doesn't seem logical to me why transformations, rotations and matrices are not part of the kernel, or at least of a math module. Misc is an inappropriate module. 2008/11/11 <imp-dev-request(a)salilab.org>: > Send IMP-dev mailing list submissions to > imp-dev(a)salilab.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://salilab.org/mailman/listinfo/imp-dev > or, via email, send a message with subject or body 'help' to > imp-dev-request(a)salilab.org > > You can reach the person managing the list at > imp-dev-owner(a)salilab.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IMP-dev digest..." > > > Today's Topics: > > 1. Comments on transformation stuff (Daniel Russel) > 2. Re: Comments on transformation stuff (Keren Lasker) > 3. Re: Comments on transformation stuff (Daniel Russel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 11 Nov 2008 05:58:36 -0800 > From: Daniel Russel <drussel(a)gmail.com> > Subject: [IMP-dev] Comments on transformation stuff > To: List for IMP development <imp-dev(a)salilab.org> > Message-ID: <140EE0B9-B252-4CC3-BB75-210034CD4D1F(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Rotation3D: > - the protected methods should probably be private as nothing is > likely to inherit from Rotation3D and doxygen skips documenting > private methods and the methods are not general purpose > - it would be nice to be able to initialize from a vector and an angle > - the current constructor should probably say Euler angle somewhere in > its docs. > > Matrix3D: > - why are there the rotation methods there? A cleaner interface would > probably be to have a method is_rotation() and another get_rotation() > so you can check is is close to a rotation and then get the rotation3D > object out directly. Having to go through intermediates of some sort > is messy. > - it needs an operator[] which returns a vector3D (with appropriate > bounds checking and all that). > - I would suggest using \brief to define multi-line brief comments > > ParticleFunction: > - Why does ParticleFunction take Particles? If you want that it should > be ParticlesFunction, but it seems to me what we really want is for it > to only take one particle and then use apply methods if we want to > apply it to more than one. Otherwise we will be creating Particles > with one Particle everywhere. > - apply should be pure virtual so that you can tell if you got the > name or signature wrong when overriding it. > - at least one of the methods needs to be defined in a .cpp to get > linking and casting right when using multiple libraries > > > ------------------------------ > > Message: 2 > Date: Tue, 11 Nov 2008 16:12:03 -0500 > From: Keren Lasker <kerenl(a)salilab.org> > Subject: Re: [IMP-dev] Comments on transformation stuff > To: List for IMP development <imp-dev(a)salilab.org> > Message-ID: <25232B3D-FD3B-4F62-8002-FDF2C71A69BA(a)salilab.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Daniel - thanks for your good review! > I'll make the suggested changes. > I agree with everything on Rotation3D and Matrix3D. > Regarding ParticleFunction - see discussion below. > On Nov 11, 2008, at 8:58 AM, Daniel Russel wrote: > >> Rotation3D: >> - the protected methods should probably be private as nothing is >> likely to inherit from Rotation3D and doxygen skips documenting >> private methods and the methods are not general purpose >> >> - it would be nice to be able to initialize from a vector and an angle >> - the current constructor should probably say Euler angle somewhere in >> its docs. > > >> >> >> Matrix3D: >> - why are there the rotation methods there? A cleaner interface would >> probably be to have a method is_rotation() and another get_rotation() >> so you can check is is close to a rotation and then get the rotation3D >> object out directly. Having to go through intermediates of some sort >> is messy. >> - it needs an operator[] which returns a vector3D (with appropriate >> bounds checking and all that). >> - I would suggest using \brief to define multi-line brief comments >> >> ParticleFunction: >> - Why does ParticleFunction take Particles? If you want that it should >> be ParticlesFunction, but it seems to me what we really want is for it >> to only take one particle and then use apply methods if we want to >> apply it to more than one. Otherwise we will be creating Particles >> with one Particle everywhere. > yes ... , but then I'll have to do a loop each time I want to rotate a > molecule. > maybe it would be better to have MolecularHierarchyDecoratorFunction ? > So I could just give as input the root of the molecule? >> >> - apply should be pure virtual so that you can tell if you got the >> name or signature wrong when overriding it. > sure. >> >> - at least one of the methods needs to be defined in a .cpp to get >> linking and casting right when using multiple libraries > For some reason python can not find the function implementation if it > is in the cpp file. It happened to Joerg as well - is there anything > else other than updating the include/Sconscript, ,src/Sconscript and > pyext/misc.i ? >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > > ------------------------------ > > Message: 3 > Date: Tue, 11 Nov 2008 06:21:15 -0800 > From: Daniel Russel <drussel(a)gmail.com> > Subject: Re: [IMP-dev] Comments on transformation stuff > To: List for IMP development <imp-dev(a)salilab.org> > Message-ID: <3E4539AB-9408-416F-8A1E-414972A23206(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > >>> ParticleFunction: >>> - Why does ParticleFunction take Particles? If you want that it >>> should >>> be ParticlesFunction, but it seems to me what we really want is for >>> it >>> to only take one particle and then use apply methods if we want to >>> apply it to more than one. Otherwise we will be creating Particles >>> with one Particle everywhere. >> yes ... , but then I'll have to do a loop each time I want to rotate a >> molecule. > Write a method to apply it to a molecule. And another to apply it to a > Particles. >> >> maybe it would be better to have MolecularHierarchyDecoratorFunction ? >> So I could just give as input the root of the molecule? > If it takes a single particle it is easy enough to have a method which > traverses the hierarchy and applies it to each atom, for example. This > is annoying to do with the current definition. > > >> >>> >>> - apply should be pure virtual so that you can tell if you got the >>> name or signature wrong when overriding it. >> sure. >>> >>> - at least one of the methods needs to be defined in a .cpp to get >>> linking and casting right when using multiple libraries >> For some reason python can not find the function implementation if it >> is in the cpp file. It happened to Joerg as well - is there anything >> else other than updating the include/Sconscript, ,src/Sconscript and >> pyext/misc.i ? > I'm not quite sure what you mean. What exactly happens? And what were > you doing? See UnaryFunction as an example of how it should be. > > As it stands now, each library which uses ParticleFunction will have > its own definition of the base class and they will not be > interconvertible (i.e. a ParticleFunction defined in IMP.core cannot > be used in something in Kernel which expects a particlefunction). > > > ------------------------------ > > _______________________________________________ > IMP-dev mailing list > IMP-dev(a)salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > End of IMP-dev Digest, Vol 13, Issue 5 > ************************************** >

2 1

Comments on transformation stuff
by Daniel Russel 11 Nov '08

11 Nov '08

Rotation3D: - the protected methods should probably be private as nothing is likely to inherit from Rotation3D and doxygen skips documenting private methods and the methods are not general purpose - it would be nice to be able to initialize from a vector and an angle - the current constructor should probably say Euler angle somewhere in its docs. Matrix3D: - why are there the rotation methods there? A cleaner interface would probably be to have a method is_rotation() and another get_rotation() so you can check is is close to a rotation and then get the rotation3D object out directly. Having to go through intermediates of some sort is messy. - it needs an operator[] which returns a vector3D (with appropriate bounds checking and all that). - I would suggest using \brief to define multi-line brief comments ParticleFunction: - Why does ParticleFunction take Particles? If you want that it should be ParticlesFunction, but it seems to me what we really want is for it to only take one particle and then use apply methods if we want to apply it to more than one. Otherwise we will be creating Particles with one Particle everywhere. - apply should be pure virtual so that you can tell if you got the name or signature wrong when overriding it. - at least one of the methods needs to be defined in a .cpp to get linking and casting right when using multiple libraries

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev November 2008