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

From: John Maddock (john_at_[hidden])
Date: 2008-04-30 04:52:44

dherring_at_[hidden] wrote:
> On Tue, 29 Apr 2008, John Maddock wrote:
>
>> Folks I'm looking for some good names for some functions I'm on the
>> brink of adding to Boost.Math (all in namespace boost::math::):
>>
>> T nextafter(T val, T dir)
>> T next_greater(T val)
>> T next_less(T val)
>
> Given the first name is fixed, this is a reasonable family of names;
> though dropping the underscore would increase consistency.  However,
> there
> is the ambiguity whether greater/less reference zero or infinity.

Not sure what you mean there, next_greater returns a value that is strictly 
greater than the argument (so always moves towards positive infinity).

> nextpositive() and nextnegative() might be clearer.  Why does this
> remind
> me of IEEE-754 rounding modes?
>
>
>> T edit_distance(T a, T b)
>>
>> Returns the number of floating point representations between values
>> a and b.
>>
>> So the questions are: can you think of any better names, or are
>> these OK?
>>
>> And should edit_distance return a signed or absolute value?
>
> I'm at a loss for a better name (representation_distance seems overly
> verbose but interval_size might be ok), but do have a couple questions
> about this function's behavior.
>
> Why is the return value templated?  Shouldn't it be some fixed
> diff_t?  I tentatively agree with the other comment that a signed
> distance is
> preferable to unsigned.

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!

> Shouldn't this return the number of gaps, rather than the number of
> representations?  Consider the following examples
>
> float x=1.0;
> float y=2.0;
> int d=edit_distance(x, y);
> float z=x;
> for(int i=0; i<d; i++)
> {
>   z=next_greater(z);
> }
> // Does y==z?

A rather long running program, but yes: edit_distance(next_less(x), x) == 1.

> z=x;
> for(int i=0; i<d/2; i++)
> {
>   z=next_greater(z);
> }
> // Does y==(x+z)/2, given the right rounding mode?

Change i<d/2 to i<2*d and yes I believe so.

HTH, John.