mp_bitcnt_signed_t

[Marc Glisse]

On Sat, 22 Aug 2015, Niels Möller wrote:

> Marc Glisse <marc.glisse at inria.fr> writes:
>
>> For the mpz case, the answer should always be nonnegative, so we could
>> use an unsigned type if we wanted, but I guess it is better to keep
>> the current signed type, which is consistent with the mpf case.
>
> If it's really non-negative,

It approximates z as d*2^exp where abs(d)<1, so I believe that exp is 
always non-negative.

> I think I'd prefer the unsigned mp_bitcnt_t. I don't think consistency 
> with mpf (deprecated) is important.

Ok. Do we consider that changing the type from signed to unsigned in the 
next release is fine (some people might get a warning)? Or should I just 
leave it alone?

(I was looking at this function because of another project that uses it, I 
don't particularly want to change it)

>> What do you think of introducing 2 typedefs mp_builtin_[su]i (or
>> mp_native_[su]i or gmp_[su]i or whatever) and using them in all the
>> functions with _si or _ui in their name ?
>
> As I understand it, the main point of those interfaces is to support
> plain unsigned long (or signed long). Then I think a new typedef is more
> confusing than clarifying.

Ok.

On Sat, 22 Aug 2015, Niels Möller wrote:

[unsigned types]
>> They are really ugly when doing arithmetic on them,
>
> They have the slight advantage that behaviour on overflow is well
> defined. But you might be right that problems from unexpected
> conversions negate that advantage.

The well-defined behavior on overflow is actually a drawback here. It 
prevents from having a debug mode that traps on overflow and hinders 
optimizers. Wrapping doesn't make much sense for a bit count.

The current dominant opinion in the C++ community (don't know about C) is 
that with signed and unsigned defined as they are in C, unsigned types 
should be marginalized and only used for very specific cases like bignum 
(where wrapping makes sense) and bitfields (where you don't perform 
arithmetic anyway). It should not be used just because a value is 
non-negative. But it is too late, with many places in the standard using 
unsigned types...

-- 
Marc Glisse