Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: math function accuracy -- was Re: text2interval again /

Here's an alternative to the current spec for sin (etc).

The current problem is for sin(x) where x is  a float_with_huge-exponent.
This may cause problems because any value for sin(x) first
requires a value for pi good to a huge number of places..
 so as to reduce x modulo pi/2 or pi/4 to < 1 ULP.


Instead of setting the spec so that sin(x) is [merely] accurate,
not tight (because it might take too much memory or time on large args for the reason above) 
why not specify it this way:

define as tight: sin_modest(x) .
This would be the function to use
    for  -pi/2<x<pi/2
or even say -1.0d8 < x <1.0d8; ( it doesn't really matter much... some modest limit...) 


Otherwise if you want to have a tight sin([a,b]),
 it is YOUR responsibility to either
1. find some n such that A:= a mod n*pi and B:=b mod n*pi are -pi <=A<=B<=pi ; that is, reduce the interval 
   Or
2. determine that no such n exists, in which case the result is [-1,1].
Another sine_not_limited() function, one which allows ANY input, could be the "merely" accurate one. For small size inputs it would of course call sin_modest() and would be tight.
The same idea could be used for the other functions to provide tight enclosures. probably 
on the ranges of most usage.

RJF



On 3/11/2013 9:14 AM, 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


However a good specification should forbid implementations from
providing poor results (though correct) for bad reasons.


That does not compute.  Sorry, but distinguishing good from bad
reasons is not something that is practically specifiable.


Regards,
Nick Maclaren.