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

[Daniel Russel <>]

Since my emails are long, here in brief are the ideas (which can be  
chosen independently):
1) forget about function generators and just make the restraints shift  
the distance value itself before calling the ScoreFunc. Then each  
restraint just has one ScoreFunc and so modifications to it (such as  
reducing its stiffness) are easy.
2) separate the choice of pairs of particles from the actual  
computation on the pair. So we have a set of restraints each of which  
applies a computation to a differently generated set of pairs and a  
set of computation functions each of which simply computes on a pair.

On Jan 3, 2008, at 12:45 AM, Ben Webb wrote:

> 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
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev