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: Rich Felker <dalias at libc dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Szabolcs Nagy <nsz at port70 dot net>, libc-alpha at sourceware dot org
- Date: Wed, 18 Feb 2015 21:17:22 -0500
- 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>
On Wed, Feb 18, 2015 at 06:45:38PM +0000, Joseph Myers wrote:
> On Wed, 18 Feb 2015, Szabolcs Nagy wrote:
>
> > * Joseph Myers <joseph@codesourcery.com> [2015-02-18 17:25:38 +0000]:
> > > On Wed, 18 Feb 2015, Szabolcs Nagy wrote:
> > >
> > > > this is an interesting issue because iso c annex f forbids the
> > > > omission of underflow right now, which is hard to achive unless
> > > > libm checks <= DBL_MIN instead of the sensible < DBL_MIN and
> > > > raises spurious underflow for a lot of exact (or non-tiny) DBL_MIN
> > > > results (which is allowed by the standard)
> > >
> > > I don't believe it forbids computing an imprecise result that happens to
> > > be (exactly) DBL_MIN or more, and so doesn't underflow.
> > >
> >
> > 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
know that the result is non-exact; only a small number of functions in
a small number of cases even admit exact results.
Rich