Re: [boost] [gsoc-2013]Approximate string matching

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!