[Math/nextafter] A question of naming functions...
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) Returns the next representable floating point value to "val" in the direction of "dir". This name is basically fixed, since it's the one that C99 uses. T next_greater(T val) Returns the next representable value greater than "val". T next_less(T val) Returns the next representable value less than "val". 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? Thanks in advance, John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 29 April 2008 11:16 To: Boost mailing list Subject: [boost] [Math/nextafter] A question of naming functions...
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)
Returns the next representable floating point value to "val" in the direction of "dir". This name is basically fixed, since it's the one that C99 uses.
Wrinkles nose - but you're right - can't change this nasty name.
T next_greater(T val)
Returns the next representable value greater than "val".
T next_less(T val)
Returns the next representable value less than "val".
pred and succ have been used elsewhere. They are shorter.
T edit_distance(T a, T b)
Returns the number of floating point representations between values a and b.
Definitely useful. Not convinced by this name, but I'll think about it. Signed sounds obvious but I suspect choice may be more complicated than it seems. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
T next_greater(T val)
Returns the next representable value greater than "val".
T next_less(T val)
Returns the next representable value less than "val".
pred and succ have been used elsewhere. They are shorter.
I disagree with Paul here: I prefer the longer, more descriptive names, especially in a general purpose library.
T edit_distance(T a, T b)
Returns the number of floating point representations between values a and b.
A useful function, with a technically accurate name. Works for me. -- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Kevin Lynch Sent: 29 April 2008 17:35 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
T next_greater(T val) Returns the next representable value greater than "val".
T next_less(T val) Returns the next representable value less than "val".
pred and succ have been used elsewhere. They are shorter.
I disagree with Paul here: I prefer the longer, more descriptive names, especially in a general purpose library.
Fine - I agree - I'm only reporting what I have seen used elsewhere.
T edit_distance(T a, T b)
Returns the number of floating point representations between values a and b.
A useful function, with a technically accurate name. Works for me.
The edit bit sounds odd to me - and uses I have found are applied to *strings* when the name makes some sense - the number of typing mistakes you need to make ;-) Can you enlighten me on why it is a "technically accurate" name here? Paul PS Are we choosing names for posssible specializations of other types than floating-point? derived FP, integer, char, strings, intervals... --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
on Tue Apr 29 2008, Kevin Lynch <krlynch-AT-bu.edu> wrote:
Paul A Bristow wrote:
T next_greater(T val)
Returns the next representable value greater than "val".
T next_less(T val)
Returns the next representable value less than "val".
pred and succ have been used elsewhere. They are shorter.
I disagree with Paul here: I prefer the longer, more descriptive names, especially in a general purpose library.
We do have next() and prior() (not abbreviations!) already, which have meaning for iterators, integers, etc. -- Dave Abrahams Boost Consulting http://boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: 01 May 2008 19:47 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
on Tue Apr 29 2008, Kevin Lynch <krlynch-AT-bu.edu> wrote:
T next_greater(T val) Returns the next representable value greater than "val". T next_less(T val) Returns the next representable value less than "val".
We do have next() and prior() (not abbreviations!) already, which have meaning for iterators, integers, etc.
Doh! So why didn't I remember that! next and prior sound entirely intuitive to me. However John has specifically limited his question to floating-point types. (I'm not totally convinced this is wise). I think many novice non-mathematician, but not entirely floating-point naïve, users will want these functions. But none of suggestions so far for the difference or distance really grabs me. Complicated mathy terms like edit_difference and distance will not be what the above users will be looking for, even if they are what they need. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
But none of suggestions so far for the difference or distance really grabs me.
I would agree with you here....
Complicated mathy terms like edit_difference and distance will not be what the above users will be looking for, even if they are what they need.
... but would also point out that you can't call EVERYTHING next or prior or prev or succ or ... When you are dealing with technically detailed, domain specific functions, you should (in my opinion, of course) use longer, more detailed names for disambiguation and clarity.
Paul
-- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------
AMDG Paul A Bristow wrote:
T edit_distance(T a, T b)
Returns the number of floating point representations between values a and b.
Definitely useful.
Not convinced by this name, but I'll think about it.
Signed sounds obvious but I suspect choice may be more complicated than it seems.
It's more intuitive to get the unsigned value from the signed than the other way around. std::abs(edit_distance(a, b)) vs. copysign(edit_distance(a, b), b - a) In Christ, Steven Watanabe
Steven Watanabe wrote:
It's more intuitive to get the unsigned value from the signed than the other way around. std::abs(edit_distance(a, b))
vs.
copysign(edit_distance(a, b), b - a)
Yep, that's sort of the view I'm coming round to: even though I implemented it as returning an unsigned value initially :-( John.
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. 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. 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? z=x; for(int i=0; i<d/2; i++) { z=next_greater(z); } // Does y==(x+z)/2, given the right rounding mode? Thanks, Daniel
dherring@ll.mit.edu 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.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 30 April 2008 09:53 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
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!
I can see the problem here - Would you need a difference_t with about as many bits as the floating point type? But I'm struggling to conceive of uses for this where the distance is so large? Perhaps someone can suggest some? 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". 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. But I'm still struggling to find a better name, though 'nexts(a, b)' is short. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
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.
floatdistance(lhs, rhs)? And as someone noted earlier, it should be the number of gaps, or rather: the number of times nextafter needs to be applied to lhs in order to obtain rhs. Otherwise, the "number of representations between lhs and rhs" is 0 in two cases, when rhs==lhs or when rhs == nextafter(lhs). -- Hervé Brönnimann hervebronnimann@mac.com On Apr 30, 2008, at 5:35 AM, Paul A Bristow wrote:
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'. ... But I'm still struggling to find a better name, though 'nexts(a, b)' is short.
Paul
--- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Hervé Brönnimann wrote:
floatdistance(lhs, rhs)?
Maybe :-)
And as someone noted earlier, it should be the number of gaps, or rather: the number of times nextafter needs to be applied to lhs in order to obtain rhs. Otherwise, the "number of representations between lhs and rhs" is 0 in two cases, when rhs==lhs or when rhs == nextafter(lhs).
Yep, that's what it *does*, it's figuring out how to explain it correctly! Thanks, John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hervé Brönnimann Sent: 30 April 2008 12:20 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
floatdistance(lhs, rhs)?
Would adding an underscore be nicer: FPT float_distance(FPT lhs, FPT rhs); And to be clear, this (and the other next functions) *only* apply to floating-point types. (not integer, not decimal, not interval, or any other type)? next_distance() is another possible that does not explicitly limit to floating point. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hervé Brönnimann Sent: 30 April 2008 12:20 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
floatdistance(lhs, rhs)?
Would adding an underscore be nicer:
FPT float_distance(FPT lhs, FPT rhs);
That's more to the Boost style of things.
And to be clear, this (and the other next functions) *only* apply to floating-point types. (not integer, not decimal, not interval, or any other type)?
AS far as the current implementation is concerned it's strictly limited to floating point values, represented in base 2. John.
Shouldn't the return type be integral, though? And long long (or int64) for double? Sent via BlackBerry from T-Mobile -----Original Message----- From: John Maddock <john@johnmaddock.co.uk> Date: Wed, 30 Apr 2008 13:16:03 To:boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions... Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hervé Brönnimann Sent: 30 April 2008 12:20 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
floatdistance(lhs, rhs)?
Would adding an underscore be nicer:
FPT float_distance(FPT lhs, FPT rhs);
That's more to the Boost style of things.
And to be clear, this (and the other next functions) *only* apply to floating-point types. (not integer, not decimal, not interval, or any other type)?
AS far as the current implementation is concerned it's strictly limited to floating point values, represented in base 2. John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Shouldn't the return type be integral, though? And long long (or int64) for double? Sent via BlackBerry from T-Mobile -----Original Message----- From: John Maddock <john@johnmaddock.co.uk> Date: Wed, 30 Apr 2008 13:16:03 To:boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions... Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hervé Brönnimann Sent: 30 April 2008 12:20 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
floatdistance(lhs, rhs)?
Would adding an underscore be nicer:
FPT float_distance(FPT lhs, FPT rhs);
That's more to the Boost style of things.
And to be clear, this (and the other next functions) *only* apply to floating-point types. (not integer, not decimal, not interval, or any other type)?
AS far as the current implementation is concerned it's strictly limited to floating point values, represented in base 2. John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John Maddock wrote:
Johan Råde wrote:
floatdistance(lhs, rhs)? Would adding an underscore be nicer:
FPT float_distance(FPT lhs, FPT rhs); How about discrete_distance?
That's not bad at all actually,
Thanks, John.
To me the word distance suggests an unsigned quantity. Maybe discrete_difference? --Johan
Johan Råde wrote:
John Maddock wrote:
Johan Råde wrote:
floatdistance(lhs, rhs)? Would adding an underscore be nicer:
FPT float_distance(FPT lhs, FPT rhs); How about discrete_distance?
That's not bad at all actually,
Thanks, John.
To me the word distance suggests an unsigned quantity.
Same here, but...
Maybe discrete_difference?
The word difference in the context of a numerical operation suggests a numerical difference, so I feel that distance suits better here. I like "representation_distance". To me it says exactly what it is. And I would even call it "rep_distance" since 'rep' is a fairly common abbreviation. Anyway, don't we want to also have the 'cousin' function: "representation_advance", such that: representation_advance(x,representation_distance(x,y)) == y always holds for any x,y? That identity makes it clear that the distance is signed. Best -------- Fernando Cacciola SciSoft http://scisoft-consulting.com http://fcacciola.50webs.com
Fernando Cacciola wrote:
Johan Råde wrote:
John Maddock wrote:
Johan Råde wrote:
> floatdistance(lhs, rhs)? Would adding an underscore be nicer:
FPT float_distance(FPT lhs, FPT rhs); How about discrete_distance? That's not bad at all actually,
Thanks, John. To me the word distance suggests an unsigned quantity.
Same here, but...
Maybe discrete_difference?
The word difference in the context of a numerical operation suggests a numerical difference, so I feel that distance suits better here.
I like "representation_distance". To me it says exactly what it is. And I would even call it "rep_distance" since 'rep' is a fairly common abbreviation.
Anyway, don't we want to also have the 'cousin' function: "representation_advance", such that:
representation_advance(x,representation_distance(x,y)) == y
always holds for any x,y?
That identity makes it clear that the distance is signed.
Best
Hmm, the concept we are discussing is related to the set of possible values of a floating point number type, but not necessarily to the representation of these values. Also, if we calculate the xxx_distance between a positive and a negative number, do we count positive and negative zero separately? I suppose not. The name representation_distance suggests that we might. --Johan
So, it looks like so far we have: next(val) prior(val) and either of representation_distance(a, b); discrete_distance(a, b); Whilst I'm normally all in favour of "long_meaningful_names_with_underscores", next() and prior() do look OK to me: especially so long as they're in namespace boost::math. Like Paul, I'm still looking for the right "killer name" for the *_distance function, I quite like "maddock_metric" but I doubt anyone will know what that means :-) Given that this function is inherently related to the "units in the last place" metric, I wonder if we can compose a name from that? Maybe extending the API slightly how about: T upl_distance(T, T); // "representation distance" T relative_distance(T, T); // AKA relative error. T ulp(T); // distance between arg and next(arg) Thoughts? Thanks, John.
On Mon, May 5, 2008 at 6:48 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Given that this function is inherently related to the "units in the last place" metric, I wonder if we can compose a name from that?
Maybe extending the API slightly how about:
T upl_distance(T, T); // "representation distance" T relative_distance(T, T); // AKA relative error. T ulp(T); // distance between arg and next(arg)
Thoughts?
I like these a lot. I was thinking about suggesting ulp_* names last week but didn't want to get into a discussion on a subject I'm not very knowledgeable about. --Michael Fawcett
John Maddock wrote:
So, it looks like so far we have:
next(val) prior(val)
and either of
representation_distance(a, b); discrete_distance(a, b);
I'm still a bit unhappy about calling a signed quantity a "distance". I would prefer "difference". Let me elaborate: To me a "distance" is a quantity that satisfies the rules: d(x,y) >= 0 d(x,x) = 0 d(y,x) = d(x,y) d(x,y) + d(y,z) >= d(x,z) while a "difference" is a quantity that satisfies the rules d(x,x) = 0 d(y,x) = -d(x,y) d(x,y) + d(y,z) = d(x,z) The function we are discussing satisfies the second set of rules. --Johan
Johan: you can construct an iterator wrapper that map operator++ to next(float), and then it *really* is the specialization of std::distance() for this iterator type. In my opinion, difference implies an algebraic structure (which there is on float, but not what you want). I hope this convinces you that distance is the right name. HB Sent via BlackBerry from T-Mobile -----Original Message----- From: Johan Råde <rade@maths.lth.se> Date: Mon, 05 May 2008 17:10:09 To:boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions... John Maddock wrote:
So, it looks like so far we have:
next(val) prior(val)
and either of
representation_distance(a, b); discrete_distance(a, b);
I'm still a bit unhappy about calling a signed quantity a "distance". I would prefer "difference". Let me elaborate: To me a "distance" is a quantity that satisfies the rules: d(x,y) >= 0 d(x,x) = 0 d(y,x) = d(x,y) d(x,y) + d(y,z) >= d(x,z) while a "difference" is a quantity that satisfies the rules d(x,x) = 0 d(y,x) = -d(x,y) d(x,y) + d(y,z) = d(x,z) The function we are discussing satisfies the second set of rules. --Johan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Herve Bronnimann wrote:
Johan: you can construct an iterator wrapper that map operator++ to next(float), and then it *really* is the specialization of std::distance() for this iterator type. In my opinion, difference implies an algebraic structure (which there is on float, but not what you want). I hope this convinces you that distance is the right name.
I very much like the idea of having an iterator wrapper, mapping operator++ to next(float). Actually I once wrote such an iterator myself :-) Would it be worth adding such a "float_iterator" to Boost? If so, the "upl distance" function could simply be called "operator minus" :-) float_iterator::difference_type operator-( const float_iterator & lhs, const float_iterator & rhs); BTW, I was thinking of having a template, basic_float_iterator<T>, for T being either float or double... Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
hervebronnimann@mac.com wrote:
Johan: you can construct an iterator wrapper that map operator++ to next(float), and then it *really* is the specialization of std::distance() for this iterator type.
You are right. (And std::distance is poorly named. What on earth was Alex Stepanov thinking?) --Johan
I have one qualm about next / prior / rep or discrete distance names: they do not indicate at all that the operation is tied to *floating-point* representation! Imho, a major omission. Especially discrete_distance is bad from that point of view. That is why I suggested and still prefer next_float / prior_float / floating_distance names. Perhaps next_float_distance is even better. Regarding ulp_distance, I might also work but the name is misleading, I think. It would likely be understood by someone relying on name rather than reading docs to mean: the number of times you have to add ulp to x to obtain y??? Regarding ulp(T), the comment is wrong: that is not the ulp_distance between x and next(x), that would be one. Or else I misunderstood ulp_distance. Back to square one... Just a few personal thoughts, please feel free to disregard. Sent via BlackBerry from T-Mobile -----Original Message----- From: John Maddock <john@johnmaddock.co.uk> Date: Mon, 05 May 2008 11:48:22 To:boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions... So, it looks like so far we have: next(val) prior(val) and either of representation_distance(a, b); discrete_distance(a, b); Whilst I'm normally all in favour of "long_meaningful_names_with_underscores", next() and prior() do look OK to me: especially so long as they're in namespace boost::math. Like Paul, I'm still looking for the right "killer name" for the *_distance function, I quite like "maddock_metric" but I doubt anyone will know what that means :-) Given that this function is inherently related to the "units in the last place" metric, I wonder if we can compose a name from that? Maybe extending the API slightly how about: T upl_distance(T, T); // "representation distance" T relative_distance(T, T); // AKA relative error. T ulp(T); // distance between arg and next(arg) Thoughts? Thanks, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 05 May 2008 11:48 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
So, it looks like so far we have:
next(val) prior(val)
and either of
representation_distance(a, b); discrete_distance(a, b);
Whilst I'm normally all in favour of "long_meaningful_names_with_underscores", next() and prior() do look OK to me: especially so long as they're in namespace boost::math.
Like Paul, I'm still looking for the right "killer name" for the *_distance function, I quite like "maddock_metric" but I doubt anyone will know what that means :-)
I can guess, but I may be peculiar ;-)
Given that this function is inherently related to the "units in the last place" metric, I wonder if we can compose a name from that?
Maybe extending the API slightly how about:
T upl_distance(T, T); // "representation distance" T relative_distance(T, T); // AKA relative error. T ulp(T); // distance between arg and next(arg)
If this is really limited to floating_point's ulp, I'm puzzlied as to what is your objection to T float_distance(T, T) ? Paul PS Shocking, but there are people who don't know what ulp means, but still understand enough about floating point to conceive a least significant bit change. float_distance will mean more to them? --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 06 May 2008 13:28 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
Paul A Bristow wrote:
If this is really limited to floating_point's ulp, I'm puzzlied as to what is your objection to
T float_distance(T, T)
?
None frankly, if folks are happy with
float_distance float_next float_prior
then I could go with that,
Sounds good to me. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Ooh, the return type is an integer that is always representable as a FPT (same as the arguments) and in addition, having FPT allows infinity and NaN if one (both) of the args are infinite or NaN. Nifty... I do hope all these get documented somehow besides the "number of gaps" basic return value. Thanks! Sent via BlackBerry from T-Mobile -----Original Message----- From: Paul A Bristow <pbristow@hetp.u-net.com> Date: Wed, 30 Apr 2008 12:52:47 To:boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hervé Brönnimann Sent: 30 April 2008 12:20 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
floatdistance(lhs, rhs)?
Would adding an underscore be nicer: FPT float_distance(FPT lhs, FPT rhs); And to be clear, this (and the other next functions) *only* apply to floating-point types. (not integer, not decimal, not interval, or any other type)? next_distance() is another possible that does not explicitly limit to floating point. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Paul A Bristow wrote:
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".
I'm the one that called it "technically accurate" yesterday, and I still think it is (although it may not be intuitive, and reasonable people can disagree, I guess :-) ). The only "primitive operations" allowed on floating point numbers are the arithmetic operations ... you aren't allowed "positional operations" or "string indexing" operations the way you are for integers or strings. So if the question is "How many fundamental, single bit additions does it take to get from a to b" ... that sounds to me like an "edit distance" (perhaps we should call it the Maddock Floating Point Edit Distance for clarity :-) I certainly like edit_distance better than most of the other names I've seen; "float_distance" in particular seems like a poor choice to me ... I think its semantics will be too easily confused with std::distance ... but then, what do I know :-) But I don't really care all that much -- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------
On Wed, 30 Apr 2008, John Maddock wrote:
dherring@ll.mit.edu 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).
I confused myself. Standard terminology says < and > are "less than" and "greater than"; so your names are fine. Still think the underscore should be dropped for consistency.
float x=1.0; float y=2.0; int d=edit_distance(x, y); float 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.
That was supposed to read // Does z==(x+y)/2? Which I think you've answered as yes. All of these operations apply to integers (albeit in the trivial sense that i and i+1 are always separated by a single gap). Thus it might be nice if these operators could be applied to all numeric types, integers and floating-point. Thanks, Daniel
John Maddock wrote:
T nextafter(T val, T dir)
Returns the next representable floating point value to "val" in the direction of "dir". This name is basically fixed, since it's the one that C99 uses.
T next_greater(T val)
Returns the next representable value greater than "val".
T next_less(T val)
Returns the next representable value less than "val".
T edit_distance(T a, T b)
Returns the number of floating point representations between values a and b.
Hi John, How did you implement these functions? Are they wrappers around functions provided by the compiler, or do you do some bit-twidling? --Johan
Johan Råde wrote:
How did you implement these functions? Are they wrappers around functions provided by the compiler, or do you do some bit-twidling?
The current implementation uses only basic arithmetic operations and frexp/ldexp: http://svn.boost.org/trac/boost/browser/sandbox/math_toolkit/boost/math/spec... but but there's scope to forward the implementations to native nextafter implementations where available. So far I've only done this for msvc doubles by way of an experiment / sanity check. There's no native or optimised version of edit_distance - I'm assuming this will used mostly in testing situations where out and out performance isn't so critical - which is just as well because the logic is rather complex :-( Feel free to work your bit twiddling magic on these :-) Regards, John.
John Maddock wrote:
Feel free to work your bit twiddling magic on these :-)
I will *not* do that. Actually, I'm *not* at all interested in floating point arithmetic. I wrote the floating point classification functions for one reason only: I needed them. The native fp classification functions on MSVC 7.1 do not handle single precision floating point numbers correctly, so I had to put together my own. --Johan
Johan Råde wrote:
John Maddock wrote:
Feel free to work your bit twiddling magic on these :-)
I will *not* do that. Actually, I'm *not* at all interested in floating point arithmetic. I wrote the floating point classification functions for one reason only: I needed them.
LOL, <chuckle>, well you can't blame a guy for trying :-) John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde Sent: 01 May 2008 06:25 To: boost@lists.boost.org Subject: Re: [boost] [Math/nextafter] A question of naming functions...
John Maddock wrote:
Feel free to work your bit twiddling magic on these :-)
I will *not* do that. Actually, I'm *not* at all interested in floating point arithmetic. I wrote the floating point classification functions for one reason only: I needed them.
The native fp classification functions on MSVC 7.1 do not handle single precision floating point numbers correctly, so I had to put together my own.
And we all thought that bit twiddling was your idea of Having a Really Good Time :-)) Which makes us all the more grateful to you for having done it :-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (12)
-
David Abrahams -
dherring＠ll.mit.edu -
Fernando Cacciola -
hervebronnimann＠mac.com -
Hervé Brönnimann
-
Johan Råde -
John Maddock -
Kevin Lynch -
Michael Fawcett -
Niels Dekker - mail address until 2008-12-31 -
Paul A Bristow -
Steven Watanabe