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

[Marc Glisse]

On Sat, 11 Aug 2018, Richard Damon wrote:

> On 8/11/18 7:50 AM, Torbjörn Granlund wrote:
>> Anders Andersson <pipatron at gmail.com> writes:
>>
>>   Hi! I tend to use the rational functions in GMP a lot, and quoting
>>   from the documentation: The set of mpq functions is quite small.
>>
>>   I was wondering if this is by design or if the developers would
>>   welcome an extension of the API to cover some more common cases that
>>   I've found while using it?
>>
>> Use cases which suggest some shortcoming of GMP are interesting!
>>
>>   I'm mostly missing arithmetic with native integers (think mpq_mul_ui)

gmpxx internally uses different code for some of those. For instance, q+=3 
turns into a call to mpz_addmul_ui. Others fake the conversion to mpq to 
avoid an allocation.

>>   and raw I/O functions. These are all trivial to implement but having
>>   them in the API could perhaps enable some optimizations when it is
>>   known that one operand is always small.
>>
>> "Raw" I/O function would need to define a file format.  I consider the
>> file format of the current mpz_*_raw function to be poor, so before even
>> considering raw I/O extension of mpq or mpf, a better file format should
>> be considered.
>>
>> In the meantime, using mpz_*_raw in the numerator and denominator
>> separetely might be what you want to do.  Or else mpz_export/import
>> followed by some system I/O operation.
>>
>> Perhaps mpq_mul_ui would make sense.  It would require a gcd of the ui
>> argument with the denominator.
>>
> Would a mpq_mul_ui function really be that much more efficient than
> converting the ui number to a rational (with unity denominator). I would
> 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.

-- 
Marc Glisse