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).
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)
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 > >
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 > >
participants (2)
-
Barak Raveh -
Daniel Russel