Bitwise logic gmpxx.h problems

[Marc Glisse]

On Fri, 25 Jul 2008, Torbjorn Granlund wrote:

>  It seems mostly right, except that we now get (experimentally)
>  operator&=(double) which silently forwards to operator&=(unsigned long). I
>  don't really like that. I would prefer if it either generated an error
>  (which can be achieved by separating the float/double from the other
>  int/short/etc in the macros) or cast the double to a mpz_class (either
>  play with the macros to do this cast, or provide yet another overload for
>  the eval method).
>
> Does mpz_a &= double work differently from mpz_a = mpz_a & double?
> That'd be bad!

No they act the same, they both cast the double to an unsigned long (with 
the proposed patches).

> I suppose mpz_a $= double (for any operation $) should work like
>
>  mpz_b = double   [using mpz_set_d]
>  mpz_a $= mpz_b
>
> Is that not how it works now?  In that case, we need to fix this.

That is how it works now for addition (for instance) because 
__gmp_binary_plus has an overload of eval() for this case.

And I agree that this is the desired behaviour.

The proposed patches for & and &= add an overload of eval() for 
__gmp_binary_and for unsigned long and add operators & and &= for all 
numeric types (signed/unsigned char/shot/int/long and float/double) that 
end up calling the eval() overloaded for unsigned long.

Casting to unsigned long seems ok to me for integer types (don't know what 
the meaning is of & with a negative argument) but not for float/double, 
where something else should be done. The simplest is probably to overload 
eval() for double as well as unsigned long. And then also overload it for 
signed long, otherwise there will be ambiguities. This way the bit 
operations look the same as addition in gmpxx. That means 12 more 
functions compared to the already proposed changes.


-- 
Marc Glisse