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.