Re: Circular functions are not as intractable as you may think...
On Aug 20 2011, Dan Zuras Intervals wrote:
The main problem can be the performance on some functions, e.g. for
sin/cos/tan on large arguments. One solution would be to return [-1,1]
Domain reduction for circular functions hasn't been a
performance problem for 3 decades now. With O(emax)
memory for tables, the operation can be performed in
O(1) time.
That IS a performance problem, because modern machines rely on cache
efficiency for performance, and that is a good way to destroy it.
I did some work along those lines 25+ years back, when cache was not
as critical and, even then, it was counter-productive.
However, I agree that circular functions are not where the problem
really arises, not least because extreme arguments are rare.
> so such a specification has to be for the best achievable bounds with
> the technology at the time the specification is developed. Then
> someone develops a better algorithm, and the standard forbids an
> implementor to adopt it ....
No, the standard won't forbid it. It will just forbid to return an
*incorrect* result (w.r.t. reproducibility).
Eh? I was talking about the NON-trivial functions - but which I do
not include the exponential/trigonometric family. All relevant
languages have at least erf, most have more and libraries provide
others. And, what is FAR more important, the vast majority of
scientific programs use some of them.
At any date, the best realistic approach may be to deliver bounds
(A,B) for a particular function call. Yes, in theory, any specifiable
function can be calculated to arbitrary accuracy, but the cost of
doing so is often super-exponential. So they deliver that. Someone
then develops a better approach, but that can't be used in reproducible
mode. So even NEW compilations in that mode deliver poor accuracy.
Of course, if you want to say that the reproducibility requirement
will not apply AT ALL to any program that uses anything beyond a
small set of essentially trivial functions, go ahead. But I can
tell you what the reaction of the languages, vendors and scientific
programmers will be.
Regards,
Nick Maclaren.