A few more thoughts:
*) Cost functionals should take parameters, probably something like:
struct substitution_cost { double operator()(const T& a, const T& b) const { // return some distance metric between a and b that represents // cost of substitution. In the classic case, this just returns 1 // if a != b, and zero if a == b. } }
struct insertion_cost { double operator()(const T& a) const { // cost of deleting element (a), classic case is also just 1. } }
......
The third is to use a keyword argument scheme. Boost provides this, or at
least it did in the past. The one time I tried it, I personally didn't care for it, but that was several years ago and if it's widely used in the community then it should probably be considered. I'd defer to community opinions.
Thanks for your further thoughts! I agree with you. *) Edit distance can either just return the distance and nothing else, or
it can optionally return the actual sequence of edit operations and op-costs that yielded the distance measure. Returning just the cost allows for more internal efficiencies but it would probably be useful to supply variations that also return the actual edit sequence.
Seems interesting! But it may be hard to design the interface? I have no idea on this.. By the way, I have posted my proposal for this idea in this mail list, would you like to read it? Thanks!