"The set of mpq functions is quite small." Is this by design?
Marc Glisse
marc.glisse at inria.fr
Sun Aug 19 17:12:46 UTC 2018
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
More information about the gmp-discuss
mailing list