Re: math function accuracy -- was Re: text2interval again /
On 2013-03-11 15:31:24 +0000, N.M. Maclaren wrote:
> >>(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.
>
> The principal point in such a specification would be to encourage
> languages to do that more generally. I am utterly sick of languages
> and libraries that say that, as soon as you use certain critical
> facilities, all behaviour is undefined.
>
> Inaccuracy is a minor form of undefined behaviour, but the point
> stands.
This is true for floating-point, when the error bound is not given
(or when the error bound is too large to be useful in practice).
Even if the result happens to be accurate, there is no guarantee,
and one doesn't know whether one can trust the result.
This isn't really true for interval arithmetic, as containment gives
useful information. And if one gets a tight interval, one knows one
can trust it.
However a good specification should forbid implementations from
providing poor results (though correct) for bad reasons.
BTW, for the arithmetic operations, even though "tightest" could
be required, "accurate" could still be useful for some types, like
long long on PowerPC (corresponding to double-double, for which
"tightest" may be useless on some inputs, because the distance
between two consecutive representable values can be very tiny).
--
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)