"Dan Pop" <Da*****@cern.c h> wrote in message

news:c7******** **@sunnews.cern .ch...

In <Di************ ********@nwrddc 01.gnilink.net> "P.J. Plauger"
<pj*@dinkumware .com> writes:"Dan Pop" <Da*****@cern.c h> wrote in message

news:c7******* ***@sunnews.cer n.ch...

Even not so large arguments can still have plenty of fuziness and

getting a 53-bit accurate answer for the value actually represented is

still a waste of CPU resources.

So all the sine function needs is an indication of how much fuzz to

assume in the argument. I've yet to hear a specific criterion. Concrete

example please.

Assume all the bits of the argument are exact and the *only* source

of fuziness is the magnitude of the value. By the time the least

significant bit of the mantissa means more than 2 * pi, the fuziness

is complete (any result in the -1..1 range is correct).

Is that concrete enough for you?

Yes, it's concrete enough to show that you still don't get it.

If the argument were in quadrants, I'd agree that for sufficiently

large arguments the answer is always one of {0, 1, -1}, and for

still larger arguments the answer is always zero. You'd still

want to return the appropriate member of this simple set, just as you

want to return 1e38 from the round function when called with 1e38.

Here, round is operating nowhere near its most interesting range,

but there's still a well defined function value for each input value,

and it's not the place of the library to set the Uninteresting Argument

Exception in the FPP, or set errno to EUNINTERESTING_ ARGUMENT.

The argument to sine is not really in quadrants, but in radians.

That means that even when there are no fraction bits represented in

the argument x, there *still are* in x/(pi/2) (which is how you convert

radians to quadrants). So each argument value still corresponds to

some reduced argument that can be expressed to full machine precision

(almost always as some value other than {1, 0, -1} but still computable

with enough hard work). Which means that there's a corresponding

function return value that's also computable to full machine precision

that you really ought to return.

You may think that it's unlikely that all the bits of that value are

meaningful in a given application, and you're probably right. But

you're not *definitely* right. So as a library vendor, best engineering

practice is to supply all the bits that *might* make sense, in case

they actually do. A good quality implementation will continue to

compute the sine of small arguments quickly, but if it has to take

progressively longer to reduce ever larger arguments, then so be it.

You don't want the cost, reduce the arguments quickly, by your own

crude methods that are good enough for your application, before calling

sine.

Note also that even sin(1e-38) *might not* be good to full precision,

because the argument happens not to be good to full precision, but

you have no criterion for judging how many bits are worth computing.

Since it's so easy to compute them, and since they're often all

meaningful, nobody wastes much time debating the cost of producing

bits that are potentially garbage.

Now it so happens that it gets progressively *much* harder to follow

this best engineering practice as x gets larger in magnitude. The

temptation is strong to decree that the bits are meaningless beyond

some point and just return garbage. I've done this very thing in the

past, but I'm less inclined to do it now -- at least not without some

sanctioned way to report significance loss in lieu of computing a

difficult function value.

You also didn't get that you're still not giving a sufficiently concrete

criterion for when the sine function should stop trying. If you don't

like that a sine function wastes your program microseconds computing

what you shouldn't have told it to compute, then you need to be more

precise about where it can and should give up. You state above that

the function result is definitely meaningless once 1 ulp in the argument

weighs more than 2*pi, but why go that far? Aside from a phase factor,

you've lost all angle information at pi/2. But then how meaningful is it

to have just a couple of bits of fraction information? To repeat what

you stated above:

Even not so large arguments can still have plenty of fuziness and

getting a 53-bit accurate answer for the value actually represented is

still a waste of CPU resources.

So you've taken on a serious responsibility here. You have to tell us

library vendors just how small "not so large" is, so we know where to

produce quick garbage instead of slower correct answers. If you don't,

you have no right to deem our products unacceptable, or even simply

wasteful.

Of course, you also need to get some standards organization to agree

with you, so we all have the same *concrete* criteria to obey. But I'm

sure you can sweet talk one of them into doing as you say, once you

actually say it.

P.J. Plauger

Dinkumware, Ltd.

http://www.dinkumware.com