"The set of mpq functions is quite small." Is this by design?

[Marc Glisse]

On Sun, 19 Aug 2018, Marco Bodrato wrote:

>>>> Perhaps mpq_mul_ui would make sense.  It would require a gcd of the ui
>>>> argument with the denominator.
>
>>> expect that most of the savings you might be able to get would be
>>> handled better in the mpq library with special casing for unity
>>> denominators (which is likely a not that uncommon case that might be
>>> worth handling).
>
>> These things always depend on the kind of operands you are dealing with. I
>> often deal with small numbers where simply building (allocating) a
>> rational from an int is already a very costly operation. For people who
>> only deal with huge numbers that are often integers, your solution would
>> work fine.
>
> Should we also add mpq_{add,sub,mul,div}_z functions?
> We already have mpq_cmp_z.

mpq_add_z is pretty trivial to do using mpz operations (that doesn't mean 
we can't provide it). mpq_mul_z sounds more useful, it is getting a bit 
more complicated for users to implement efficiently themselves, although 
delegating to mpq_canonicalize avoids having to mess with divexact.

I am not sure how much reuse of operands we want to allow in a mix mpq/mpz 
operation. Can the input mpz alias the numerator or denominator of the 
output mpq?

(by the way, mpz_divexact_gcd often come in pairs with the same divisor, I 
wonder how much redundant work that is, probably completely negligible)

-- 
Marc Glisse