Bitwise logic gmpxx.h problems
marc.glisse at normalesup.org
Fri Jul 25 18:33:30 CEST 2008
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.
More information about the gmp-bugs