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