Re: math function accuracy -- was Re: text2interval again /
On 2013-03-09 08:40:02 -0800, Richard Fateman wrote:
> 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.*
Probably no conforming 754-2008 implementations. But for these
elementary functions, there exist some implementations, such as
CRlibm and Sun Microsystems's libmcr. GNU MPFR could be used too,
though it would not be very efficient compared to specific
libraries such as CRlibm.
Now, you don't need a 754-2008 conforming implementation for P1788
(in particular if you don't need the tightest accuracy mode).
> According to the draft of 1788 I am looking at, section 9.6 "Required
> operations"
You should regard it as obsolete concerning these 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.
Not necessarily 1 ulp, in particular not for sin on large arguments
(see the definition of widen, which has been chosen to ease
implementation).
> Except for exp and log?
There has been a private discussion about that on Feb 28, and
I suggested that this should be changed.
> 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.
No, the only reason is to ease the implementation, and even make it
practically possible in some cases. Without widening the argument,
with a large exponent such as what is possible with MPFR on 64-bit
machines, you could quickly exhaust the available memory without
getting an answer. Even in binary64, one may want fast sin/cos/tan
for large arguments.
> It would simplify a reference implementation to drop some of those
> functions from "required" to "recommended".
This is what I suggested on Feb 28.
> (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. )
Possibly useful for some languages, like XPath (without extensions),
where all operations are required to be correctly rounded to nearest.
But I'm not sure whether this is a good idea. The interval type could
be degraded to an implicit type is such a case.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)