BUG in gmp-4.2.1: mpf_get_str on large arg

[Vincent Lefevre]

On 2007-01-05 02:55:45 +0100, Torbjorn Granlund wrote:
> abbott <abbott at dima.unige.it> writes:
[...]
>     mpf_set_ui(overflow, 10);
>     mpf_pow_ui(overflow, overflow, 70000);
>     mpf_pow_ui(overflow, overflow, 70000);
>     mpf_out_str(stdout, 10, 20, overflow); /* gives SEGV */
[...]

> GMP does not handle overflows well, not here and not elsewhere.
> 
> You can also silently get exponent overflow during arithmetic.  I am
> not sure what the right approach would be for fixing this.  Overflow
> is irrelevant for most applications, and checking for it in GMP when
> doing exponent arithmetic would be costly.  And how should GMP handle
> it?  Abort?  I suppose a sticky inf would be cleanest, but would also
> be costliest.

Perhaps optional overflow handling via a configure option. But in this
case, the library name and function names should be different so that
the user can choose the function he wants (and can possibly use both).
Now, MPFR can be seen as a MPF replacement in particular for exception
handling.

> Does MPFR handle this better?  It wouldn't surprise me if it did.

It should, though I have not tried on this example. FYI, I fixed
several problems related to overflow/underflow detection in mpfr_pow
and mpfr_pow_z in the last few months. These fixes are available in
MPFR 2.2.1 only. If there are problems, e.g. undetected exceptions,
please send a bug report to the MPFR list.

> We then run into that we cannot represent the exponent in the output
> base ("exp_in_base") and have to make that into two words too...

MPFR cannot have such problems since the internal exponent is a base-2
exponent and after a conversion into another base (necessarily larger
or equal to 2), the exponent is smaller. As a consequence, its exponent
range is smaller that MPF's, but it is still quite large, and I don't
think anyone cares.

-- 
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)