Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,

[John Denker <jsd av8n com>]

On 5/27/22 9:26 PM, newbie nullzwei via gnumeric-list wrote:

> In my double version tan(pi()/2) fails with 16331239353195370 instead of the
> reference 16324552277619072, tan(3/2*pi()) and the negative values fail too,
> exotic processor? messed up system? updated libraries??? how reliable are the
> references?

The issue has very little to do with tan() and everything
to do with the representation of pi()/2.

In any serious application it would be better to use tanpi(0.5)
which produces #NUM! which is IMHO the right answer. Note that
cospi(0.5) is exactly zero, as it should be.

OTOH if for some reason we can't do that, the value of pi()/2
is 1.5707963267948966192313217 (to high accuracy). However an
IEEE double cannot represent that; the closest it can come is
1.5707963267948965579989817

If you take the tangent of that (to high accuracy) you get
16331239353195369.755 for which the closest IEEE double is
16331239353195370. So I don't consider that a failure.

I don't know where the claim of 16324552277619072 is coming
from.

I would also suggest that tan() is not the best way to frame
the question. It would be better to look at cos(float(π/2))
or equivalently cot(float(π/2)), which are not quite zero.
You can then use the nexttoward(,) function to step through
the representable argument values. That produces a nice linear
output, whereas tan() produces an output that is grossly
nonlinear (indeed wildly non-monotonic).

I suggest there's no point in worrying about tan() until you
have figured out what you want to do with cot() and cos().

Note: The 'maxima' language has bigfloats which I find to
be convenient for examining such issues.