On Thu, Jun 14, 2012 at 12:16 PM, Barak Raveh barak.raveh@gmail.com wrote:
> Daniel - there will still be also functors for lists of pairs right in > ParticleIndexPairs, Floats distances, right? ( so we can still cache a very > large list of pairwise distances efficiently)
What would you accomplish with that? Since the functor is bound with a template, repeatedly applying it to each pair in a list is efficient, do I don't see a benefit to providing hooks to handle lists explicity. That is, the FunctorDistancePairScore (there already is a DistancePairScore :-) would have a method like evaluate_indexes(ParticleIndexPairs, DA) { for (unsigned int i=0; i< pip.size(); ++i) { ret+=evaluate_index(pip[i], da); } return ret; } just passing off to the single pair method.
> > On Thu, Jun 14, 2012 at 11:23 AM, Daniel Russel drussel@gmail.com wrote: > >> Following further discussion after the meeting yesterday, Dina and I have >> an alternative proposal for how to move forward with distance-based >> scoring. The changes would be to provide a class >> >> template <class DistanceScore, class DistanceScoreAndDerivatives> >> class DistancePairScore{ >> ... >> }; >> >> The DistanceScore argument would be a functor (or a function) with the >> following signature >> >> double DistanceScore(Model *, ParticleIndexPair, double distance) >> >> where the return value is the score for the pair of particles separated >> by distance. And the DistanceScoreAndDerivatives argument would be the >> same except that it would return a pair of doubles, on for the score and >> one for the derivative. >> >> We would then (gradually), provide functor versions of the existing >> distance-based pair scores and implement the corresponding PairScores in >> terms of the functor and this template class. >> >> For python users, we could provide a python implementation of >> DistancePairScore that would allow experimenting with such pair scores (but >> which would be rather slow). >> >> The advantages of this over the proposed changes are mostly that of >> flexibility, efficiency and reduced amount of code to right. On the >> flexibility side, doing things this way makes it easier to create modified >> versions of existing pair scores (eg by weighting them) as that just >> requires writing a functor that calls the other functions and adds up the >> values with the expected weights. On the efficiency side, such an approach >> computes the distances and then uses them immediately, rather than storing >> them in memory and passing over the stored values repeatedly. And on the >> reduced code side, it just requires adding one non-trivial class (whose >> implementation already exists) and we had wanted to move the scoring >> computations to functors anyway (and that can be done on-demand). >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > > > -- > Barak > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >