This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] Add nextup and nextdown math functions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Rical Jasan <ricaljasan at pacific dot net>
- Cc: Rajalakshmi Srinivasaraghavan <raji at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Date: Tue, 7 Jun 2016 17:24:52 +0000
- Subject: Re: [PATCH v3] Add nextup and nextdown math functions
- Authentication-results: sourceware.org; auth=none
- References: <201606011211 dot u51C9sVN019582 at mx0a-001b2d01 dot pphosted dot com> <574FE5C6 dot 6040303 at pacific dot net> <alpine dot DEB dot 2 dot 20 dot 1606022330330 dot 9542 at digraph dot polyomino dot org dot uk> <201606061715 dot u56HEkNN001197 at mx0a-001b2d01 dot pphosted dot com> <57567324 dot 6030301 at pacific dot net>
On Tue, 7 Jun 2016, Rical Jasan wrote:
> > +the function returns the positive number of least magnitude in the type of
> > +@var{x}. If @var{x} is @code{NaN}, @code{NaN} is returned. @code{nextup}
>
> To adhere to the majority style of the Arithmetic chapter, those NaNs
> would not be enclosed in @code{} (57:2). In fact, their appearance in
> @code{} in nextafter is the only place in the chapter that happens (and
> only one other time in Mathematics). Personally, I thought it was
> strange they were all unformatted, and they probably should be
> @code{NaN}, but I wanted to mention it for the sake of consistent style.
I don't think any should use @code, because it's not a literal sequence of
characters in source code, but a value, that's being referred to.
> I've attached the beginnings of how I would approach it, but there are
> some questions embedded as comments in there, which I also mention
> below. The general strategy is to attempt to address the functions'
> behaviour when given any of the classifications of floating-point
> numbers, as outlined in fpclassify, 20.4 Floating-Point Number
> Classification Functions (NaN, infinity, 0, subnormal, normal).
> Hopefully my understanding of the target values is correct, and I am
> referencing the Floating Point Parameters in Appendix A correctly.
I think in general that's a bad approach, and very repetitive. A function
has semantics from which you can deduce what it does for all those values.
Some of those semantics may come from general rules; for example, that a
function with a signaling NaN input raises the "invalid" exception, other
than for a few non-arithmetic functions such as fabs and copysign; a
function raising the "invalid" exception and returning a floating-point
result returns a quiet NaN; and a function with a quiet NaN argument
returns a quiet NaN without raising any exceptions if it does not have any
signaling NaN arguments (except for a few special cases such as hypot
(Inf, NaN), and the possibility of fma (0, Inf, NaN) raising "invalid").
Pretty much no functions should do anything special for subnormals, or for
0, and the result for infinity are generally the limits of the
mathematical function for finite arguments.
> It seems like the really interesting case is what nextup and nextdown do
> when they should increment away from their respective infinities. I can
> reason returning both infinity or the next largest value, and I can't
> find anything in your documentation about those cases, so I definitely
> think those need clarification.
They do what the nextUp and nextDown operations in IEEE 754-2008 do.
That's the exact point of these functions. The most relevant case to
mention for infinities would seem to be nextup(+Inf) and nextdown(-Inf),
as the cases where there aren't any more representable values in the
relevant direction. (And the other special cases to mention are for zero
- that a zero result has the sign of the argument and a zero argument of
either sign results in a nonzero result.)
> Are subnormals treated differently than normals? It sounds like
> subnormals have their own special representation, and I'm not sure if
> the step sizes between them are different than for normals. If they
If you aren't familiar with subnormals and other aspects of the set of
values of an IEEE floating-point type, you aren't likely to have a use for
these functions.
The functions that are the odd cases out are nextafter / nexttoward, that
raise "inexact" and "underflow" for subnormal results despite those
results not depending on the rounding mode.
> Lastly, is there anything to say about floating-point exceptions? From
Only that these functions raise no exceptions except for sNaNs.
--
Joseph S. Myers
joseph@codesourcery.com