Contributing to GMP

Marco Bodrato bodrato at mail.dm.unipi.it
Wed Feb 26 14:09:33 UTC 2020


Ciao,

Il Mer, 26 Febbraio 2020 1:54 pm, Marc Glisse ha scritto:
> Also, bounding the size of the denominator may not always be the best
> suited to each application.
> It is good for absolute errors, but does not bound the size of the output,
> and can have bad relative error (sqrt(1/big,100) would be 0.

Well, you can estimate the difference of the bit-size of the numerator and
denominator of the result starting from the fraction fr with:
  (mpz_sizeinbase (mpq_numref (fr), 2) -
   mpz_sizeinbase (mpq_denref (fr), 2) ) /2;
i.e. the "order of magnitude" of the result.

Then, if you want a bound on the relative error, or the size of the
output, you can easily compute the desired "size of the denominator".

But of course, the interface may be different.

> The only reply I got for now from CGAL is that they don't seem
> particularly interested. The one function they would like for mpq_t is a
> function that takes a mpq_t and returns a tight interval of double

Yes, I remember a similar discussion two years ago.

https://gmplib.org/list-archives/gmp-discuss/2018-February/006188.html

I can say that in mini-gmp/tests/t-mpq_double.c there is a possible
function to detect if the conversion from mpq_t to double is tight, named
mpq_get_d_exact_p . But it is not in the interface, and will not be (it
does not work in general, it does not handle denorm...). If someone wants
to suggest something similar, it is welcome.

> So we have to look elsewhere for people interested in mpq_sqrt.

So, writing an efficient function is not required, now. That's good :-)

Ĝis,
m



More information about the gmp-discuss mailing list