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.