Re: Radians Or Degrees?

Michael S wrote:

On Fri, 23 Feb 2024 11:01:02 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

 

Both you and Mitch look at it from wrong perspective.

For the record, I am only addressing SIN() or SINPI() as a HW instruction.

When we define a library API, an ease of implementation of the library
function should be pretty low on our priority scale. As long as
reasonably precise calculation is theoretically possible, we should
give credit to intelligence of implementor, that's all.

At the HW level, when someone executes a      SIN    R9,R17
instruction, they should get a result that has been computed to very
high precision, including argument reductions (which may require more
bits in the reduced argument than fit in an IEEE container).

The real concern of API designer should be with avoidance of loss of
precision in preparation of inputs and use of outputs.

With an instruction performing all the work, this argument is moot.

In specific case of y=sin2pi(x), it is x that is more problematic,
because near 0 it starts to lose precision 3 octaves before y. In
subnormal range we lose ~2.5 bits of precision in preparation of the
argument.

NOT when the argument reduction process does not contain ROUNDINGs !!!
OR when the argument reduction process contains more precision bits than
fit in an IEEE container !!! I determined for SIN() this needed 57-bits
of intermediate reduced argument, for TAN() and ATAN() this requires 58-bits:: compared to the 53 available in normalized IEEE 754.

            An implementation, no matter how good, can't recover what's
already lost.

My 66000 ISA has these as instructions (not function calls) and has the execution width to avoid your perils.

sinpi() is slightly better, but only slightly, not enough better to
justify less natural semantics.

SINPI() is also an instruction.
SIN() takes 19 cycles whereas SINPI() takes 16.....

My yesterday suggestion is a step in right direction, but today I think
that it is not sufficiently radical step. In specific case of sin/cos
there is no good reason to match loss of precision on input with loss of
precision.

In the end, you either have a precise result, or you do not.

<Thinking out load>
There are advantages in matched loss of precision for input and for
output when both input and output occupy full range of real numbers
(ignoring sign). Output of sin/cos does not occupy o full range. But
for tan() it does. So, may be, there is a one good reason for matching
input with output for sin/cos - consistency with tan.
</Thinking out load> So, ignoring tan(), what is really an optimal input scaling for sin/cos
inputs? Today I think that it is a scaling in which full circle
corresponds to 2**64. With such scaling you never lose any input
precision to subnoramals before precision of the result is lost
completely.

See USPTO 10,761,806 and 10,983,755 for your answer.