"The set of mpq functions is quite small." Is this by design?
Richard at Damon-Family.org
Sat Aug 11 13:29:11 UTC 2018
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
More information about the gmp-discuss