Contributing to GMP

[Marc Glisse]

On Mon, 24 Feb 2020, Marco Bodrato wrote:

> Ciao,
>
> Il Lun, 24 Febbraio 2020 9:30 am, Marc Glisse ha scritto:
>> On Mon, 24 Feb 2020, Marco Bodrato wrote:
>>> I agree, a log_ui function does not belong to the current mpq_t
>>> interface.
>>>
>>> But maybe it would be interesting to write some mpq_ functions giving
>>> inexact results... If it is possible to return a fraction that is a good
>
>>> E.g. the attached code computes the square root of a fraction. It
>
>>> Might inexact functions on rationals, like this one, be useful to
>>> someone?
>
>> In CGAL, we use
>>
>> template <typename NT>
>> NT approximate_sqrt(const NT& nt, CGAL::Field_tag)
>> {
>>    return NT(sqrt(CGAL::to_double(nt)));
>> }
>
>> That is, for types without sqrt, we convert to double, compute sqrt, and
>> convert back.
>
>> I think speed may be important there, or precision just
>> doesn't matter that much.
>
> Of course, if you don't care to obtain sqrt(9/49) = 3/7 or anything
> different...

If you are going to approximate sqrt(2) with a rational, you probably 
don't care that much about getting exactly 3/7 either.

>>> Anyway, extending the rational interface in a coherent way, to add also
>>> inexact functions, seems difficult.
>>
>> At least I would give it a name that more clearly reflects its approximate
>> nature, like mpq_approximate_sqrt.
>
> Well, also mpz_sqrt is not exact :-)

I see it more like division: you can see integer division as inexact, or 
as a different operation (division with remainder).

We have mpf_sqrt_ui (though not mpf_sqrt_z) vs mpz_sqrt (and mpz_sqrtrem) 
for the 2 definitions of square root.

> But of course, with mpq, we can decide how to approximate.

By the way, maybe the function could return a bool (exact or not) or 
{-1,0,+1} to say in which direction it approximated.

I'll forward the question about the use of mpq_sqrt.

-- 
Marc Glisse