Zimmermann Paul paul.zimmerm...@inria.fr writes:
thank you for the feedback. Yes the new curve is not everywhere optimal, but
the important thing is that it is much more regular, which is critical
for algorithms assuming that when we cut both numerator and divisor (for
a fixed-size
Hi Torbjörn,
I got back to this now, and finally committed a patch.
New diagrams at gmplib.org/devel/.
Things are still not perfect. More work is needed.
thank you for the feedback. Yes the new curve is not everywhere optimal, but
the important thing is that it is much more
Torbjörn,
You might want to try this patch. It removes lots of code, originally
put in place for saving memory. It allows the divappr function to do
its job more smoothly.
this is much better with this patch. Before I got:
frite% ./bug2 201 101
mpz_tdiv_q(201,101)
You might want to try this patch. It removes lots of code, originally
put in place for saving memory. It allows the divappr function to do
its job more smoothly.
I am not sure this is the best change. Selecting 'in' better in the
first place might have certain advantages. More work is needed.
Hi,
on January 25 I reported efficiency issues with unbalanced multiplication.
Here I report similar issues with unbalanced division. Consider the program
below. I get on a 2Ghz Intel Xeon E7540 with GMP 5.1.0:
barbecue% ./bug2 201 101
mpz_tdiv_q(201,101) took 2244ms
