Subject: Re: [boost] [gsoc-2013]Approximate string matching
From: Yu Jiang (sunlightt07_at_[hidden])
Date: 2013-04-26 13:25:58
> 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!