Boost logo

Boost :

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:


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:

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 }?

Boost list run by bdawes at, gregod at, cpdaniel at, john at