Re: C99 and GMP

On Fri, 27 Apr 2018, paul zimmermann wrote: https://gmplib.org/devel/lcov/shell/gmp/mini-gmp/mini-mpq.c.gcov.html quite interesting. Why is gmp/mpn not tested in the head coverage? It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of symlinks created at build time. --

Re: dead code in div_q.c?

paul zimmermann writes: >> It would be good to either prove that qh > 0 can't happen, or add a test >> that will exercise the code handling that case. > > yes more generally it would be nice to know for the divappr functions, if the > exact quotient fits on qn limbs

Re: C99 and GMP

> > quite interesting. Why is gmp/mpn not tested in the head coverage? > > It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of > symlinks created at build time. sorry I missed that. I see some of the files are not tested at all (add_err3_n.c for example), and some have a

Re: documentation on internals not up to date

from gmp-bugs. Il Ven, 27 Aprile 2018 7:21 am, Niels Möller ha scritto: > "Marco Bodrato" writes: >> Currently there's always at least one readable limb, so for instance >> @code{mpz_get_ui} can fetch @code{_mp_d[0]} unconditionally (though its >> value is then only

Re: C99 and GMP

On Fri, 27 Apr 2018, Marc Glisse wrote: On Fri, 27 Apr 2018, paul zimmermann wrote: quite interesting. Why is gmp/mpn not tested in the head coverage? It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of symlinks created at build time. sorry I missed that. I see some

Re: dead code in div_q.c?

Niels, I fully agree with your analysis. Small comments below. > From: ni...@lysator.liu.se (Niels Möller) > Date: Thu, 26 Apr 2018 22:12:09 +0200 > > paul zimmermann writes: > > > In the second case (lines 267-276) this is less obvious since you use an > >

Re: documentation on internals not up to date

On Fri, 27 Apr 2018, Niels Möller wrote: _mp_alloc == 0 and _mp_size != 0 is a read-only value, _mp_d is neither written, reallocated or freed by mpz functions. It must not be passed as destination argument to any mpz function. Should also link to docs for mpz_roinit_n and MPZ_ROINIT_N.

Re: C99 and GMP

On Fri, 27 Apr 2018, paul zimmermann wrote: quite interesting. Why is gmp/mpn not tested in the head coverage? It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of symlinks created at build time. sorry I missed that. I see some of the files are not tested at all

Re: documentation on internals not up to date

On Fri, 27 Apr 2018, Niels Möller wrote: Marc Glisse writes: There would be a significant advantage to mpq if we could have a non-allocated 1 for the denominator. But indeed, with the current code where only some mpz functions would work, it seems safer to document that

Re: documentation on internals not up to date

Marc Glisse writes: > There would be a significant advantage to mpq if we could have a > non-allocated 1 for the denominator. But indeed, with the current code > where only some mpz functions would work, it seems safer to document > that none work. We could do that

Re: documentation on internals not up to date

Ciao, Il Ven, 27 Aprile 2018 2:46 pm, Marc Glisse ha scritto: > On Fri, 27 Apr 2018, Niels Möller wrote: >> Marc Glisse writes: >>> There would be a significant advantage to mpq if we could have a >>> non-allocated 1 for the denominator. But indeed, with the current code >>

divappr interface

Hi, after the discussion on div_q, I had another look at divappr, or more precisely, the mpn_sbpi1_divappr_q function. It's not entirely obvious from the implementation which limbs of the {np, nn} argument are actually used. But I think it should access only the qn+2 upper limbs. For accuracy,

Re: dead code in div_q.c?

ni...@lysator.liu.se (Niels Möller) writes: > --- a/tests/mpn/t-div.c Wed Apr 25 07:38:14 2018 +0200 > +++ b/tests/mpn/t-div.c Wed Apr 25 22:19:17 2018 +0200 > @@ -445,6 +445,7 @@ main (int argc, char **argv) > alloc = itch + 1; > } > scratch[itch] = ran;

Re: documentation on internals not up to date

"Marco Bodrato" writes: > ... and it's not just a problem of supporting mpq_denref() we should also > change some mpq_ functions. If someone does init an mpq_t with: > mpz_init (mpq_numref (accumulator)); > mpz_roinit_n (mpq_denref (accumulator), _one, 1); > > then

Re: documentation on internals not up to date

Ciao, Il Ven, 27 Aprile 2018 10:50 am, Niels Möller ha scritto: > I'd prefer that we not document any way to pass _roinit values to any > mpz functions taking a non-const mpz_t, even if it happens to work in > the current implementation. Maybe as a later extension, *if* we find > some use cases

Re: divappr interface

ni...@lysator.liu.se (Niels Möller) writes: > Once we reach qn = dn - 1, keep looping to produce quotient limbs, but > also discard one limb of dp in each interation, until we in the final > iteration have qn = 1, qn+2 = 3 numerator limbs, and qn+1 = 2 divisor > limbs, i.e., a single udiv_qr_3by2