"Marco Bodrato" <bodr...@mail.dm.unipi.it> writes:
Maybe we can "promise" the right type, by adding an explicit cast?
SIZ((mpz_srcptr) NUM(op2))
Except that we should cast op2, not NUM(ops).
I am not sure Marc's reasoning is accurate, nor am I suggesting it is
not, I've forgotten this level of detail of the C standard. I am not
too enthusiastic about passing the wrong type, but if we add casts both
when going to &mpq and when going back to &mpz, I cannot see how that
could break with a conforming compiler.
> > (We might consider adding mpf_cmp_z too, at least in a simple-minded
> > manner, to keep the GMP interface as orthogonal as possible.)
> Adding new mpf_t functions might confuse the message that people should
> use mpfr...
We can silently add it to the manual without claiming it in the release
announce :-)
Or deny that we added it?
A tenth of lines of code should be enough, shouldn't it?
int
mpf_cmp_z (mpf_srcptr u, mpz_srcptr v) __GMP_NOTHROW
{
mpf_t vf;
mp_size_t size;
SIZ (vf) = size = SIZ (v);
EXP (vf) = size = ABS (size);
/* PREC (vf) = size; */
PTR (vf) = PTR (v);
return mpf_cmp (u, vf);
}
It looks about right. The code for mpf_set_z should provides a pattern,
except that its conditionally truncattion is not needed.
--
Torbjörn
Please encrypt, key id 0xC8601622
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
