Re: sqrt algorithm

Ciao, ni...@lysator.liu.se (Niels Möller) writes: For the divisions in the sqrt algorithms, I'm not sure of exactly how the sizes of the numerator E, the denominator H, and the quotient, relate, but they ought to all be pretty close to k. Below is an updated version of the code, which

Re: Anomaly in mpn_sqrtrem and mpn_rootrem

Ciao, Il Mer, 8 Luglio 2015 4:20 pm, Torbjörn Granlund ha scritto: bodr...@mail.dm.unipi.it writes: The code above should give a range for the first 5 bits (the first is 1 anyway), and it should work for any k. But I spotted % k and / k there, and those are very expensive, unless you

Re: Anomaly in mpn_sqrtrem and mpn_rootrem

Ciao, Il Mar, 7 Luglio 2015 11:12 am, Torbjörn Granlund ha scritto: bodr...@mail.dm.unipi.it writes: Maybe we should improve mpn_rootrem for small sizes in general... Tabling start values is hard, but we should consider doing it for k some limit, and perhaps provide just 4 bits. We

Re: Anomaly in mpn_sqrtrem and mpn_rootrem

Ciao, Il Mer, 8 Luglio 2015 8:31 am, Niels Möller ha scritto: bodr...@mail.dm.unipi.it writes: If H=floor(sqrt(A/B^2n)), then the residual we need to compute the lower half of the square root is floor(A/B^2n)-H^2 . I don't follow you here. Consider a simple case: A of size 2n, and we try

Re: Anomaly in mpn_sqrtrem and mpn_rootrem

Ciao, On Tue, July 14, 2015 11:48 am, bodr...@mail.dm.unipi.it wrote: estimate. The trick I suggest consists in adding some fractional digits of log2(n), by table lookup, then use log2(n)/k to estimate a few of the highest digits of n^(1/k), not just one. With two 256-chars tables(too

Re: mpq_cmp_z

Ciao, On Sun, August 16, 2015 11:50 pm, Torbjörn Granlund wrote: On Sat, August 15, 2015 12:37 pm, Vincent Delecroix wrote: it would be convenient to have a GMP function int mpq_cmp_z(mpq_t, mpz_t) We might consider some code sharing between the mpq_cmp and this function,

Re: Anomaly in mpn_sqrtrem and mpn_rootrem

Ciao, On Tue, August 18, 2015 10:51 am, Torbjörn Granlund wrote: I miss some rootrem logs from ChangeLog. Before the changes I just pushed, I simply reordered the steps in the loop to shorten the first and the last iteration in the loop... How much speed difference is there now, for k = 4 vs

Re: sqrt algorithm

Ciao, On Wed, July 29, 2015 10:38 pm, Niels Möller wrote: Hmm, but if we shift to make the *root* normalized, that also means that the input will always be an even number of limbs. Not entirely sure that's good, in particular for smallish sizes. But it ought to simplify some things. Current

Re: speed of mpn_sqrtrem vs mpn_rootrem

Ciao Paul, Il Mer, 22 Gennaio 2014 1:00 pm, Zimmermann Paul ha scritto: tarte% ./speed -s 1000,3000,1 -r mpn_sqrtrem mpn_rootrem.2 overhead 0.2 secs, precision 1 units of 3.53e-10 secs, CPU freq 2833.00 MHz mpn_sqrtrem mpn_rootrem.2 1000 0.000153504

Re: sqrt algorithm

Ciao, On Mon, August 3, 2015 12:02 pm, Torbjörn Granlund wrote: I don't think I ever considered a sqrlo. I remember I thought about it when we introduced mullo, and I concluded that it was hard to obtain an efficient version... but I don't remember why, so I can be wrong. All the *_basecase

Re: sqrt algorithm

Ciao, On Mon, August 3, 2015 8:48 pm, Marco Bodrato wrote: Do we need a sqrlo_basecase? The DC version of sqrlo would use a full squaring and a single mullo, so that the base_cases for sqrlo_dc are sqr_basecase, mul_basecase and mullo_basecase. Writing a working sqrlo based on the current

Re: sqrt algorithm

Ciao, On Thu, August 13, 2015 2:52 pm, Torbjörn Granlund wrote: This is my alternative mullo_basecase: Great code! May I suggest to save a variable? void mpn_mullo_basecase (mp_ptr rp, mp_srcptr up, mp_srcptr vp, mp_size_t n) { mp_limb_t h; ASSERT (n 0); h = up[0] * vp[--n]; if (n

Re: sqrt algorithm

Ciao, On Fri, August 7, 2015 9:15 am, Torbjörn Granlund wrote: Marco Bodrato bodr...@mail.dm.unipi.it writes: tune/speed-cs 1-9000 -f2 mpn_sqr mpn_sqrlo mpn_sqrmod_bnm1 overhead 5.84 cycles, units of 2.86e-10 secs, CPU freq 3500.08 MHz mpn_sqr mpn_sqrlo

Re: sqrt algorithm

Ciao, On Wed, August 12, 2015 2:03 pm, Torbjörn Granlund wrote: I tested this approach for sqrlo_basecase too, you can find the code enclosed by #ifdef SQRLO_SHORTCUT_MULTIPLICATIONS But I'm not sure it is faster, so it is currently disabled. It will obviously be faster for

GMP 6.1.0 release candidate available

. * Support for AVX-less modern x86 CPUs. * Support for NetBSD under Xen. Best regards, Marco Bodrato ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel

Re: Debian jessie does not include the gmp documentation

Ciao, Il Lun, 26 Ottobre 2015 4:42 pm, Joerg Arndt ha scritto: > The file /usr/share/doc/libgmp10/README.Debian > contains the mysterious sentences > > Sadly, due to licensing the GMP documentation is no longer shipped in > Debian. The package libgmp10-doc now contains only demo code. > >

Re: Lazy mpz allocation

Ciao, Il Lun, 9 Novembre 2015 8:36 pm, Niels Möller ha scritto: > I agree on the direction. Please do it! Done: https://gmplib.org/repo/gmp/rev/299ec6187305 Of course you may have better suggestions for mpz/init*.c (currently there are different dummy_limbs, all defined inside their own init

Re: Lazy mpz allocation

Ciao, Il Lun, 28 Settembre 2015 10:26 am, Torbjörn Granlund ha scritto: > Some weeks ago, I made a naive testsuite-driven attempt at implementing > lazy allocation. I had 55 FAILures and 114 PASSes after having fixed > these files: > > M mpz/clear.c > M mpz/clears.c > M mpz/init.c > M mpz/mul.c

binomial [Was: primorial(negative)]

Ciao, Il Mar, 10 Novembre 2015 7:39 am, Marc Glisse ha scritto: > Other functions you would particularly like to see in the C++ interface? > (I'd like 'binomial', but it is a bit more complicated because it takes 2 > arguments) The C++ interface to binomial will surely support binomial (mpz,

Re: mpq_cmp_z

Ciao, On Mon, August 24, 2015 6:24 pm, Torbjörn Granlund wrote: An alternative to messing with void * would be an interface like this: static int cmp_helper (mpq_srcptr op1, mpz_srcptr op2num, mpz_srcptr op2den) I tested this one: cmp_helper (mpq_srcptr o1, mpz_srcptr o2n, mpz_srcptr o2d,

Re: mpq_cmp_z

Ciao Vincent, Il Sab, 15 Agosto 2015 12:37 pm, Vincent Delecroix ha scritto: > Dear all, > > I am new to this list. I am a regular developer of the SageMath project > [1] in which we use mpz_t and mpq_t as our based type for integers and > rationals. We often have to compare integers with

Re: mpq_cmp_z

Ciao, Il Gio, 3 Settembre 2015 11:14 am, Torbjörn Granlund ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > PS: I'm not very happy for the testing code... too general to finely > explore the corner cases for the size-based branches... > All branc

Re: Lazy mpz allocation

Ciao, Il Lun, 31 Agosto 2015 6:27 pm, Torbjörn Granlund ha scritto: > (We should use 'attribute ((visibility ("hidden")))' for the the constant > zero limbs at any rate. I'll commit a basic patch for that soonish.) You pushed a patch to check if both 'attribute ((visibility ("hidden")))' and

Re: Shared lib symbol hiding (Was: Re: Lazy mpz allocation)

Ciao, Il Lun, 7 Settembre 2015 5:34 pm, Torbjörn Granlund ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > Maybe in some cases (e.g. the constant limb we are speaking about in > this thread) we only want to hide, without the need of an alias? > &

Re: GMP autotools upgrade

Ciao, Il Dom, 6 Settembre 2015 10:29 pm, Torbjörn Granlund ha scritto: > This means that tests are run with the help of a script, test-driver, > which reports things differently. Does this mean that we will not be able to see the Seed GMP_CHECK_RANDOMIZE= line on the log of failing tests in

Re: Lazy mpz allocation

Ciao, Il Mar, 1 Settembre 2015 6:46 am, Marco Bodrato ha scritto: > I think that the condition to distinguish mpzs that where not allocated > yet should be ALLOC(x)==0. As a consequence, MPZ_ROINIT_N can be the > interface for initialising you ask for. > I'd like a sort of &q

Re: mpz_ndiv_qr wanted

Ciao Paul, We (my fault) answered to one another privately... Il Mar, 22 Settembre 2015 8:48 am, paul zimmermann ha scritto: >> Date: Mon, 21 Sep 2015 23:09:35 +0200 >> From: "Marco Bodrato" <bodr...@mail.dm.unipi.it> >> Il Ven, 18 Settembre 2015 8

Re: Contribution to your project

Ciao, Il Lun, 11 Gennaio 2016 7:18 pm, suraj ghosh ha scritto: > How can i start contributing to your project ? what are the procedures If you want to contribute code, there are some procedures... But we shall start discussing, shouldn't we? Do you have suggestions? Functionalities you

Re: increase mini-gmp base support to 62

Ciao, Il Mer, 1 Febbraio 2017 7:20 pm, Niels Möller ha scritto: > I also prefer the conciser version without the large table. Applied. But I changed again the code that checks the base. I used the following: digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; if (base >

Re: increase mini-gmp base support to 62

Ciao, Il Ven, 3 Febbraio 2017 10:10 pm, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: >> Applied. But I changed again the code that checks the base. I used the >> following: >> if (base > 1) ... >> else if (b

Re: Recent changes to mpn_get_str/mpn_set_str

Ciao, Il Gio, 26 Gennaio 2017 1:31 pm, Torbjörn Granlund ha scritto: > It would be possible to improve the general speed for binary-to-string > conversion (i.e., mpn_get_str). One idea is to pre-invert the larger > powers. The highest power is used just once, so nothing to improve > there. The

mpn_sqrtrem{1,2}

ible to the "precision" required for measures... this is unexpected to me. [bodrato@shell ~/gmp-repo]$ tune/speed-ext -s2 -cp10 mpn_sqrtrem2 pz_sqrtrem2 apb_sqrtrem2 mpn_sqrtrem overhead 5.84 cycles, precision 10 units of 2.86e-10 secs, CPU freq 3500.07 MHz mpn_sqrt

Re: Recent changes to mpn_get_str/mpn_set_str

Ciao, Il Ven, 27 Gennaio 2017 12:27 am, Torbjörn Granlund ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > > We may also try the division-free algorithm explored by > Bouvier-Zimmermann > in their paper: https://members.loria.fr/PZimmerman

Re: Problem with gmp_randinit_set

Ciao, Il Lun, 20 Febbraio 2017 10:18 am, Marco Bodrato ha scritto: > fear) give a number greater than 2^19937 as a result. Even if we > change them to take care of the possible carry in those last > additions, we may have problems with the (few!) numbers in the range > 2^19937-2.

Re: Problem with gmp_randinit_set

Ciao, Il Dom, 19 Febbraio 2017 8:41 pm, Marco Bodrato ha scritto: > If the small patch already pushed is enough to heal the _initset, _reseed > problem, we might dec Sorry, I truncated the message. I mean, for GMP 7, we might forget the seed->sequence backward compatibility... Best r

Re: Problem with gmp_randinit_set

Ciao, Il Lun, 20 Febbraio 2017 9:25 pm, Torbjörn Granlund ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > > They all will represent the numbers (n) in the range 0..20022 with their > equivalent (2^19937-20023+n). The sketched proof follows.

Re: mpn_sqrtrem{1,2}

Ciao, Il Gio, 16 Febbraio 2017 10:45 pm, Adrien Prost-Boucle ha scritto: > Before doing heavy (for me) asm development, > I first wanted to evaluate could be the impact, on the mpz_sqrt() > function itself, of a 2-3x speedup on functions mpn_sqrtrem{1,2}. > There is some noticeable speedup only

Re: Several independent build and test failures

Ciao, Il Ven, 24 Febbraio 2017 10:01 pm, Torbjörn Granlund ha scritto: > The add_sss definition for powerpc had one operand specified Maybe the coherent name should be add_css? ... also add_csaac is defined there, somewhere we also have the macros ADDC_LIMB (may it be called add_csaa?)

Re: Recent changes to mpn_get_str/mpn_set_str

Ciao, Il Gio, 2 Febbraio 2017 5:02 pm, Torbjörn Granlund ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > > Maybe I'll try, the basecase... > > I take this as a promise. :-) A first attempt is attached. It is not specialised for base 10, and it

Re: Recent changes to mpn_get_str/mpn_set_str

Ciao, Il Mer, 15 Febbraio 2017 7:19 pm, Niels Möller ha scritto: > But on the other hand, it might be better to note that, e.g., 10^19 fits > in 64 bits, and compute 10^e as (10^19)^(floor(e/19)) * 10^(e mod 19). > Or even better, handle the power of 2 separately and note that 5^27 fits > in a

Re: mpn_sqrtrem{1,2}

Ciao, Il Dom, 29 Gennaio 2017 5:29 am, Bradley Lucier ha scritto: > One checks the correctness of each of these routines by showing, > e.g., that for each uint32_t value i, that sqrt64_float_double > gives the correct answer for (i*i) and (i*i + 2*i), so by > monotonicity it gives the correct

Re: Recent changes to mpn_get_str/mpn_set_str

Ciao, Il Mar, 28 Febbraio 2017 11:04 pm, Torbjörn Granlund ha scritto: > Now the crossover is around 5 limbs. > > The cross-over between old base-case code for base 10 and the > new "base-case" code? Yes, for 6 limbs or more, the new code is faster than the old one for all the bases I tested.

Re: Using MPZ_ROINIT_N in mpz sources

Ciao, Il Dom, 27 Novembre 2016 10:30 am, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: >> Moreover, can we slightly abuse it to obtain a static lazy init w/out >> calling the _init function? E.g. > > If we want to do that, I

Re: New mini-gmp macro GMP_CMP?

Ciao, Il Gio, 24 Novembre 2016 4:44 pm, Niels Möller ha scritto: > Looks fine to me. I find the result on overflow a bit odd (but I think > it's the same as gmp). If I understand it correctly, the value v of > mpz_get_si (u), is defined by the conditions > > sgn(v) == sgn(u) and > v == u

Re: Help stabilising mini-gmp

Ciao, Il Mer, 16 Novembre 2016 11:57 pm, Niels Möller ha scritto: > t...@gmplib.org (Torbjörn Granlund) writes: > >> ni...@lysator.liu.se (Niels Möller) writes: >> It could also use some units test of its own; result is easy to >> validate. >> >> Perhaps better tests are needed. > > There

Re: Help stabilising mini-gmp

Ciao, Il Lun, 14 Novembre 2016 3:49 pm, Torbjörn Granlund ha scritto: > 2. There are inexplicable timeouts (or possibly excessive memory use) >triggered by t-pprime_p for some of our systems: >Perhaps the test is simply too slow, or its time varies hugely, or it >hits an infinite

Using MPZ_ROINIT_N in mpz sources

Ciao, I do not remember if we require C99 to compile the library... Can we use MPZ_ROINIT_N inside our sources to improve readability? e.g. *** /tmp/mpz/gcdext.c 2016-11-27 08:23:37.281277360 +0100 --- /gmp-repo/mpz/gcdext.c 2016-11-27 08:18:22.512770938 +0100 *** *** 91,113

Re: Changes for GMP 6.1.2

Ciao, Il Mar, 29 Novembre 2016 9:41 pm, Torbjörn Granlund ha scritto: > I think we should make 6.1.2, mainly for mini-gmp but also with a bunch > of GMP changes listed below. > > I'd like to ask the mini-gmp changes to either copy the current code to > the gmp-6.1 repo, or if you prefer

Re: mpz_gcd_ext(NULL, ...)

Ciao. Il Dom, 1 Gennaio 2017 7:30 pm, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: >> While we are looking at gcdext, I propose a small change to save an >> allocation when t must be computed. Can you review it, to check if the >

Re: mpz reuse test takes too much time

Ciao, Il Ven, 2 Dicembre 2016 11:50 pm, Torbjörn Granlund ha scritto: > Target operands which are not also input operands are now overwritten > with garbage via the CLOBBER macro. (It would make sense to do this in > almost every other GMP test file.) I like the macro. > I split your gcdext

Re: Changes for GMP 6.1.2

Ciao, Il Mer, 30 Novembre 2016 7:08 am, Niels Möller ha scritto: > I think it will be easier for us to keep track if we copy head mini-gmp Agreed, m -- http://bodrato.it/ ___ gmp-devel mailing list gmp-devel@gmplib.org

Re: mpz_gcd_ext(NULL, ...)

Ciao, Il Ven, 25 Novembre 2016 2:11 pm, Marc Glisse ha scritto: > On Fri, 25 Nov 2016, Niels Möller wrote: > >> Marc Glisse writes: >>> a user was asking if we could support calling mpz_gcd_ext with a NULL >>> first argument (the gcd), since they are only interested in the

Re: Changes for GMP 6.1.2

Ciao, Il Mer, 30 Novembre 2016 7:08 am, Niels Möller ha scritto: > I think it will be easier for us to keep track if we copy head mini-gmp I hope I did it correctly. > (except the ChangeLog file which now needs special handling). Not done yet. -- http://bodrato.it/

Re: gcdext, computing the biggest cofactor only [was: mpz reuse test takes too much time]

Ciao, Il Dom, 18 Dicembre 2016 6:00 pm, Marco Bodrato ha scritto: > Another alternative is to zero-pad the smallest operand. The _documented_ > interface of mpn_gcdext allows this trick. > A possible patch follows, it swaps back A and B if only the biggest > cofactor is needed

Re: mpn_sqrtrem1

Ciao, Il Lun, 19 Dicembre 2016 6:21 pm, Adrien Prost-Boucle ha scritto: > That said, the interesting part in my code is these functions: > - sqrt32_inv()for single 32-bit words > - sqrt64_inv()for single 64-bit words > - sqrt64x2_inv() for double 64-bit words Is there a reason why you

Re: PS: mpn_sqrtrem1

Ciao, Il Mar, 20 Dicembre 2016 7:09 pm, Adrien Prost-Boucle ha scritto: > I'm not sure using a table of invroot*invroot would bring speedup. > But using a table involves adding a table to the binary + doing a memory > access. There is a table already. My proposal is: using a single table, with

Re: mpn_sqrtrem1

Ciao, Il Mar, 20 Dicembre 2016 7:29 pm, Adrien Prost-Boucle ha scritto: >> Reducing the number of multiplications is possible... but I bet a >> Karatsuba umul_ppmm() is not faster than the plain version (at least not >> on current 64-bits CPUs ;-) > > Thank you for the analysis, I was curious :-)

Re: mpn_sqrtrem1

Ciao, Il Lun, 19 Dicembre 2016 6:21 pm, Adrien Prost-Boucle ha scritto: > The program enables to launch benchmark with these commands: > ./sqrt bench32 1000 > ./sqrt bench64 1000 > ./sqrt bench64x2 1000 It is quite difficult to interpret the numbers, times spent by direct calls to

Re: mpn_sqrtrem1

Ciao, Il Mer, 21 Dicembre 2016 12:20 am, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: >> +__x1 = (mp_limb_t) __ul * __vl; \

gcdext, computing the biggest cofactor only [was: mpz reuse test takes too much time]

Ciao, Il Sab, 3 Dicembre 2016 12:13 pm, Niels Möller ha scritto: > In the case > > mpn_gcdext(G, S, NULL, A, B) > > with size(A) < size(B), IIRC we currently handle that by swapping > arguments, calling mpn_gcdext to compute T (even though the caller You remember correctly. > That doesn't

Re: mpn_sqrtrem{1,2}

Ciao, Il Ven, 24 Marzo 2017 11:54 pm, Adrien Prost-Boucle ha scritto: > This page, at the end, tends to discourage playing with rounding mode too > frequently: > https://www.gnu.org/software/libc/manual/html_node/Rounding.html This page is about writing portable code using libc, here we have a

Re: mpn_sqrtrem{1,2}

Ciao, Il Gio, 23 Marzo 2017 8:46 pm, Adrien Prost-Boucle ha scritto: >> About the pure C code, integer version that was working on, >> But... when I put that code in GMP code, that resulted in >> a noticeable slowdown /o\ > Problem solved. > Branch prediction made GMP's sqrtrem1 appear faster

Re: mpn_sqrtrem{1,2} - patch for pure C implem

Ciao, Il Mar, 28 Marzo 2017 9:18 pm, Adrien Prost-Boucle ha scritto: > The diff is at the end of this message. Based on rev 17327. > It's a bit ugly with interleaved ++ and -- ... > Basically, remove previous mpn_sqrtrem1 and replace by my 2 versions, 32 > and 64b. You didn't try ./configure

Re: mpn_sqrtrem{1,2}

Ciao, Il Mer, 15 Marzo 2017 8:56 pm, Adrien Prost-Boucle ha scritto: > Hi, > >> I miss a case: 32 bits; to fully evaluate the impact of the patch+FP on >> one-limb operands in the range 1..62. > > Isn't 64-bit and 32-bit data identical, for one mpn_sqrtrem1 call on > x86-64? > I don't get why we

Re: mpn_sqrtrem{1,2} - patch for pure C implem

Ciao, Il Sab, 1 Aprile 2017 9:02 pm, Adrien Prost-Boucle ha scritto: > On Sat, 2017-04-01 at 18:15 +0200, Marco Bodrato wrote: >> After the patch: >> $ (cd tests/devel; make sqrtrem_1_2)& tests/devel/sqrtrem_1_2 c >> Corner cases tested, up to bits: >> \ 63 >

Re: mpn_sqrtrem{1,2}

Ciao, Il Gio, 9 Marzo 2017 2:33 am, Torbjörn Granlund ha scritto: > Marco Bodrato <bodr...@mail.dm.unipi.it> writes: > After the patch. > real3m47.247s The time to compute and check 2^33 square roots, but it can be reduced. > Almost 2x speedup, awesome! Yes, Adr

Re: mpn_sqrtrem{1,2}

e. Before the patch. [bodrato@shell ~/gmp-repo/tests/devel]$ time ./sqrtrem_1_2 c Values of a single limb, tested. Values with at most a limb for reminder, tested. Values of at most two limbs, tested. real6m39.725s After the patch. [bodrato@shell ~/gmp-repo/tests/devel]$ time ./sqrtrem_1_

Re: mpn_sqrtrem{1,2} - patch for pure C implem

Ciao, Il Mer, 29 Marzo 2017 8:38 am, Adrien Prost-Boucle ha scritto: > On Wed, 2017-03-29 at 02:06 +0200, Marco Bodrato wrote: >> You didn't try >> ./configure ABI=32 && make && make check >> did you? > Standard copy/paste problem... > Just repla

Re: Is asm code selection optimal?

Ciao, Il Mar, 16 Maggio 2017 3:53 pm, Torbjörn Granlund ha scritto: > Therefore the "tuneup" GMP test reporting category now contains tables > comparing all working assembly code for each CPU. Really interesting! > Sample result file: >

Re: mpn_sqrtrem{1,2} - patch for pure C implem

Ciao, Il Gio, 8 Giugno 2017 9:44 am, paul zimmermann ha scritto: >Dear Marco, > - in the 1-limb routine mpfr_sqrt1(), in the > at the end we have u0*2^GMP_NUMB_BITS = r0^2 + rb*2^GMP_NUMB_BITS + sb I'll look into it. > - similarly in mpfr_sqrt2() in the else branch we have > {np,

Re: mpn_sqrtrem{1,2} - patch for pure C implem

Ciao, Il Sab, 1 Aprile 2017 9:02 pm, Adrien Prost-Boucle ha scritto: > The new diff is at the end of this message. I got inspired by Adrien's code and by Paul's one, and I wrote another candidate replacement for mpn_sqrtrem{1,2}, working for both 32 and 64 bits. My goals: - new code should not

Re: mini-gmp and mpq

Ciao, I reply to an e-mail from gmp-discuss. Il Lun, 19 Febbraio 2018 5:24 pm, Marc Glisse ha scritto: > On Mon, 19 Feb 2018, Marco Bodrato wrote: >> Il Mer, 14 Febbraio 2018 8:07 pm, Andreas Fabri ha scritto: >>> 2) the conversion of a mpq to its closest double >> >

Re: mini-gmp/README

Ciao, Il Ven, 4 Maggio 2018 11:35 pm, Vincent Lefevre ha scritto: > On 2018-05-04 23:20:57 +0200, Marco Bodrato wrote: >> Should we add to the "as specified in the GMP manual, with a few >> exceptions:" section also this line? >> >> When mpz_get_str alloca

mini-gmp/README

Ciao, Should we add to the "as specified in the GMP manual, with a few exceptions:" section also this line? When mpz_get_str allocates the string, it can be longer than needed. Ĝis, m -- http://bodrato.it/ ___ gmp-devel mailing list

Re: _ptr and _srcptr types

Ciao, Il Lun, 14 Maggio 2018 1:58 pm, Torbjörn Granlund ha scritto: > Emmanuel Thomé writes: > > ~/gmp $ grep 'mp[a-z]*_[a-z]*ptr' doc/gmp.texi > @deftypefun mpz_srcptr mpz_roinit_n (mpz_t @var{x}, const mp_limb_t > *@var{xp}, mp_size_t @var{xs}) > The return type

mpq_get_d [Was: mini-gmp and mpq]

Ciao Marc, Il Lun, 19 Febbraio 2018 5:24 pm, Marc Glisse ha scritto: > On Mon, 19 Feb 2018, Marco Bodrato wrote: >> mpq_get_d currently gives a double, but rounded towards zero... > > Except when it uses the broken generic code :-( If you want, you can check the changed gener

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" <bodr...@mail.dm.unipi.it> writes: >> Currently there's always at least one readable limb, so for instance >> @code{mpz_get_ui} can fetch @code{_mp_d[0]} unconditionally (t

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

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: mini-gmp and mpq

Ciao, Il Mer, 28 Febbraio 2018 12:42 am, Bradley Lucier ha scritto: > Thanks. I tried this test on my machine: Finally, the mini-mpq code is in the development library. https://gmplib.org/repo/gmp/file/tip/mini-gmp I'll be happy if you want to test it or write any comment about it. Previous

Re: Any interest in multi-threaded code?

Ciao, Il Lun, 7 Maggio 2018 9:02 pm, Victor Shoup ha scritto: > I finally have time to study this. > Then I found out about .bootstrap...that doesn't work either > (no aclocal-1.8). Tried editing .bootstrap to remove "-1.8"...errors. I merged the current head with that 10 years old repository,

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

Ciao, Il Mer, 14 Marzo 2018 8:10 pm, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > >> #if defined(USE_FLOAT_H) >> #include >> #endif > > This won't work well for mini-gmp. >>> I'd also say that

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

Ciao, Il Sab, 19 Maggio 2018 11:16 pm, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > >> diff -r 41e50c4fdc46 bootstrap.c >> +#define DONT_USE_FLOAT_H 1 >> #include "mini-gmp/mini-gmp.c" >> di

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

Ciao, Il Dom, 20 Maggio 2018 9:57 pm, Niels Möller ha scritto: > "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: > You could consider making this into small step towards modularizing > mini-gmp. Something like > #ifndef MINI_GMP_FLOAT_SUPPORT > ... The ide

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

Ciao, Il Lun, 21 Maggio 2018 7:06 am, Niels Möller ha scritto: > t...@gmplib.org (Torbjörn Granlund) writes: > >> Would it be beneficial to add some non-IEEE host to the GMP autobuild >> setup? We could revive vax using simh. Yes, of course. > Can VAX be supported using the generic code,

Re: _ptr and _srcptr types

Ciao, Il Mar, 22 Maggio 2018 11:53 am, Torbjörn Granlund ha scritto: > But we won't argue against Vincent casting > the terminating mpz_inits argument to mpz_ptr (but hopefully he refrains > from doing that until we solemnly declare that we have pronounced it as > part of the GMP standard). :-)

Re: _ptr and _srcptr types

Ciao Emmanuel, Il Lun, 14 Maggio 2018 10:00 am, Emmanuel Thomé ha scritto: > May I suggest one or several of the following things be done ? > - document the mpz_srcptr type somewhere, so that the documentation is >self-contained. > - document all the mp*_*ptr types > I might suggest a

Re: GMP and C++11 move constructors

From gmp-discuss: Il Lun, 21 Maggio 2018 12:15 pm, Marc Glisse ha scritto: > If m is a > moved-from object, it is fine to assign a new value to it with m = > whatever. That's even what std::swap does. It should also be fine to > read from it, although you can't rely on any specific value so

Re: mini-gmp and mpq

Ciao, Il Sab, 28 Aprile 2018 10:16 am, Marco Bodrato ha scritto: > Finally, the mini-mpq code is in the development library. > https://gmplib.org/repo/gmp/file/tip/mini-gmp Uhm... I added both a new file mini-mpq.c, and a new mini-mpq.h ... Maybe we should merge mini-gmp.h and mini

Re: mini-gmp and mpq

Ciao, Il Mer, 2 Maggio 2018 3:05 pm, Torbjörn Granlund ha scritto: >On 04/30/2018 04:06 AM, Marco Bodrato wrote: >> Il Lun, 30 Aprile 2018 4:10 am, Bradley Lucier ha scritto: >>> The important case is when a=b, but I just realized that the test >>> can be refi

Re: C99 and GMP

Ciao Marc, Il Gio, 26 Aprile 2018 4:40 pm, Marc Glisse ha scritto: > Marco had a mini-mpq that seemed to be in a working state. I guess it is > missing tests, so too much work for 6.2. Is that a correct interpretation > of the status? I pushed it, so that you can see the status ;-) I did not

Re: mini-gmp and mpq

Ciao, Il Dom, 29 Aprile 2018 8:24 pm, Bradley Lucier ha scritto: > On 04/28/2018 04:16 AM, Marco Bodrato wrote: >> Finally, the mini-mpq code is in the development library. >> https://gmplib.org/repo/gmp/file/tip/mini-gmp > I haven't tested the code, but I have examined it

Re: mini-gmp and mpq

Ciao, Il Lun, 30 Aprile 2018 4:10 am, Bradley Lucier ha scritto: >> On Apr 29, 2018, at 9:02 PM, Marco Bodrato <bodr...@mail.dm.unipi.it> >>> Il Dom, 29 Aprile 2018 8:24 pm, Bradley Lucier ha scritto: > Looks good. The important case is when a=b, but I just real

Re: udiv_qr_3by2 vs divappr

Ciao Niels, Il Dom, 29 Aprile 2018 10:52 am, Niels Möller ha scritto: > #if 0 > q1 += (r1 >= d1); > #else > /* FIXME: Take care of this case more efficiently, > need analysis of the case n1 == d1. */ > if (r1 >= d1 && q1 != GMP_NUMB_MAX) > q1++; > #endif On some CPU saturating

Re: Fast mpz_bin_ui

Ciao, Il Gio, 28 Dicembre 2017 8:14 am, Niels Möller ha scritto: > Replacing multiplies by squares is no gain for scalar numbers, but Of course, but this gives me an idea... > Let's look closer at one of the functions. >> mul6 (mp_limb_t m) >> { >> - mp_limb_t m01 = (m + 0) * (m + 1); >> -

Re: gmp_snprintf tries to allocate 18 EB on long strings

Ciao, Il Gio, 1 Febbraio 2018 11:32 am, Niels Möller ha scritto: > I think we should be able to rely on C99 vsnprintf. If need, check for > correct behavior in configure, and fall back to repl_vsnprintf if I'd try to reject the return value -1 in configure, where a short string is tested. Then

Re: gmp_snprintf tries to allocate 18 EB on long strings

Ciao, Il Mar, 23 Maggio 2017 8:34 pm, Vincent Lefevre ha scritto: > Consider the following program: > r = gmp_snprintf (NULL, 0, "%2147483600s%100s%ln", "", "", ); > package), I get after 273 seconds: > > GNU MP: Cannot allocate memory (size=18446744071562067968) > > Wow! 18 EB! Actually this

Re: [RFC][PATCH] mini-gmp: move memory allocation out of loops

Ciao, Il Sab, 10 Febbraio 2018 7:07 pm, Ilya Yanok ha scritto: > thanks a lot for your comments. Thank you for spotting a function that was not as efficient as it could (easily) be :-) Keep on the good work!-) > On Sat, Feb 10, 2018 at 6:11 PM Niels Möller wrote: >> Note

Re: [RFC][PATCH] mini-gmp: move memory allocation out of loops

Ciao! Il Mar, 6 Febbraio 2018 7:21 pm, Ilya Yanok ha scritto: > I did a small patch for mini-gmp, that removes memory allocations in loop, > when mpz_get_str gets called. This might be undesired behaviour in the May I suggest a different approach? Modify mpn_div_qr_1_preinv to work in-place,

Re: How to push

Ciao, Il Ven, 9 Febbraio 2018 5:04 pm, Win C ha scritto: > I have tried to do an `hg push` to the repo of gmp. However, it says: I think the way Ilya Yanok just used is the correct answer to "how to push". Share the proposed (small, readable and explained) change on the list and wait to see if

<    1   2   3   4   5   >