- IMP-dev - salilab.org

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

Fix behavior of DistanceRestraint at near-zero distance
by Ben Webb 13 Dec '07

13 Dec '07

Attached is a patch which corrects the math in DistanceRestraint. Currently if the interparticle distance is zero (or very near zero) DistanceRestraint pretends that the particles are randomly placed in near proximity, so that a random distance and derivatives are returned. This is because the derivatives of the distance at zero are undefined (the math is 0/0). IMHO, this behavior is flawed, because the score of a given state should always be the same - and the scoring function should be … [View More]

1 0

Re: [IMP-dev] First code review
by Ben Webb 13 Dec '07

13 Dec '07

Daniel Russel wrote: >> They come and complain to me in person. And it is hard to object to a >> change which isn't mentioned on the list, until much later when you >> realize your code doesn't work any more. > Recently? I haven't heard anyone complain in rather a while a month or so. That's because they complain only to me. > I agree that more should be on the list. I stopped emailing the list > because I was just getting complaints about their being too much … [View More]

1 0

Re: [IMP-dev] First code review
by Ben Webb 13 Dec '07

13 Dec '07

Daniel Russel wrote: >> You can't really expect changes to be committed rapidly if you make them >> before discussing the implications, because that requires everyone to >> agree with everything you do, which is not likely to be the case. ;) > Well, I don't think we have ever had an objection from anyone else :-) They come and complain to me in person. And it is hard to object to a change which isn't mentioned on the list, until much later when you realize your code … [View More]

1 0

Re: [IMP-dev] First code review
by Ben Webb 13 Dec '07

13 Dec '07

Daniel Russel wrote: > The problem is, I can't currently write very clean patches. I have to > produce them from overlapping changes I have already made. If it were > the case that the response time to the change were fast compared to the > frequency of these changes, then they could be cleaner. It will happen > eventually as things stabilize, just not quite yet. You can't really expect changes to be committed rapidly if you make them before discussing the implications, … [View More]

1 0