Re: math function accuracy -- was Re: text2interval again /
On 2013-03-11 16:14:09 +0000, N.M. Maclaren wrote:
> On Mar 11 2013, Vincent Lefevre 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.
>
> That's not my point. If 1788 demands tightest, there are two
> immediate consequences:
>
> 1) Languages and implementations where performance is critical
> will not provide those functions
>
> 2) Some languages and implementations will note that it isn't
> deliverable for all of their numeric intrinsics and won't bother
> for at least the others or possibly any of them
I'm not saying that P1788 should demand tightest. On the contrary.
What I'm saying is that even if P1788 just demands containment,
a program will benefit from implementations providing a good
accuracy. This is not true for floating-point: a C program has
no way to compute an error bound on some result, because C doesn't
have any requirement concerning the accuracy of math functions;
even if the result is accurate, the program cannot know this in
a portable way.
Also note that a P1788 implementation can provide several versions
of a function, e.g. one tightest, one accurate and one valid. So
depending on his speed/accuracy compromise, a user could choose
the best version for his application.
--
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)