Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,
- From: John Denker <jsd av8n com>
- To: Gnumeric Forum <gnumeric-list gnome org>
- Subject: Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,
- Date: Sat, 28 May 2022 22:27:22 -0700
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?
1) See my previous message from 5/28/22 12:43 AM.
2) Here is more detail about how I think about it.
Consider the following rational numbers:
7074237752028437 / 4503599627370496
7074237752028438 / 4503599627370496
7074237752028439 / 4503599627370496
7074237752028440 / 4503599627370496
7074237752028441 / 4503599627370496
7074237752028442 / 4503599627370496
7074237752028443 / 4503599627370496
The denominator is the same for all, and is a power of 2.
In fact, all those rationals are representable as IEEE
doubles. Representable exactly. Furthermore, they are
consecutive, adjacent IEEE doubles.
The FPU on my laptop does very good job of calculating the
cotangent of these rational numbers. The results are shown
here:
https://av8n.com/computer/img48/trig-function-accuracy.png
Forsooth, the accuracy is very much better than can be
depicted on such a graph. I'm not sure that all 64 bits of
the result are always correct, but I'm not sure they're not.
(I have not researched this. The conventional explanation is
that the FPU does the calculation with a "few" guard digits
and then rounds the result. So in rare marginal cases the
last bit could get rounded the wrong way, compared to what
you would get with "more" guard digits. This happens on top
of the much larger inevitable rounding error. So it is both
rare and immaterial. It cannot possibly be important in
practical applications.)
Mathematically, cot(π/2) is zero. The FPU cannot compute this
for the exceedingly simple reason that the abscissa (π) cannot
be represented as an IEEE double. It is somewhere close to
7074237752028438.275766 / 4503599627370496
which is definitely not representable.
This is shown by the + symbol in the middle of the diagram.
Not being able to compute cot(π/2) has got nothing to do with
the accuracy of the FPU computation. To repeat, it does a very
good job on all the abscissas you can actually feed it. There
is no point in even asking what the FPU does with abscissas
that it cannot possibly be given.
For numbers this close to π/2, you can compute the cotangent
to high accuracy using two terms of the Taylor series. Or in
lots of other ways. The main thing you need is a verrry
accurate representation of π/2.
If you are interested in the tangent, you can compute the
cotangent and then take the reciprocal.
I have a maxima script that maps this out in lurid detail.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]