Closed dimpase closed 4 years ago
The problem isn't printing an error message when there is an exception; the problem is calling the function in a way that can trigger the exception in the first place. Either the Sage code should check the exponent range before trying to convert to an MPFR, or Arb should provide a version of this function which handles the overflow more smoothly than calling flint_abort().
It's hard to deal with an error message in a context of Sage (or any interactive use, in fact). That's why there should be a way to suppress it (if you really think it's not handled better by a usual mechanism of aborting with a documented numeric code, which can be processed).
@vbraun ?
IMHO a user of the library shouldn't have to figure out exactly what the limits are (which is moreover different on 32 and 64 bit afair), only to have the library then check it again.
As far as Sage is concerned, the current API of signaling the exception (which we then catch) is fine, were it not for text injected into stdio that then somewhat randomly pops out when buffers get flushed.
A different API that notifies the caller of the overflow via a return code, say, would be fine as well.
Yes, I think the API should be different.
Arguably, this conversion should just follow MPFR semantics: if the exponent is out of range, underflow to 0 or overflow to infinity, setting the relevant MPFR exception flags.
I have changed the behavior in f433b7597e140a6ebd556de59ff5ee086a18b0ab. It would be great if someone could test this in Sage to make sure it works as intended.
OK, will be testing this - also on flint 2.6.0.alpha (which, I suppose, mandates a new arb release, due to a patch needed?), see https://trac.sagemath.org/ticket/29719
Please see comments on https://trac.sagemath.org/ticket/28817
tl;dr: in
arf/get_mpfr.c
andfmpr/get_mpfr.c
there arecalls which cause too much noise in case of an exception.