mp_bitcnt_signed_t

[Vincent Lefevre]

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
32-bit variables.

> Or maybe it's a mistake that mp_bitcnt_t is unsigned in the first
> place?

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
with -fsanitize=undefined.

> > They are really ugly when doing arithmetic on them,
> 
> They have the slight advantage that behaviour on overflow is well
> defined.

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)