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 11:13:26

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

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

Or, we might unify all of it into a single parameter:

_terminate = cost(cost_thresold, [bool exception - defaults to false])
_terminate = time(time_threshold, etc)
_terminate = memory(mem_threhold, etc)

That is, 'cost', 'time' and 'memory' are data types that carry an appropriate threshold and a termination policy flag that defaults to 'false', aka 'fallback without exception.'   The above assumes only one kind of termination condition.  That might be OK.   Time, memory and cost are roughly surrogates of each other, and limiting any one of them limits the other two.

I guess it wouldn't be a c++ project if it didn't have a large, confusing solution space.

> 
> 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 }?
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>