Re: [boost] [Math/nextafter] A question of naming functions...

From: John Maddock (john_at_[hidden])
Date: 2008-04-30 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
> floating-point 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.