Next: Removed Functions, Previous: Added Functions, Up: API Compatibility [Index]
The following functions and function-like macros have changed after MPFR 2.2. Changes can affect the behavior of code written for some MPFR version when built and run against another MPFR version (older or newer), as described below.
mpfr_printf, etc.) have
slightly changed in MPFR 4.1 in the case where the precision field
is empty: trailing zeros were not output with the conversion specifier
‘e’ / ‘E’ (the chosen precision was not fully specified and
it depended on the input value), and also on the value zero with the
conversion specifiers ‘f’ / ‘F’ / ‘g’ / ‘G’ (this
could partly be regarded as a bug); they are now kept in a way similar
to the formatted output functions from C. Moreover, the case where the
precision consists only of a period has been fixed in MPFR 4.2 to
be like ‘.0’ as specified in the ISO C standard (it previously
behaved as a missing precision).
mpfr_abs, mpfr_neg and mpfr_set changed in
MPFR 4.0.
In previous MPFR versions, the sign bit of a NaN was unspecified; however,
in practice, it was set as now specified except for mpfr_neg with
a reused argument: mpfr_neg(x,x,rnd).
mpfr_check_range changed in MPFR 2.3.2 and MPFR 2.4.
If the value is an inexact infinity, the overflow flag is now set
(in case it was lost), while it was previously left unchanged.
This is really what is expected in practice (and what the MPFR code
was expecting), so that the previous behavior was regarded as a bug.
Hence the change in MPFR 2.3.2.
mpfr_eint changed in MPFR 4.0.
This function now returns the value of the E1/eint1 function for
negative argument (before MPFR 4.0, it was returning NaN).
mpfr_get_f changed in MPFR 3.0.
This function was returning zero, except for NaN and Inf, which do not
exist in MPF. The erange flag is now set in these cases,
and mpfr_get_f now returns the usual ternary value.
mpfr_get_si, mpfr_get_sj, mpfr_get_ui
and mpfr_get_uj changed in MPFR 3.0.
In previous MPFR versions, the cases where the erange flag
is set were unspecified.
mpfr_get_str changed in MPFR 4.0.
This function now sets the NaN flag on NaN input (to follow the usual MPFR
rules on NaN and IEEE 754 recommendations on string conversions
from Subclause 5.12.1) and sets the inexact flag when the conversion
is inexact.
mpfr_get_z changed in MPFR 3.0.
The return type was void; it is now int, and the usual
ternary value is returned. Thus programs that need to work with both
MPFR 2.x and 3.x must not use the return value. Even in this case,
C code using mpfr_get_z as the second or third term of
a conditional operator may also be affected. For instance, the
following is correct with MPFR 3.0, but not with MPFR 2.x:
bool ? mpfr_get_z(...) : mpfr_add(...);
On the other hand, the following is correct with MPFR 2.x, but not with MPFR 3.0:
bool ? mpfr_get_z(...) : (void) mpfr_add(...);
Portable code should cast mpfr_get_z(...) to void to
use the type void for both terms of the conditional operator,
as in:
bool ? (void) mpfr_get_z(...) : (void) mpfr_add(...);
Alternatively, if ... else can be used instead of the
conditional operator.
Moreover the cases where the erange flag is set were unspecified in MPFR 2.x.
mpfr_get_z_exp changed in MPFR 3.0.
In previous MPFR versions, the cases where the erange flag
is set were unspecified.
Note: this function has been renamed to mpfr_get_z_2exp
in MPFR 3.0, but mpfr_get_z_exp is still available for
compatibility reasons.
mpfr_out_str changed in MPFR 4.1.
The argument base can now be negative (from −2 to
−36), in order to follow mpfr_get_str and GMP’s
mpf_out_str functions.
mpfr_set_exp changed in MPFR 4.0.
Before MPFR 4.0, the exponent was set whatever the contents of the MPFR
object in argument. In practice, this could be useful as a low-level
function when the MPFR number was being constructed by setting the fields
of its internal structure, but the API does not provide a way to do this
except by using internals. Thus, for the API, this behavior was useless
and could quickly lead to undefined behavior due to the fact that the
generated value could have an invalid format if the MPFR object contained
a special value (NaN, infinity or zero).
mpfr_strtofr changed in MPFR 2.3.1 and MPFR 2.4.
This was actually a bug fix since the code and the documentation did
not match. But both were changed in order to have a more consistent
and useful behavior. The main changes in the code are as follows.
The binary exponent is now accepted even without the ‘0b’ or
‘0x’ prefix. Data corresponding to NaN can now have an optional
sign (such data were previously invalid).
mpfr_strtofr changed in MPFR 3.0.
This function now accepts bases from 37 to 62 (no changes for the other
bases). Note: if an unsupported base is provided to this function,
the behavior is undefined; more precisely, in MPFR 2.3.1 and later,
providing an unsupported base yields an assertion failure (this
behavior may change in the future).
mpfr_subnormalize changed in MPFR 3.1.
This was actually regarded as a bug fix. The mpfr_subnormalize
implementation up to MPFR 3.0.0 did not change the flags. In particular,
it did not follow the generic rule concerning the inexact flag (and no
special behavior was specified). The case of the underflow flag was more
a lack of specification.
mpfr_sum changed in MPFR 4.0.
The mpfr_sum function has completely been rewritten for MPFR 4.0,
with an update of the specification: the sign of an exact zero result
is now specified, and the return value is now the usual ternary value.
The old mpfr_sum implementation could also take all the memory
and crash on inputs of very different magnitude.
mpfr_urandom and mpfr_urandomb changed in MPFR 3.1.
Their behavior no longer depends on the platform (assuming this is also true
for GMP’s random generator, which is not the case between GMP 4.1 and 4.2 if
gmp_randinit_default is used). As a consequence, the returned values
can be different between MPFR 3.1 and previous MPFR versions.
Note: as the reproducibility of these functions was not specified
before MPFR 3.1, the MPFR 3.1 behavior is not regarded as
backward incompatible with previous versions.
mpfr_urandom changed in MPFR 4.0.
The next random state no longer depends on the current exponent range and
the rounding mode. The exceptions due to the rounding of the random number
are now correctly generated, following the uniform distribution.
As a consequence, the returned values can be different between MPFR 4.0
and previous MPFR versions.
Next: Removed Functions, Previous: Added Functions, Up: API Compatibility [Index]