# Re: SIND, COSD, TAND functions

glen herrmannsfeldt wrote:
robert.corbett@xxxxxxx wrote:
(snip)

There was a long discussion of this topic on this news group
a while ago. Try evaluating COSD(90.0) and see if you are
happy with the result.

Any chance for SIND, COSD, TAND, and ASIND, ACOSD, and ATAND,
in Fortran 2008?

They should be pretty easy to add.

It's easy to add to the standard. Would it be that easy
to implement? Most hardware these days has in-built
instructions for the trig functions. These are based on
radians. So, getting degree based trig functions to work
well might be problematical. SIND(30.0) should be
exactly one-half (0.5). Can you even be sure that there's
a float value whose SIN (radian based) is exactly one-half?
For some floating-point represenations there migh not be.
Similarly for TAND(45.0): it should be exactly one,
but is there an angle in radians that is both representable
to one?

To be sure, such issues as COSD(90.0) can be resolved
by careful argument reduction *before* converting to
radians: COSD(X) == SIND(X-90.0), so COSD(90.0)
is the same as SIND(0.0), which in turn is the same as
SIN(0.0) (radians-based). But the more such work you
do, the less efficient the degree-based function relative to

Dependong on how trig functions are actually implemented
in you hardware there may be other options. And, it's not
harder for hardware implementors to design degree-based
instructions, it's just that few have. Can the Fortran language
standard assume that such things will be done? Or, are you
willing to naively convert to radians and get inexact results?
The "implementation dependend approximation" language
of the standard allows all kind of crimes against precision.
Is that what you want?

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

.