Re: [IMP-dev] Proposal: replace BasicScoreFuncParams with PairPotential

[Daniel Russel <>]

On Jan 3, 2008, at 12:45 AM, Ben Webb wrote:
> How is this different from the current ScoreFuncs? (Or Modeller math
> forms, for that matter.) It seems like this is just a rename, yes?
Yes, no changes there, just a rename to make them descriptive and  
decouple them from the idea that they are anything more than just a  
function.

> > - A set of ParticlePairScoreFunctions. These take a pair of particles
> > and a DerivativeAccumulator and compute a score and the derivatives.
>
> And these would be functors? Taking a SingleVariableFunction as a
> parameter to the constructor, and two Particle* in the operator() ?
The constructor is not part of the ParticlePairScoreFunction  
interface, but many of the constructors for various PairScoreFunctions  
would probably take a SingleVariableFunction. And operator() or  
evaluate() would take two particles and a DA.

> >
> Of course, and only some of the existing restraints work that way  
> right
> now - my understanding is that Bret wrote them that way because 1) he
> didn't want to write a nonbonded list and 2) he liked to do everything
> at constructor time. There's no reason you couldn't do that at  
> evaluate
> time instead. And if somebody wants to use sub restraints, we should
> certainly let them. (As I understand it, your proposal does not  
> prohibit
> this.)
I am would not prohibit it, but I would not try to make it easy. Much  
of the complication with the current design is from trying to make it  
easy. Since
- I can't think of a case where creating trivial sub restraints would  
simplify the code
- we need to support generating the sub restraints on the fly since we  
will eventually have the non-bonded list,
- and the existing restraints are an awful mess,
I would like switch the gestalt.


> To clarify, are you suggesting that DistanceRestraint would simply
> instantiate and call a DistanceScoreFunction?
Yes. The main simplification here is that we would forget about  
translating ScoreFuncs since that would be handled by the restraint  
(not a DistanceRestraint) translating the distance appropriately ahead  
of time rather than forcing everything to be a plain vanilla  
DistanceRestraint.

If for some reason you want to create sub-restraints, you would write  
a DistanceRestraint-like class which doesn't delete its  
PairScoreFunction on destruction and create a mess of those.

> > The ParticlePairScoreFunctions would, among other things, subsume the
> > non-trivial code from the current DistanceRestraint making it more
> > easily usable.
>
> Can you clarify what you mean here? It seems like you'd just be moving
> the code wholesale from one class to the other. How does it simplify  
> it?
Two ways.
First, it is nice to be able to use the code without explicitly  
creating a new Restraint per particle pair. This would allow such  
usage. My NonbondedRestraint would just call the evaluate of a  
ParticlepairScoreFunction for each pair passed by the nonbonded list  
rather than having to create and destroy a DistanceRestraint.

Second I remove having one class of objects create instances of  
another class. A restraint either takes a PairScoreFunction which it  
keeps internally or a SingleVariableFunction which it likewise keeps  
internally. Neither of those create other objects on the heap and we  
don't provide any easy mechanism to do so.