tg at gmplib.org
Fri Aug 21 06:56:32 UTC 2015
"Marco Bodrato" <bodrato at mail.dm.unipi.it> writes:
Maybe we can "promise" the right type, by adding an explicit cast?
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
Or deny that we added it?
A tenth of lines of code should be enough, shouldn't it?
mpf_cmp_z (mpf_srcptr u, mpz_srcptr v) __GMP_NOTHROW
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.
Please encrypt, key id 0xC8601622
More information about the gmp-devel