Re: [boost] RFC: edit_distance / edit_alignment library

Subject: Re: [boost] RFC: edit_distance / edit_alignment library
From: Erik Erlandson (eje_at_[hidden])
Date: 2013-12-16 11:37:23

----- Original Message -----
> On 12/14/2013 03:54 AM, Erik Erlandson wrote:
> 
> > I've been considering possible alternate names for the functions:
> > edit_distance / edit_alignment
> > or: edit_cost / edit_path
> > or: edit_cost / edit_script
> 
> I suggest that you rename the boost::algorithm::sequence_alignment
> namespace to boost::algorithm::edit. 

My original idea for boost::algorithm::sequence_alignment was that it could also serve as a home for other sequence alignment algorithms, such as BLAST, or HMMs.   However, that is pretty speculative.

> Then we can drop the "edit_"
> prefix on the function names, giving boost:algorithm::edit::distance
> and likewise for alignment.

Just 'distance' or 'alignment' (or 'path') seem like they might be too generic.  The likelihood that they'd need to be qualified seems higher.  I'll give it some thought.

> The edit::distance is reminiscient of std::distance, so I think that
> name should be retained. I have no strong opinion about edit::alignment.
> Research papers use "edit alignment" but I find "edit path" slightly
> more descriptive.

I've been leaning toward 'edit_distance' and 'edit_path'.   My survey of the literature hasn't given me any impression of an unambiguous standard for terminology.

> Talking about naming, it may be a good idea avoid abbreviations for
> some of the names. So "allow_sub" could become "allow_substitution"
> (or just "substitution".)

Agreed, my abbreviations aren't really warranted.

> 
> Likewise, the cost function object has names like cost_ins and cost_del,
> but as these are already located inside the cost function object, they
> could be renamed to insertion and deletion (or erasure to match the STL
> namining a bit better.)

That makes sense.  I could do the same for the output function object.