This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Refine documentation of libm exceptions goals [committed]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Szabolcs Nagy <nsz at port70 dot net>, <libc-alpha at sourceware dot org>
- Date: Thu, 19 Feb 2015 10:29:46 +0000
- Subject: Re: Refine documentation of libm exceptions goals [committed]
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1502172341550 dot 26150 at digraph dot polyomino dot org dot uk> <20150218164730 dot GQ32724 at port70 dot net> <alpine dot DEB dot 2 dot 10 dot 1502181723520 dot 12618 at digraph dot polyomino dot org dot uk> <20150218181046 dot GR32724 at port70 dot net> <alpine dot DEB dot 2 dot 10 dot 1502181843060 dot 12618 at digraph dot polyomino dot org dot uk> <20150219021722 dot GO23507 at brightrain dot aerifal dot cx>
On Wed, 18 Feb 2015, Rich Felker wrote:
> > > well, there are no precision requirements on not exactly-defined math
> > > functions, but with that interpretation an implementation which never
> > > raises underflow is also correct: it can claim that it exactly computed
> > > an incorrect result so there is no precision loss and thus no underflow
> >
> > Yes. This falls under the general implementation-defined accuracy of libm
> > functions.
>
> I think this is a stretch to say that implementation-defined accuracy
> allows an implementation to falsely report a result as exact when it's
> not. For all functions in the math library it's relatively trivial to
I see that as being potentially a < 1ulp error. There is *never* any
requirement (except for fma, sqrt, etc.) for "inexact" exceptions to be
correct (in either direction), so this is just about whether there is a
stricter requirement in the underflow case. And C99 and C11 Annex F bind
to IEEE 754-1985, which permits denormalization loss as an alternative to
inexactness for when underflow is raised (and many of the cases where it's
missed in practice correspond to cases of scaling down a normal result,
where the scaling is exact - i.e., no denormalization loss). (Whether
libm functions not directly bound to IEEE operations are covered by the
constraint that all operations raise underflow under the same conditions,
so that they can't use "denormalization loss" where basic arithmetic
operations use "inexact result", is doubtful.)
--
Joseph S. Myers
joseph@codesourcery.com