mpq_cmp_z

[Torbjörn Granlund]

"Marco Bodrato" <bodrato at 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