Walter Neumann on Thu, 12 May 2005 17:07:32 +0200

 Re: erfc() behavior change

```There does seem to be a related incosistency however:

? erfc(-2^11)
%1 = 2.000000000000000000000000000
? 2-%1
%2 = 0.E-1821573
? precision(%2)
%3 = 1821573

...

? 0.0
%10 = 0.E-28
? precision(%)
%11 = 28
? 0.0e-90
%12 = 0.E-91
? precision(%)
%13 = 96
? 1.e-90
%14 = 1.000000000000000000000000000 E-90
? precision(%)
%15 = 28

Shouldn't precision in %3 and %13 be something like 28?

--walter neumann

.

On Thu, 12 May 2005, Karim Belabas wrote:

```
```* Walter Neumann [2005-05-12 07:31]:
```
```On Wed, 11 May 2005, Igor Schein wrote:
```
```\\ ver 2.2.9
? for(k=1,10,print(k" "precision(erfc(2^k))" "precision(erfc(-2^k))))
...
10 455407 455446
\\ ver 2.2.10
? for(k=1,10,print(k" "precision(erfc(2^k))" "precision(erfc(-2^k))))
...
10 38 455446
```
```
The second (2.2.10) looks better to me:

GP/PARI CALCULATOR Version 2.2.11 (development CHANGES-1.1205)

? erfc(2^10)
%1 = 9.342620665669385261706140592 E-455395
? precision(%)
%2 = 28
? erfc(-2^10)
%3 = 2.000000000000000000000000000
? precision(%)
%4 = 455427
? 2-%3
%5 = 9.342620665669385261706140592 E-455395
? precision(%)
%6 = 38
```
```
Indeed. As for the ridiculous accuracy of %3 above, we have conflicting
"specifications":
1) PARI functions give as precise a result as is possible from the input,
2) floating point computations are meant to foster speed by truncating
operands.

Only 1) is specified in the documentation, 2) is only a general understanding.
And a rather misleading one as far as PARI is concerned; it is a common
source of misapprehension to assume that

* 'realprecision' is  "the relative accuracy used to truncate operands in 2)".
Which it is not: it is used to convert exact objects to inexact ones.

* operands with n digits of accuracy will yield a result with at most the
same accuracy. Which is wrong: indeed 1 + 1e-50000 may be computed to
more than 50000 digits of accuracy.

In most cases, the second behaviour is a bug from the user's point of view
(what's the point of getting 455000 trailing zeroes ?). I believe it is
better to stick to strict specifications and let the user sort out
numerical problems from this point.

The 2.2.9 problem was quite different: the _apparent_ accuracy of erfc(huge)
was huge, but almost all printed decimals were wrong due to catastrophic
cancellation. I fixed it so that only meaningful digits are output
[ and so that complex arguments are accepted, but that's irrelevant to our
present topic ].

Cheers,

Karim.
--
Karim Belabas                     Tel: (+33) (0)1 69 15 57 48
Dep. de Mathematiques, Bat. 425   Fax: (+33) (0)1 69 15 60 19
Universite Paris-Sud              http://www.math.u-psud.fr/~belabas/
F-91405 Orsay (France)            http://pari.math.u-bordeaux.fr/  [PARI/GP]

```
```
```