math function accuracy -- was Re: text2interval again /
On 3/9/2013 6:49 AM, Vincent Lefevre wrote:
On 2013-03-09 07:48:08 -0600, Ralph Baker Kearfott wrote:
Does that mean then that within the C-environment, one
isn't assured the environment is 754-2008 conforming, and
hence will not be 1788 conforming unless <math.h> is
upgraded or the functionality of <math.h> is supplied
separately for 1788 conformance? (We'd been discussing
within a small group about accuracy requirements for
specific functions, some of which we've -- within the
group -- agreed should be correctly rounded.)
First, the C standard mentions the 1985 version. Moreover, even with
the 2008 version, the math functions are recommended, not required.
So, even though C provides math functions, they are not necessarily
correctly rounded. The error bound may not even be known, making all
IA implementation impossible from the std library version.
My apologies for my earlier message which was based on (my recollection of)
754-1985. I incorrectly assumed that sin, cos, etc. did not have to
respond to
the rounding mode. In 754-2008 indeed functions like sin(x) could be
thought of as having an extra attribute, the rounding mode. e.g.
sin(x,RM), and must be correctly rounded with respect to that attribute.
There is, I suppose, a third attribute which is the width of the
desired result, but this is transmitted as the width of x.
I thank Michel Hack for setting me straight, and now agree with Vincent
and Baker.
The issue for building a reference implementation is (sort of) simplified.
My current understanding is that:
All those functions (sin, cos, and many friends) are merely recommended
in 754-2008.
Not required.
If they are included, they must be correctly rounded.
I say sort of simplified because one could then take 754-2008
routines and use them. However, conforming implementations
do not seem to be available.*
So a reference implementation of intervals with tightest bounds
that would depend on such conforming 754-2008 implementations must first
write those 754-2008 scalar conforming implementations.
According to the draft of 1788 I am looking at, section 9.6 "Required
operations"
lists sin and many friends in Table 1 page 19, so 1788 goes beyond
754-2008.
This makes a reference implementation hard if they are required to be
tight. But they aren't; just specified to be accurate, so
intervals for sin and friends could be computed by believing the
advertised accuracy of (say) 1ULP and rounding,
after the computation, up and down.
Except for exp and log? That could be a problem if IEEE 754-2008 routines
for them are not available. I am guessing you want this so x^y
can be computed, but it would be simpler to say they too are merely
accurate.
Incidentally, I do not see the merit in widening the argument in the
spec for "accurate" (page 41).
It seems to be saying that for sin(x) evaluated on an interval that
looks like
[very large argument, very large argument] we don't believe in FTIA.
It would simplify a reference implementation to drop some of those
functions from "required" to "recommended".
(And it would even
more simplify an implementation to replace "required tightest"
with "required accurate, recommended tightest" for
ALL "tightest", since some systems without access to rounding modes
will have to work hard to get tightest, but can be accurate
extremely efficiently. )
....................
*Note. I tried some functions to see if, by happenstance, setting the
rounding
mode and obliviously running them, would cause them to provide the correct
rounding. I only tried rounding to pos-inf and neg-inf, the ones that
matter
for interval arithmetic. For approximations that are
simple polynomials, what plausibly matters is the rounding effect on the
final addition.
From some simple tests I found
that for the implementation of sin, cos, log that I happened to have,
they appeared to "work" for round up and down. For some other functions the
result was not good, in particular exp. Rounding up and down happened
to enclose the true result, but the bounds were far from tight.
The exp approximation used is a carefully devised rational computation,
not a polynomial.
Oh, also. Since I could easily do it, I tried taking the library sin()
algorithm
and ran it on an interval that was 1ULP wide. Unsurprisingly you get an
unacceptably crude interval.
RJF