Simplifications

[minad]

This PR contains two things:

• Renaming some mp_(root|expt|log)_u32 functions back to suffix less version. Using uint32_t for those functions was a mistake, I have to admit that now. In particular using a suffix is not a good idea, since this is a slight obstacle now to change the types :( These functions should either take/return bitcounts (int) or mp_digits. For example mp_log is defined in terms of count_bits, so this is the natural type to use. mp_root calls mp_mul_d, so mp_digit would be a good fit. For now I am using simply int.

• Many simplifications - I hope that those will be helpful when we decide to convert the bitcount type to size_t/or something else. Furthermore these simplifications are helpful if we want to change the digit representation, such that the full width is used.

[minad]

@sjaeckel @czurnieden Since this is a huge PR touching a lot of functions, it might make sense to split it into smaller pieces, which are easier to consume, if that is desired.

[sjaeckel]

had only a quick look for now, basically looks good

[minad]

Generally, regarding this PR my proposal would be the following. I split it in three parts:

1. The suffix PR (let's decide on what suffix to use again ;)
2. One PR containing the more trivial refactorings about which I am very sure
3. Refactorings of the more complicated functions, which need a more careful review.

@sjaeckel What do you think?

[sjaeckel]

regarding this PR my proposal would be the following. I split it in three parts:

that was my first thought when I saw this huge PR

[minad]

I splitted the more complicated parts of this PR in multiple commits regarding logical units of functions. These can also be extracted to separate PRs if desired. This PR is rebased on #435.

[minad]

@czurnieden @sjaeckel If you want to open the renaming bottle, I would propose to rename mp_div_2d -> mp_rsh, mp_mul_2d -> mp_lsh and s_mp_log_pow2 -> s_mp_log_2expt. The _2d suffix is really weird. These renamings could even be backported to 1.3 with deprecations warnings if we want to ease the transition. The same applies to mp_(expt|log|root) without or with a new suffix. It is funny that we rename the functions again, but naming is really the hardest problem.

[czurnieden]

mp_div_2d -> mp_rsh, mp_mul_2d -> mp_lsh

If you want to include the proposed changes (inclusion of the subfunctions like mul_2 and mp_lshd) it is quasi a new function which sells the name change better.

Ah, I forgot one: the data type for the shift amount is still int. Would it make sense to allow for negative input and and send that to the opposite function (like in mp_add and mp_sub) or would that behaviour too surprising?

s_mp_log_pow2 -> s_mp_log_2expt.

These are private functions, what you call them should not matter at all.

but naming is really the hardest problem.

But one of the many parental duties ;-)

[minad]

Ah, I forgot one: the data type for the shift amount is still int. Would it make sense to allow for negative input and and send that to the opposite function (like in mp_add and mp_sub) or would that behaviour too surprising?

One could only provide only one shift function which decides based on the sign.
However this is not how things are usually, e.g., the >> and << operators. Furthermore there are different behaviors regarding sign extension for >>, where one operation does sign extension shift and one which extends with zeros.

I think it makes sense to keep it as is. Or rather return an error for negative shifts, this is what I did in this PR. mp_lshd and mp_rshd are special however. They ignore negative shifts since mp_rshd doesn't return an error code.

[minad]

@czurnieden If you have time in the next days, I would highly appreciate if you review the things I did here, since this could easily lead to bugs. I did things step by step and used the test suite quite often, but things could have happened. Feel free to also push additional commits if something comes up.

[minad]

@czurnieden One other thing regarding comba - since you asked about performance. Actually I don't expect there to be a huge difference between asm and the c version. In ltm we only have the generic comba and nothing unrolled. I think in tfm the performance difference comes mainly due to loop unrolling in combination with the custom assembly. Probably also due to vectorization.

[czurnieden]

I have no serious problems with the function mp_prime_strong_lucas_selfridge, s_mp_exptmod, s_mp_exptmod_fast. They look just very complex.

Took a short first glimpse, and can say with confidence: it needs a second glimpse and a much longer one, too.

BTW: I found that the cut-off values in mp_exptmod* for the number of windows a bit off from the theoretical values. Nothing serious, just wondering how they were computed in the first place because the differences seem to be too much for a simple rounding error.

1.246041023861365  :  1 
2.058660344689936  :  8             7  
3.001508362585475  :  41           36
4.002716871975187  :  162         140
5.000808585528096  :  530         450
6.000607510406698  :  1562       1303
7.000136942889815  :  4299       3529
8.000044561915664  :  11293     <- max. needed for current key-lengths in RSA plus one.
9.000030428030995  :  28666 
10.00001149850915  :  70879 
11.00000388290744  :  171647 
12.00000044772216  :  408691 
13.00000095004352  :  959458
14.00000022160508  :  2225683 
15.00000011060768  :  5110211
16.00000000335862  :  11628824
17.00000004155538  :  26255994
18.00000001397662  :  58871894
19.0000000058284  :  131190198
20.00000000346447  :  290726600
21.00000000150675  :  641052593
22.00000000078542  :  1407118193

Computed with the abomination below

tempfile=$(mktemp /tmp/maxima_out.XXXXXX) && maxima -q --batch-string='eqn5:-(a/x^2)+2^x * log(2) -1;for a:1 thru 1000000 step 1 do print(find_root(eqn5,x,1,20), " : ", a);' > $tempfile  && for i in {1..20};do grep -m1 ^$i $tempfile;done ; rm -v $tempfile

(Currently running up to 2^31 just because. Will add results when ready)

[czurnieden]

So far, so good.

[minad]

@sjaeckel this is good to merge!

[sjaeckel]

sorry for the delay, I was sick for the last week :-\