Re: erfc() behavior change

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Thu, May 12, 2005 at 10:47:13AM +0200, Karim Belabas wrote:
> 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.

The IEEE754 specification and the MPFR extension say the the correct
result is the representable number the closest to the actual result,
assuming the operands are exact. However they implicitly assume the
output precision to be fixed, and say nothing about how to derive it
from the input, which is the PARI problem. We use a 'philosophical' rule
instead of a 'pragmatic' one (like, say "the output precision will be
the minimal precision of the input" or "the output precision is defined
by the ouput_precision global variable"). 

What worry me more is that we should make sure transcendental functions
compute the output precision correctly in term of the input and not
rely on the additions in the algorithm to do so...

> 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.

Someone should check whether exp() given the same precision in 2.2.9 and
2.2.10. I am afraid the use of Newton iterations for large precisions
might break that...

Cheers,
Bill.