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

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

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

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]