vincent at vinc17.net
Sat Aug 22 21:33:01 UTC 2015
On 2015-08-22 19:26:48 +0200, Niels Möller wrote:
> Vincent Lefevre <vincent at vinc17.net> writes:
> > On 2015-08-22 14:21:55 +0200, Niels Möller wrote:
> >> If it's really non-negative, I think I'd prefer the unsigned
> >> mp_bitcnt_t. I don't think consistency with mpf (deprecated) is
> >> important.
> > Is there any reason to prefer an unsigned type?
> Not sure, maybe on 32-bit systems the extra bit matters (if we want
> to support mpz_t values with up to 2^32-1 bits; I don't remember the
> documented limits).
Can't people who need such numbers move to a 64-bit system?
Moreover, even if the result would fit on 32-bits (but not on 31),
there is a high risk of overflow in the following computations on
> Or maybe it's a mistake that mp_bitcnt_t is unsigned in the first
I think so. This would have made arithmetic easier and safer. Moreover
mpq_mul_2exp could have been used with a signed exponent (easier than
having to use a conditional and mpq_mul_2exp / mpq_div_2exp).
> But I don't think it's a good idea to introduce mp_bitcnt_signed_t and
> use it for a somewhat arbitrary subset of the GMP functions working with
> bit counts.
Anyway for mpz_get_d_2exp, it's already signed in GMP 6.0.0. Moving
everything to signed would be better, and testable with GCC or Clang
> > They are really ugly when doing arithmetic on them,
> They have the slight advantage that behaviour on overflow is well
well-defined, but often incorrect and not easily testable.
> But you might be right that problems from unexpected conversions
> negate that advantage.
In particular in this case, where the result can be used in a exponent
computation; in the past, there were real bugs in MPFR when mixing
the (signed) exponent type and the (unsigned before MPFR 3) precision
type due to such conversions.
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
More information about the gmp-devel