December 2007 - IMP-dev

change IMP.ParticleVector to IMP.Partcles
by Daniel Russel 17 Dec '07

17 Dec '07

to be consistent with everything else (I don't like having the name Vector in python code as it acts like a python list). And the name Particles is already used for it in C++. Changed the distance test case to use it.

1 0

Add square function
by Daniel Russel 16 Dec '07

16 Dec '07

I added a template function square to utility.h which computes the square of any object. In order to make sure it gets tested I cleaned up the implementation of DistanceRestraint and made it use the square function. Since python has the ** operator already, I don't see any reason to export this function to python at the moment.

1 0

Re: [IMP-dev] Update SphericalRestraint
by Ben Webb 16 Dec '07

16 Dec '07

Daniel Russel wrote: > I think we may want to think about removing the list of particles from > the Restraint base class and providing several restraint subclasses > which use different containers to store the particles (this would be a > fairly minor change given the IMP_RESTRAINT macro and the current > interface). Then, we could have restraints which require a dynamic set > use a std::set, and ones which just have a static list or (like distance > restraint) a … [View More]

2 3

[Fwd: Build system failure, 12/16/2007]
by Ben Webb 16 Dec '07

16 Dec '07

Looks like Daniel's static variable initialization check caught some badness on IMP Windows builds (see below; the x86_64 build also failed, but I suspect that's an intermittent NFS issue). Patches to fix this are welcomed. ;) P.S. I suspect most of you don't have access to a Windows box with MSVC and scons installed. So to build IMP with MSVC, build it on synth and pass 'wine=true' to your scons invocation. That'll run the MS tools on Linux using Wine. Ben -------- Original Message --… [View More]

1 0

First significant code review
by Daniel Russel 14 Dec '07

14 Dec '07

I changed the interfaces of DistanceRestraint and ExclusionRestraint to make them more consistent and more general. Warning, it is quite long due to many similar changes in the test cases. Yeah for sed, but I wouldn't want to read through the diff :-) DistanceRestraint now takes a pair of ParticleIndexes and a ScoreFunc which it then owns. I also removed the constructor with a passed radius as that does add any power and adds another path which has to be tested and maintained. … [View More]

2 6

SphereRestraint
by Daniel Russel 14 Dec '07

14 Dec '07

This diff removes CoordinateRestraint and adds SphereRestraint which restraints a point's distance to a fixed point. It also makes the vectori to Int change. The XYZ decorators patch is also attached again as the previous version didn't quite split things right (I had needed to add methods to Particle.h to changed the optimized status of a float).

2 4

Changing vectori vectorf
by Daniel Russel 14 Dec '07

14 Dec '07

I propose we change IMP.vectori and IMP.vectorf to IMP.Ints and IMP.Floats to be consistent. Any objections?

3 3

Minor changes to xyzdecorator
by Daniel Russel 14 Dec '07

14 Dec '07

Here are some minor changes to the XYZDecorator. It now always creates the keys since we are always using the. This means that the get_coordinate_key(i) method doesn't have to check when getting the keys out. It also has methods to change whether the particle is optimized or not. These methods are checked as part of the SphereRestraint patch I will submit separately.

1 0

CoordinateRestraint
by Daniel Russel 14 Dec '07

14 Dec '07

It seems entirely useless to me as written as it can only restrict coordinates relative to the origin. I propose getting rid of it and instead providing, as needed, SphericalDistanceRestraint (restraint the distance from a fixed point), CoordinateRestraint (which restricts a coordinate relative to a fixed value) etc. The names could use some work. My suggestion for SphericalDistanceRestraint (which is what I want) is: SphericalDistanceRestraint(Model*, ParticleIndex (or Particle*), … [View More]

2 4

Re: [IMP-dev] Fix behavior of DistanceRestraint at near-zero distance
by Ben Webb 13 Dec '07

13 Dec '07

Daniel Russel wrote: > Fine with me with a few comments. > > I don't know that counting on pre-optimization perturbation is > reasonable as a degeneracy could arise during an optimization. That > said, in most cases, other forces should cause the two particles to > diverge even if the degenerate distance restraint does not. Agreed. The probability of two particles ending up in exactly the same position is rather small (unless you have a force pulling them together). … [View More]

1 0