I'd like to compute a SVD in IMP, so we need to revisit the question of linear algebra packages. The two main options as I see it are:
1) using some big blas implementation through boost.ublas's bindings. The advantages are that operations will then be really fast. The disadvantages are that is is a bit complicated and introduces an (easy, since basically all systems have some blas library installed) external dependency.
2) use TNT. The advantages are that is is header only and has a nice license so we can hide it away internally. On the flip side, we can't count on it being installed so we have to hide it away internally, and it isn't the best implementation of things. It is also a bit limited (but SVD can solve all problems :-).
Unless there are counter proposals, I'll stick a copy of TNT in somewhere.
Daniel Russel wrote: > I'd like to compute a SVD in IMP, so we need to revisit the question > of linear algebra packages. The two main options as I see it are: > > 1) using some big blas implementation through boost.ublas's bindings. The > advantages are that operations will then be really fast. The > disadvantages are that is is a bit complicated and introduces an (easy, > since basically all systems have some blas library installed) external > dependency. > > 2) use TNT. The advantages are that is is header only and has a nice > license so we can hide it away internally. On the flip side, we can't > count on it being installed so we have to hide it away internally, and > it isn't the best implementation of things. It is also a bit limited > (but SVD can solve all problems :-). > > Unless there are counter proposals, I'll stick a copy of TNT in somewhere.
TNT sounds good to me. I'll create an 'algebra' IMP module to put it in. Javi also has some matrix code that would sensibly live in this module.
Ben
On Jan 15, 2009, at 7:53 PM, Ben Webb wrote:
> Daniel Russel wrote: >> I'd like to compute a SVD in IMP, so we need to revisit the question >> of linear algebra packages. The two main options as I see it are: >> 1) using some big blas implementation through boost.ublas's >> bindings. The >> advantages are that operations will then be really fast. The >> disadvantages are that is is a bit complicated and introduces an >> (easy, since basically all systems have some blas library >> installed) external dependency. >> 2) use TNT. The advantages are that is is header only and has a >> nice license so we can hide it away internally. On the flip side, >> we can't count on it being installed so we have to hide it away >> internally, and it isn't the best implementation of things. It is >> also a bit limited (but SVD can solve all problems :-). >> Unless there are counter proposals, I'll stick a copy of TNT in >> somewhere. > > TNT sounds good to me. I'll create an 'algebra' IMP module to put it > in. Javi also has some matrix code that would sensibly live in this > module. Do we want to module to just have the algebra or to have restraints and things which use the algebra code? I would vote for the former. Also, Rotation3D and Transformation3D should probably go there.
> Do we want to module to just have the algebra or to have restraints and > things which use the algebra code? I would vote for the former. Also, > Rotation3D and Transformation3D should probably go there.
Agreed on both points.
Ben
so - algebra will include geometry ? Should not we seperate the two?
On Fri, 16 Jan 2009, Ben Webb wrote:
>> Do we want to module to just have the algebra or to have restraints and >> things which use the algebra code? I would vote for the former. Also, >> Rotation3D and Transformation3D should probably go there. > > Agreed on both points. > > 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 >
On Jan 16, 2009, at 8:13 AM, Keren Lasker wrote:
> so - algebra will include geometry ? > Should not we seperate the two? Most interesting geometry we do is algebraic anyway :-) We could just call it math. That is shorter too :-)
I vote for "math".
> Most interesting geometry we do is algebraic anyway :-) We could just > call it math. That is shorter too :-) > > I vote for "math".
I like the name, but unfortunately it would complicate the Python interface. If someone says "import math" in an IMP Python module they won't get the standard Python math library - they'll get IMP.math. This is because Python by default does a relative import before an absolute import. Fortunately they realized that this is a bad idea, so the default has changed in Python 3.0 (and can be imported from __future__ in Python 2.6). But obviously we can't require everybody use Python 2.6 or 3.0. It's not impossible to import the standard math module from IMP, but it is very awkward - see the workaround to import modeller from IMP.modeller. This additional complication is why I prefer algebra to math.
Ben
> I like the name, but unfortunately it would complicate the Python > interface. If someone says "import math" in an IMP Python module they > won't get the standard Python math library - they'll get IMP.math. This > is because Python by default does a relative import before an absolute > import. Fortunately they realized that this is a bad idea, so the > default has changed in Python 3.0 (and can be imported from __future__ > in Python 2.6). But obviously we can't require everybody use Python 2.6 > or 3.0. It's not impossible to import the standard math module from IMP, > but it is very awkward - see the workaround to import modeller from > IMP.modeller. This additional complication is why I prefer algebra to math. > Either way, but lets get something in there.
http://math.nist.gov/~RPozo/tnt/
Is this TNT that you talk about? It looks reasonable for SVD only, but it has a limited extendibility. My opinion depends on to what extends we will use a linear algebra package. If we have any other plans for implementing more complicated linear algebra, then I would like to vote for Boost ublas's binding since it will provide more functionality.
- Seung Joong Kim
Daniel Russel wrote: > I'd like to compute a SVD in IMP, so we need to revisit the question > of linear algebra packages. The two main options as I see it are: > > 1) using some big blas implementation through boost.ublas's bindings. The > advantages are that operations will then be really fast. The > disadvantages are that is is a bit complicated and introduces an > (easy, since basically all systems have some blas library installed) > external dependency. > > 2) use TNT. The advantages are that is is header only and has a nice > license so we can hide it away internally. On the flip side, we can't > count on it being installed so we have to hide it away internally, and > it isn't the best implementation of things. It is also a bit limited > (but SVD can solve all problems :-). > > Unless there are counter proposals, I'll stick a copy of TNT in > somewhere. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Yeah, TNT is limited. Svd, LU and eigenvalues. It is trivial enough to stick in to imp that switching to boost later would not result in a big loss of effort.
On Jan 15, 2009, at 8:54 PM, Seung Joong Kim sjkim@salilab.org wrote:
> http://math.nist.gov/~RPozo/tnt/ > > Is this TNT that you talk about? It looks reasonable for SVD only, > but it has a limited extendibility. My opinion depends on to what > extends we will use a linear algebra package. If we have any other > plans for implementing more complicated linear algebra, then I would > like to vote for Boost ublas's binding since it will provide more > functionality. > > - Seung Joong Kim > > > Daniel Russel wrote: >> I'd like to compute a SVD in IMP, so we need to revisit the question >> of linear algebra packages. The two main options as I see it are: >> >> 1) using some big blas implementation through boost.ublas's >> bindings. The >> advantages are that operations will then be really fast. The >> disadvantages are that is is a bit complicated and introduces an >> (easy, since basically all systems have some blas library >> installed) external dependency. >> >> 2) use TNT. The advantages are that is is header only and has a >> nice license so we can hide it away internally. On the flip side, >> we can't count on it being installed so we have to hide it away >> internally, and it isn't the best implementation of things. It is >> also a bit limited (but SVD can solve all problems :-). >> >> Unless there are counter proposals, I'll stick a copy of TNT in >> somewhere. >> _______________________________________________ >> 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
can we change the apply function to const ? The only thing that should change as a result of the apply function is the state of the Particle and not the Modifier itself.
The reasons I left it non-const are - we currently don't pass around pointers to const Objects anywhere (all the containers give you back non-const objects and all the functions take non-const ones) - there is no concept of const in python - it is useful to be able to do things like count the number of particles with a given property in the modifier without declaring the counter mutable (yes, it isn't necessarily a modifier then) - restraint::evaluate is non-const and that is a similar function. On the other hand UnaryFunction::evaluate is const, so we are not very consistent.
Anyway, I am fine either way. If we want to switch it I can do it as part of moving the base classes to the kernel.
On Jan 21, 2009, at 5:49 PM, Keren Lasker wrote:
> can we change the apply function to const ? > The only thing that should change as a result of the apply function > is the state of the Particle and not the Modifier itself. > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Jan 21, 2009, at 6:13 PM, Daniel Russel wrote:
> The reasons I left it non-const are > - we currently don't pass around pointers to const Objects anywhere > (all the containers give you back non-const objects and all the > functions take non-const ones) > - there is no concept of const in python We still have a lot of functions on the c++/swig interface that are const - why should apply be special ? > > - it is useful to be able to do things like count the number of > particles with a given property in the modifier without declaring > the counter mutable (yes, it isn't necessarily a modifier then) > - restraint::evaluate is non-const and that is a similar function. > On the other hand UnaryFunction::evaluate is const, so we are not > very consistent. > > Anyway, I am fine either way. If we want to switch it I can do it as > part of moving the base classes to the kernel. > I think that it makes sense for a function like modifier::apply and restraint::evaluate to be const - but this is major change in the interfaces of base classes - so we should get agreement from Ben as well for that. > > On Jan 21, 2009, at 5:49 PM, Keren Lasker wrote: > >> can we change the apply function to const ? >> The only thing that should change as a result of the apply function >> is the state of the Particle and not the Modifier itself. >> >> _______________________________________________ >> 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
>> >> Anyway, I am fine either way. If we want to switch it I can do it >> as part of moving the base classes to the kernel. >> > I think that it makes sense for a function like modifier::apply and > restraint::evaluate to be const - but this is major change in the > interfaces of base classes - so we should get agreement from Ben as > well for that. The bigger question is whether there is any existing code that takes advantage of them being non-const. I suspect not, and if not, it is actually a very minor change (due to the IMP_RESTRAINT macro and the few SingletonModifiers).
Keren Lasker wrote: > I think that it makes sense for a function like modifier::apply and > restraint::evaluate to be const - but this is major change in the > interfaces of base classes - so we should get agreement from Ben as well > for that.
That makes perfect sense to me.
Ben
participants (4)
-
Ben Webb -
Daniel Russel -
Keren Lasker -
Seung Joong Kim