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 > -- > 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