Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug in Gfortran/GCC Math Library (?)

224 views
Skip to first unread message

mecej4

unread,
Mar 8, 2021, 6:39:41 AM3/8/21
to
I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
libraries that perform the calculations for the single-precision TANH
function. I request that a few readers run the test program below and
report the results in a reply. The problem does not arise if you use a
Windows port of Gfortran such as the one from Equation.com or MINGW. It
does occur with Cygwin/Gfortran on Windows-64-bit, and on the two Linux
systems that I have tried (WSL1, Ubuntu 4.8.5-2ubuntu1~14.04.1, GCC
4.8.5 and 6.2.0; GCC version 7.1.1 20170622 Red Hat 7.1.1-3).

The expected/correct values in the last column of the output are zero or
numbers of the order of 10^(-7) or less; certainly not 1.0!

-----------------CODE------------------
program mterr
use iso_fortran_env
implicit none
integer i,ix
real x,tnhx,f
!
write (*,*) compiler_version()
print *
print *,' x x(IEEE hex) tanh(x) 1/x - 1/tanh(x)'
print *,' ---------- -------- ----------- ---------------'
ix = Z'33DBE6F8'
do i=1,16
x = transfer(ix,x)
tnhx = tanh(x)
f = 1.0/x - 1.0/tnhx
print 10,i,x,ix,tnhx,f
ix = ix+1
end do
10 format(i2,ES15.5,2x,Z8,2ES15.5)
end program
------------------Output from Redhat Linux GCC 7.1.1-3---------------
$gfortran -std=gnu *.f95 -o main
$main
GCC version 7.1.1 20170622 (Red Hat 7.1.1-3)

x x(IEEE hex) tanh(x) 1/x - 1/tanh(x)
---------- -------- ----------- ---------------
1 1.02400E-07 33DBE6F8 1.02400E-07 1.00000E+00
2 1.02400E-07 33DBE6F9 1.02400E-07 1.00000E+00
3 1.02400E-07 33DBE6FA 1.02400E-07 0.00000E+00
4 1.02400E-07 33DBE6FB 1.02400E-07 1.00000E+00
5 1.02400E-07 33DBE6FC 1.02400E-07 1.00000E+00
6 1.02400E-07 33DBE6FD 1.02400E-07 0.00000E+00
7 1.02400E-07 33DBE6FE 1.02400E-07 1.00000E+00
8 1.02400E-07 33DBE6FF 1.02400E-07 1.00000E+00
9 1.02400E-07 33DBE700 1.02400E-07 0.00000E+00
10 1.02400E-07 33DBE701 1.02400E-07 1.00000E+00
11 1.02400E-07 33DBE702 1.02400E-07 1.00000E+00
12 1.02400E-07 33DBE703 1.02400E-07 1.00000E+00
13 1.02400E-07 33DBE704 1.02400E-07 0.00000E+00
14 1.02400E-07 33DBE705 1.02400E-07 1.00000E+00
15 1.02400E-07 33DBE706 1.02400E-07 1.00000E+00
16 1.02400E-07 33DBE707 1.02400E-07 0.00000E+00

Thanks in advance for your help.

-- MECEJ4
--
mecej...@nospam.invalid
(Replace four by 4, nospam by gmail, invalid by com,
and remove all underscores)

mecej4

unread,
Mar 8, 2021, 6:47:14 AM3/8/21
to
On 3/8/2021 5:39 AM, mecej4 wrote:
> I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
> libraries that perform the calculations for the single-precision TANH
> function.
> The expected/correct values in the last column of the output are zero or
> numbers of the order of 10^(-7) or less; certainly not 1.0!
>
> -----------------CUT------------------

P.S. I am aware that an error in the last decimal digit in the evaluated
value of tanh(x) can explain the 1.0 that I am complaining about.

JRR

unread,
Mar 8, 2021, 7:43:28 AM3/8/21
to
Am 08.03.21 um 12:39 schrieb mecej4:
> I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
> libraries that perform the calculations for the single-precision TANH
> function. I request that a few readers run the test program below and
> report the results in a reply. The problem does not arise if you use a
> Windows port of Gfortran such as the one from Equation.com or MINGW. It
> does occur with Cygwin/Gfortran on Windows-64-bit, and on the two Linux
> systems that I have tried (WSL1, Ubuntu 4.8.5-2ubuntu1~14.04.1, GCC
> 4.8.5 and 6.2.0; GCC version 7.1.1 20170622 Red Hat 7.1.1-3).
>

[....]

> ------------------Output from Redhat Linux GCC 7.1.1-3---------------
> $gfortran -std=gnu *.f95 -o main
> $main
>  GCC version 7.1.1 20170622 (Red Hat 7.1.1-3)
>
>             x      x(IEEE hex)    tanh(x)    1/x - 1/tanh(x)
>       ----------   --------    -----------   ---------------
>  1    1.02400E-07  33DBE6F8    1.02400E-07    1.00000E+00
>  2    1.02400E-07  33DBE6F9    1.02400E-07    1.00000E+00
>  3    1.02400E-07  33DBE6FA    1.02400E-07    0.00000E+00
>  4    1.02400E-07  33DBE6FB    1.02400E-07    1.00000E+00
>  5    1.02400E-07  33DBE6FC    1.02400E-07    1.00000E+00
>  6    1.02400E-07  33DBE6FD    1.02400E-07    0.00000E+00
>  7    1.02400E-07  33DBE6FE    1.02400E-07    1.00000E+00
>  8    1.02400E-07  33DBE6FF    1.02400E-07    1.00000E+00
>  9    1.02400E-07  33DBE700    1.02400E-07    0.00000E+00
> 10    1.02400E-07  33DBE701    1.02400E-07    1.00000E+00
> 11    1.02400E-07  33DBE702    1.02400E-07    1.00000E+00
> 12    1.02400E-07  33DBE703    1.02400E-07    1.00000E+00
> 13    1.02400E-07  33DBE704    1.02400E-07    0.00000E+00
> 14    1.02400E-07  33DBE705    1.02400E-07    1.00000E+00
> 15    1.02400E-07  33DBE706    1.02400E-07    1.00000E+00
> 16    1.02400E-07  33DBE707    1.02400E-07    0.00000E+00
>
> Thanks in advance for your help.
>
>    -- MECEJ4

Here is the output with gfortran 11.0 on macOS BigSur 11.2
(I had to set the flag -fallow-invalid-boz as the code wouldn't
compile otherwise):

x x(IEEE hex) tanh(x) 1/x - 1/tanh(x)
---------- -------- ----------- ---------------
1 1.02400E-07 33DBE6F8 1.02400E-07 0.00000E+00
2 1.02400E-07 33DBE6F9 1.02400E-07 0.00000E+00
3 1.02400E-07 33DBE6FA 1.02400E-07 0.00000E+00
4 1.02400E-07 33DBE6FB 1.02400E-07 0.00000E+00
5 1.02400E-07 33DBE6FC 1.02400E-07 0.00000E+00
6 1.02400E-07 33DBE6FD 1.02400E-07 0.00000E+00
7 1.02400E-07 33DBE6FE 1.02400E-07 0.00000E+00
8 1.02400E-07 33DBE6FF 1.02400E-07 0.00000E+00
9 1.02400E-07 33DBE700 1.02400E-07 0.00000E+00
10 1.02400E-07 33DBE701 1.02400E-07 0.00000E+00
11 1.02400E-07 33DBE702 1.02400E-07 0.00000E+00
12 1.02400E-07 33DBE703 1.02400E-07 0.00000E+00
13 1.02400E-07 33DBE704 1.02400E-07 0.00000E+00
14 1.02400E-07 33DBE705 1.02400E-07 0.00000E+00
15 1.02400E-07 33DBE706 1.02400E-07 0.00000E+00
16 1.02400E-07 33DBE707 1.02400E-07 0.00000E+00

With gfortran 9.3.0 on Ubuntu 20.04 I do see the 1.0s in the last
column as you describe. So it seems that if this a problem it has
been fixed.



--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany

Ev. Drikos

unread,
Mar 8, 2021, 10:15:36 AM3/8/21
to
On 08/03/2021 13:39, mecej4 wrote:
> I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
> libraries...

Likely, you've found a bug (I think it qualifies for a PR).

> ... I request that a few readers run the test program below and
> report the results in a reply...

$ gfc mterr.f90 && uname -sr && ./a.out
Darwin 18.7.0
GCC version 4.8.5

x x(IEEE hex) tanh(x) 1/x - 1/tanh(x)
---------- -------- ----------- ---------------
1 1.02400E-07 33DBE6F8 1.02400E-07 0.00000E+00
2 1.02400E-07 33DBE6F9 1.02400E-07 0.00000E+00
3 1.02400E-07 33DBE6FA 1.02400E-07 0.00000E+00
4 1.02400E-07 33DBE6FB 1.02400E-07 0.00000E+00
5 1.02400E-07 33DBE6FC 1.02400E-07 0.00000E+00
6 1.02400E-07 33DBE6FD 1.02400E-07 0.00000E+00
7 1.02400E-07 33DBE6FE 1.02400E-07 0.00000E+00
8 1.02400E-07 33DBE6FF 1.02400E-07 0.00000E+00
9 1.02400E-07 33DBE700 1.02400E-07 0.00000E+00
10 1.02400E-07 33DBE701 1.02400E-07 0.00000E+00
11 1.02400E-07 33DBE702 1.02400E-07 0.00000E+00
12 1.02400E-07 33DBE703 1.02400E-07 0.00000E+00
13 1.02400E-07 33DBE704 1.02400E-07 0.00000E+00
14 1.02400E-07 33DBE705 1.02400E-07 0.00000E+00
15 1.02400E-07 33DBE706 1.02400E-07 0.00000E+00
16 1.02400E-07 33DBE707 1.02400E-07 0.00000E+00
$
$ cat mterr.f90
! { dg-do run }
program mterr
use iso_fortran_env
implicit none
integer i,ix
real x,tnhx,f
!
write (*,*) compiler_version()
print *
print *,' x x(IEEE hex) tanh(x) 1/x - 1/tanh(x)'
print *,' ---------- -------- ----------- ---------------'
ix = int(Z'33DBE6F8')
do i=1,16
x = transfer(ix,x)
tnhx = tanh(x)
f = 1.0/x - 1.0/tnhx
print 10,i,x,ix,tnhx,f
ix = ix+1
if ( f /= 0 ) error stop "last column should be 0"

Pierre Asselin

unread,
Mar 8, 2021, 11:47:05 AM3/8/21
to
mecej4 <mecej...@nospam.invalid> wrote:
> [ ... ] I request that a few readers run the test program below and
> report the results in a reply.

I get the same results as you.


$ gfortran --version
GNU Fortran (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

$ gfortran mterr.f90 && ./a.out
GCC version 7.5.0

x x(IEEE hex) tanh(x) 1/x - 1/tanh(x)
---------- -------- ----------- ---------------
1 1.02400E-07 33DBE6F8 1.02400E-07 1.00000E+00
2 1.02400E-07 33DBE6F9 1.02400E-07 1.00000E+00
3 1.02400E-07 33DBE6FA 1.02400E-07 0.00000E+00
4 1.02400E-07 33DBE6FB 1.02400E-07 1.00000E+00
5 1.02400E-07 33DBE6FC 1.02400E-07 1.00000E+00
6 1.02400E-07 33DBE6FD 1.02400E-07 0.00000E+00
7 1.02400E-07 33DBE6FE 1.02400E-07 1.00000E+00
8 1.02400E-07 33DBE6FF 1.02400E-07 1.00000E+00
9 1.02400E-07 33DBE700 1.02400E-07 0.00000E+00
10 1.02400E-07 33DBE701 1.02400E-07 1.00000E+00
11 1.02400E-07 33DBE702 1.02400E-07 1.00000E+00
12 1.02400E-07 33DBE703 1.02400E-07 1.00000E+00
13 1.02400E-07 33DBE704 1.02400E-07 0.00000E+00
14 1.02400E-07 33DBE705 1.02400E-07 1.00000E+00
15 1.02400E-07 33DBE706 1.02400E-07 1.00000E+00
16 1.02400E-07 33DBE707 1.02400E-07 0.00000E+00

--
pa at panix dot com

Ron Shepard

unread,
Mar 8, 2021, 4:41:30 PM3/8/21
to
On 3/8/21 10:47 AM, Pierre Asselin wrote:
> mecej4 <mecej...@nospam.invalid> wrote:
>> [ ... ] I request that a few readers run the test program below and
>> report the results in a reply.

I think the original poster already mentioned this, but here is a
simpler program that demonstrates the error.

program mterr
use iso_fortran_env
implicit none
integer :: ix
real :: x, xp, f
!
ix = int(Z'33DBE6F8')
x = transfer(ix,x)
xp = transfer(ix+1,x)
f = 1.0/x - 1.0/xp
print 10, x, ix, xp, f
10 format(ES15.5,2x,Z8,2ES15.5)
end program


$ ./a.out
1.02400E-07 33DBE6F8 1.02400E-07 1.00000E+00

So the problem is that the tanh() function in the original code is off
by the least signfiicant bit error. That error is hidden by the ES15.5
output format, where both values round to the same display digits. The
taylor expansion for tanh(x) is

tanh(x) = x - x**3/3 + 2*x**5/15 +...

so in this domain, around 1e-7, x==tanh(x) should be satisfied for REAL
precision, but it's not. The tanh() function probably switches from a
taylor expansion for small x to a rational function for larger x, and it
is probably switching at the wrong place and introducing that one bit of
error somewhere in the extra arithmetic that is being done. There is no
reason why tanh() cannot be computed correctly in this domain.

The expression for f in the code amplifies this error, but f is
evaluated with only one significant bit in the mantissa. That is, the
leading bits of 1/x and 1/xp all cancel. This is easier to see from the
mathematically equivalent expression

(xp - x) / (x*xp)

All the bits but one cancel in the numerator, and then that one bit is
rescaled by the denominator to the result that is printed.

tanh() is used often as a switching function in fitting procedures.
Having an error like this in a library function would result in
unphysical discontinuities in the fitted surfaces.

$.02 -Ron Shepard

gah4

unread,
Mar 8, 2021, 6:55:42 PM3/8/21
to
On Monday, March 8, 2021 at 3:39:41 AM UTC-8, mecej4 wrote:
> I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
> libraries that perform the calculations for the single-precision TANH
> function. I request that a few readers run the test program below and
> report the results in a reply. The problem does not arise if you use a
> Windows port of Gfortran such as the one from Equation.com or MINGW. It
> does occur with Cygwin/Gfortran on Windows-64-bit, and on the two Linux
> systems that I have tried (WSL1, Ubuntu 4.8.5-2ubuntu1~14.04.1, GCC
> 4.8.5 and 6.2.0; GCC version 7.1.1 20170622 Red Hat 7.1.1-3).
>
> The expected/correct values in the last column of the output are zero or
> numbers of the order of 10^(-7) or less; certainly not 1.0!

(snip calculating 1/x - 1/tanh(x))

I suppose you could consider this a bug, but I believe it is a very unfair test.

Anytime one subtracts two values that are very close, one should expect
precision loss, and not be surprised at the results. That is what happens here.

The first term in the Taylor series for tanh is 1/x, which you are trying to subtract.

The easy answer to this question is to do the calculation in double precision,
though in the end that only moves the problem down some orders of magnitude.
(Or just decide for yourself when the value is small enough and use 0.)

The harder answer is to write a routine that calculates the appropriate series
without any extra terms to subtract off.

Reminds me of a problem that I heard many years ago:

Wrap a string all the way around the Earth, and add 6m.
(I might have forgotten the distance to add.)

Arrange the string equally above the surface.
About how far is it above?

Now pull the string up at one point. Is it more than 44m
above the ground? (When I first heard it, it was the height
of Millikan library, which seems to be about 44m.)

As well as I remember from discussions in this group, the standard
doesn't say much at all about the results of library functions, but it
is usually considered reasonable to be within 1 in the least significant
bit in the result. For some functions, maybe 1.5 or so.





mecej4

unread,
Mar 8, 2021, 10:53:26 PM3/8/21
to
On 3/8/2021 5:39 AM, mecej4 wrote:
> I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
> libraries that perform the calculations for the single-precision TANH
> function. I request that a few readers run the test program below and
> report the results in a reply. The problem does not arise if you use a
> Windows port of Gfortran such as the one from Equation.com or MINGW. It
> does occur with Cygwin/Gfortran on Windows-64-bit, and on the two Linux
> systems that I have tried (WSL1, Ubuntu 4.8.5-2ubuntu1~14.04.1, GCC
> 4.8.5 and 6.2.0; GCC version 7.1.1 20170622 Red Hat 7.1.1-3).
>
> The expected/correct values in the last column of the output are zero or
> numbers of the order of 10^(-7) or less; certainly not 1.0!
>
> -----------------CUT CODE and RESULTS------------------

Thanks to all for the kind replies.

In the application code where this problem arose (groundwater flow
simulation), the lines

aa = vel/disp
wetab(k, numsel) = 1.0/tanh(aa) - 1/aa

can be replaced by

aa = vel/disp
if (abs(aa) < 2.e-4) then
wetab(k, numsel) = (1 - aa*aa/15)*aa/3
else
wetab(k, numsel) = 1.0/tanh(aa) - 1/aa
endif

David Duffy

unread,
Mar 8, 2021, 11:55:29 PM3/8/21
to
mecej4 <mecej...@nospam.invalid> wrote:
> I suspect that I have stumbled on a bug in the BSD/Linux/GNU system
> libraries that perform the calculations for the single-precision TANH
> function.
> program mterr

Nokia 2.2 phone, aarch64 Android
GCC version 10.2.0
all 0.00000E+00

mecej4

unread,
Mar 9, 2021, 6:37:49 AM3/9/21
to
Thank you, David.

-- mecej4

Ron Shepard

unread,
Mar 9, 2021, 12:40:38 PM3/9/21
to
You might think that you have worked around the tanh() library bug with
this code, but you have actually done more than that. The expression
you are using

(1 - aa*aa/15)*aa/3

actually consists of the leading terms for the taylor expansion of the
exact function that you are evaluating, f(x)=coth(x)-1/x. There is no
cancellation of error at all for small arguments in that taylor
expansion, where of course there is in the tanh() expression. Therefore,
when you switch at x=2.e-4 from the expansion to the original tanh()
expression, you are actually introducing errors, not eliminating them.

It is correct that the truncated taylor expansion has errors, and for
sufficiently large arguments, those errors will begin to dominate. So
one might ask, when should the switchover occur? You can figure it out
by hand, but perhaps an even better demonstration of this is the
following program:

program cotherr
use iso_fortran_env
implicit none
real(real32) :: x, f, g
real(real128) :: xp, fp
x = epsilon(x)
do while (x<=128.0)
f = 1/tanh(x) - 1/x
g = (1-x*x/15)*x/3
xp = x
fp = 1/tanh(xp) - 1/xp
write(*,'(5es12.4)') x, f, g, (f-fp), (g-fp)
x = x + x
end do
end program

I'm "cheating" here by using 128-bit floating point as a reference. Of
course, there are cancellation errors there too, but they are small
enough compared to the 32-bit arithmetic so that they can be ignored.
The output from this program on my computer is:

1.1921E-07 0.0000E+00 3.9736E-08 -3.9736E-08 1.1842E-15
2.3842E-07 0.0000E+00 7.9473E-08 -7.9473E-08 2.3685E-15
4.7684E-07 0.0000E+00 1.5895E-07 -1.5895E-07 4.7370E-15
9.5367E-07 0.0000E+00 3.1789E-07 -3.1789E-07 9.4739E-15
1.9073E-06 0.0000E+00 6.3578E-07 -6.3578E-07 1.8948E-14
3.8147E-06 0.0000E+00 1.2716E-06 -1.2716E-06 3.7897E-14
7.6294E-06 0.0000E+00 2.5431E-06 -2.5431E-06 7.5801E-14
1.5259E-05 0.0000E+00 5.0863E-06 -5.0863E-06 1.5166E-13
3.0518E-05 0.0000E+00 1.0173E-05 -1.0173E-05 3.0380E-13
6.1035E-05 0.0000E+00 2.0345E-05 -2.0345E-05 6.1138E-13
1.2207E-04 0.0000E+00 4.0690E-05 -4.0690E-05 1.2531E-12
2.4414E-04 0.0000E+00 8.1380E-05 -8.1380E-05 2.7487E-12
4.8828E-04 2.4414E-04 1.6276E-04 8.1380E-05 7.4376E-12
9.7656E-04 3.6621E-04 3.2552E-04 4.0690E-05 1.2935E-12
1.9531E-03 6.7139E-04 6.5104E-04 2.0345E-05 1.0348E-11
3.9062E-03 1.3123E-03 1.3021E-03 1.0174E-05 -3.3633E-11
7.8125E-03 2.6093E-03 2.6042E-03 5.0969E-06 -3.6280E-11
1.5625E-02 5.2109E-03 5.2082E-03 2.6279E-06 1.7395E-10
3.1250E-02 1.0414E-02 1.0416E-02 -1.8650E-06 4.1294E-10
6.2500E-02 2.0828E-02 2.0828E-02 3.3707E-07 -1.9348E-09
1.2500E-01 4.1623E-02 4.1623E-02 -2.1284E-07 -6.3824E-08
2.5000E-01 8.2988E-02 8.2986E-02 9.7103E-08 -2.0561E-06
5.0000E-01 1.6395E-01 1.6389E-01 -1.0945E-07 -6.4527E-05
1.0000E+00 3.1304E-01 3.1111E-01 -3.5789E-08 -1.9242E-03
2.0000E+00 5.3731E-01 4.8889E-01 5.1878E-08 -4.8426E-02
4.0000E+00 7.5067E-01 -8.8889E-02 -2.1015E-09 -8.3956E-01
8.0000E+00 8.7500E-01 -8.7111E+00 1.3348E-08 -9.5861E+00
1.6000E+01 9.3750E-01 -8.5689E+01 -2.5328E-14 -8.6626E+01
3.2000E+01 9.6875E-01 -7.1751E+02 -3.2076E-28 -7.1848E+02
6.4000E+01 9.8438E-01 -5.8041E+03 0.0000E+00 -5.8051E+03
1.2800E+02 9.9219E-01 -4.6561E+04 0.0000E+00 -4.6562E+04

You switched expressions at x=2.4e-4, which is when the complete
cancellation stops in the tanh() expression, but as you can see in the
last column, the truncated taylor expansion is still more accurate even
there. You have to get up to x=0.25 before the tanh() expression becomes
more accurate than the truncated taylor expansion. Also note that at
x=4, the truncated expression has the wrong sign, so there is ample
evidence of truncation errors at that point even without knowing the
exact function values for comparison.

The next term in the taylor expansion is x**5*2/945 if you want to
experiment with including that. Assuming the compiler is eliminating the
divisions for you at compile time, that just costs one more multiply-add
sequence to include it.

For a long time there was a numerical analysis newsgroup where these
things were discussed. There was always a large overlap between posters
in that group and here in c.l.f., and even many crossposts to both
groups. Fortran programmers have always been concerned with numerical
analysis. However, over time that newsgroup degenerated into SPAM for
prescription drugs and textbook solution manuals, while thankfully
c.l.f. has mostly survived. So 20 or 30 years ago, I would have posted
this in that group in order to bring in other perspectives on this topic
and to avoid the slightly off-topic subject matter.

$.02 -Ron Shepard

Phillip Helbig (undress to reply)

unread,
Mar 9, 2021, 2:25:39 PM3/9/21
to
In article <mqO1I.24379$mn1....@fx20.iad>, Ron Shepard
<nos...@nowhere.org> writes:

> For a long time there was a numerical analysis newsgroup where these
> things were discussed. There was always a large overlap between posters
> in that group and here in c.l.f., and even many crossposts to both
> groups. Fortran programmers have always been concerned with numerical
> analysis. However, over time that newsgroup degenerated into SPAM for
> prescription drugs and textbook solution manuals,

Any idea why that happened?

There are also (usually the same, in each case) spam messages which
regularly appear in certain groups.

Some people have no life.

Robin Vowels

unread,
Mar 9, 2021, 7:00:31 PM3/9/21
to
On Wednesday, March 10, 2021 at 4:40:38 AM UTC+11, Ron Shepard wrote:

> For a long time there was a numerical analysis newsgroup where these
> things were discussed. There was always a large overlap between posters
> in that group and here in c.l.f., and even many crossposts to both
> groups. Fortran programmers have always been concerned with numerical
> analysis. However, over time that newsgroup degenerated into SPAM for
> prescription drugs and textbook solution manuals,
>
Google pretends that it deals with spam, but it does nothing.
The "solution manuals" have nothing to do with the topic.
>
Google won't cross-post.
Means that if you have something of interest there, you need to post again to that n.g.
.

JCampbell

unread,
Mar 9, 2021, 9:00:29 PM3/9/21
to
On Wednesday, March 10, 2021 at 4:40:38 AM UTC+11, Ron Shepard wrote:
The problem being reported is for real32 |x| < 1.e-4, tanh(x) = x, but for some Gfortran libraries this is not the case, providing x - roundoff.
It would be expected that 1/x - 1/x = 0, although any calculation 1/x is problematic as x approaches epsilon (x), but getting "1.0/tanh(x) - 1/x" = 1.0 is an unnecessary result.

The use of Taylor's series to rewrite "1.0/tanh(x) - 1/x" as coth(x) - 1/x = (1 - x*x/15)*x/3 works well for small x.

mecej4

unread,
Mar 9, 2021, 10:08:52 PM3/9/21
to
Ron, thanks for your comments. It appears that a better switchover value
of x may be about 0.15, but it is not yet clear to me whether the
absolute error, which you tabulated, is a better choice in the
application than the relative error. Strangely enough, 0.15 seems to be
a good switchover point based on either absolute or relative error.

-- mecej4

Phillip Helbig (undress to reply)

unread,
Mar 10, 2021, 2:10:18 AM3/10/21
to
In article <58d9f113-83a6-45df...@googlegroups.com>, Robin Vowels <robin....@gmail.com> writes:

> Google pretends that it deals with spam, but it does nothing.
> The "solution manuals" have nothing to do with the topic.
> >
> Google won't cross-post.
> Means that if you have something of interest there, you need to post again to that n.g.

Apart from trying to create the impression that Google Groups is
something more than an interface to usenet, Google seems to be happy to
contribute to problems and do nothing about them. As the moderator of a
moderated newsgroup, for a while we got a lot of spam, which was
apparentlty actually sent by a human and sent via Google Groups. I was
never even able to discuss this with a human being at Google, much less
get them to do anything about it.

Ev. Drikos

unread,
Mar 10, 2021, 11:45:40 AM3/10/21
to
Recently, I marked a message as abuse, because I can't see any obvious
connection to c.l.f. but is still accessible via google groups:
https://groups.google.com/g/comp.lang.fortran/c/CkyAERZUeks/m/1diu8bVGAgAJ

On the other hand filtering messages with not so clear criteria would
be in my opinion worse. Once I had posted a message to c.l.f that was
not appearing in Thunderbird. Without trying to figure out why, I just
abandoned the particular server.

Whereas, news.aioe.org makes a better filtering but I find google groups
ok as well.

At the moment, I don't think c.l.f. really suffers from spam. Do you?


Ev. Drikos
0 new messages