Re: [boost] [algorithm] Review Request: edit_distance

Subject: Re: [boost] [algorithm] Review Request: edit_distance
From: Erik Erlandson (eje_at_[hidden])
Date: 2014-01-30 10:20:17

----- Original Message -----

> 
> - My experience has been that early termination is best expressed
> in terms of RAM, i.e. the caller could indicate a maximum amount
> of RAM, in bytes, rather than a maximum for the edit cost.  You
> can probably convert between them via sizeof.

As I see it, there are three early-termination options on the table:

_max_cost
_max_memory
_max_time

Each of those has its potential utility.  It is easy to code them, and I have techniques to implement them so that they cost nothing when they aren't invoked:
https://gist.github.com/erikerlandson/7455677

A few questions on my mind:

1) Adding any further parameters will require increasing BOOST_PARAMETER_MAX_ARITY from its default value.  Is it best to just do that automatically in edit_distance.hpp, or explain to the user that they should do it? 

2) Currently, _max_cost comes paired with the _max_cost_exception flag.  Adding _max_memory and _max_time would seem to imply _max_memory_exception and _max_time_exception.  So now we have six optional parameters governing early-termination conditions.  Not sure I really have a problem with that, but it's getting populous.   It is possible that the '*_exception' flags could be collapsed to a single flag, say '_terminate_exception'.  I'm not sure how likely it is that a person would want to use fallback for one condition, and throw an exception on another.

3) maybe better names would be _terminate_cost, etc?

4) I see that there are now even monadic approaches to exception handling: boost::make_optional().  Is exception throwing deprecated?  Does make_optional require c++11?   Does _terminate_exception change from a boolean flag to an enumerated type: { fallback, exception, optional }?