
Boost : 
From: John Maddock (john_at_[hidden])
Date: 20080430 05:48:41
Paul A Bristow wrote:
>> I was undecided about this: but for large intervals a
>> std::difference_t
>> wouldn't be large enough, for example edit_distance(0.0, 1.0)
>> is approx
>> 1.97753e+032. Of course if you use for intervals that stretch
>> several orders of magnitude then you get what you deserve I guess!
>
> I can see the problem here  Would you need a difference_t with about
> as many bits as the floating point type?
Yep indeed.
> But I'm struggling to conceive of uses for this where the distance is
> so large?
> Perhaps someone can suggest some?
Well me too actually, although I can imagine some situations where you
generate large numbers by accident: consider a measuring the error of a
function where it's actually the absolute error that's low: in that
situation you can easily generate arbitrary large results.
In any case it's trivial to convert the floating point result to an integer
if required (via the new rounding/truncation functions for example if you
want error checking).
> Can't the inevitable integer overflow just be accepted when it
> happens?
>
> I also find the name edit_distance very unintuitive. In fact I
> struggle to see from how the definition in Wikipedia it is
> 'technically accurate'.
>
> "In information theory and computer science, the edit distance
> between two strings of characters is the number of operations
> required to transform one of them into the other. There are several
> different algorithms to define or calculate this metric".
The idea was to invoke the idea of "how many operations are required to get
from a to b".
> In this case, don't we have a clearly defined *fixed* sequence of
> things each of which is 'iterated' from one value to another by
> calling a 'next' so many times.
> So the distance is a count of the number of 'nexts'  or gaps or
> steps or hops, or preds or succs. So it feels to me that the result
> is naturally an integer type. If you use T then it is OK for
> floatingpoint types (but loses exactness eventually), but precludes
> use for some types for which next_* functions do make sense but are
> not useful for an integer result.
Not sure I follow.
> But I'm still struggling to find a better name, though 'nexts(a, b)'
> is short.
Um, what does "nexts" mean ?
How about "intervals" or "representations" or "representation_count" or
"interval_count" or... ?
Cheers, John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk