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

[Richard Damon]

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)
>   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).

-- 
Richard Damon