Well, it is not a potential, it generates scoring function terms. Perhaps something like ScoreFunctionCreator would be better.
More substantially, it is not clear to me that we shouldn't have it directly evaluate the score from the particles and skip the function object creation. Creating the ScoreFunc doesn't cache anything useful and just adds another layer of indirection. Internally they can use ScoreFuncs if they want.
On Jan 2, 2008, at 6:19 PM, Ben Webb wrote:
> I propose to replace BasicScoreFuncParams with classes derived from > PairPotential (of course the name is also up for discussion if you > hate > that one). This would then be used by restraints that need a ScoreFunc > generator (Connectivity, ExclusionVolume, PairConnectivity, > Proximity). > PairPotential classes are simple generators that create new ScoreFunc > objects, given two Particles: > > class PairPotential > { > public: > virtual ScoreFunc* create_score_func(Particle *p1, Particle *p2) = > 0; > }; > > class UpperBoundPairPotential : public PairPotential > { > public: > UpperBoundPairPotential(Float mean, Float stdev); > UpperBoundPairPotential(FloatKey radius, Float stdev); > ScoreFunc* create_score_func(Particle*, Particle*) { > return new HarmonicUpperBound(some_mean, some_stdev); > } > }; > > Restraints such as ProximityRestraint then take a pointer to a > PairPotential, and own it. The advantage is that ProximityRestraint's > two constructors (one using a fixed mean, and the other a fixed > particle > radius attribute) can now be collapsed into one; the 'add two radii > together to get a mean distance' logic is now in the PairPotential. > The > other advantage is that pair potentials which do not use mean/stdev at > all are straightforward. For example, a DOPE potential might look > something like: > > class DOPEPotential : public PairPotential > { > public: > DOPEPotential(); > ScoreFunc* create_score_func(Particle* p1, Particle* p2) { > return new CubicSpline(p1->get_value("atom_type"), > p2->get_value("atom_type")); > } > }; > > Any thoughts/problems? I can of course clarify if any of this is > unclear. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev