Daniel Russel wrote:
My suggestion would be:- A set of SingleVariableFunctions which are created some way or another and take a float and produce the score and the derivative. These include- Harmonic - Linear - HarmonicLowerBound - etc.
How is this different from the current ScoreFuncs? (Or Modeller math forms, for that matter.) It seems like this is just a rename, yes?
- 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() ?
- A set of restraints which take lists of particles. In general, there is no reason to do as the restraints currently do and create a large number of sub restraints. These only make the code longer and take more memory. Instead, the Restraints can simply call the ScoreFunc or ParticlePairScoreFunction as needed.
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.)
To clarify, are you suggesting that DistanceRestraint would simply instantiate and call a DistanceScoreFunction?
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?
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle