Mixed-radix NTT support all orderings

[yshekel]

No description provided.

[DmytroTym]

One issue I have with this PR is that it's possible to force old radix-2 algorithm with an ordering like NM or MN. It might seem like test_ntt_batch checks correctness of it but it only compares batch and non-batch outputs of the same algorithm. While the outputs for radix-2 are consistent, they are not correct. Correct me if I'm wrong here. In terms of how to deal with NM and MN orderings in radix-2 NTT - I'm fine with a runtime error tbh cos it doesn't make a lot of sense.

About Rust NTT tests - they now take a pretty long time. One idea might be to put looping over the two algorithms as deeply as possible instead of at the very beginning of the test. This should reduce the CPU side work which is where the vast majority of test time goes into. Also it should make diffs much smaller and nicer to look at.

[HadarIngonyama]

all in all looks fine, just wanted to ask - did you make sure that the changes to the reordering kernels didn't harm the performance of the simple cases (I don't think the should, but just to verify)

[yshekel]

One issue I have with this PR is that it's possible to force old radix-2 algorithm with an ordering like NM or MN. It might seem like test_ntt_batch checks correctness of it but it only compares batch and non-batch outputs of the same algorithm. While the outputs for radix-2 are consistent, they are not correct. Correct me if I'm wrong here. In terms of how to deal with NM and MN orderings in radix-2 NTT - I'm fine with a runtime error tbh cos it doesn't make a lot of sense.

About Rust NTT tests - they now take a pretty long time. One idea might be to put looping over the two algorithms as deeply as possible instead of at the very beginning of the test. This should reduce the CPU side work which is where the vast majority of test time goes into. Also it should make diffs much smaller and nicer to look at.

One issue I have with this PR is that it's possible to force old radix-2 algorithm with an ordering like NM or MN. It might seem like test_ntt_batch checks correctness of it but it only compares batch and non-batch outputs of the same algorithm. While the outputs for radix-2 are consistent, they are not correct. Correct me if I'm wrong here. In terms of how to deal with NM and MN orderings in radix-2 NTT - I'm fine with a runtime error tbh cos it doesn't make a lot of sense.

About Rust NTT tests - they now take a pretty long time. One idea might be to put looping over the two algorithms as deeply as possible instead of at the very beginning of the test. This should reduce the CPU side work which is where the vast majority of test time goes into. Also it should make diffs much smaller and nicer to look at.

@DmytroTym @HadarIngonyama
Regarding NM, MN for radix-2: The way I am thinking about it is as follows: M (=Mixed) is by definition the order of the elements that a DIF NTT/INTT would produce given Natural inputs. DIT NTT/INTT of the same size expects this same order to output the Natural order back. Different NTT sizes would mix the elements differently but consistently per size. For element-wise ops like multiplication this is useful but again the only thing guaranteed here is consistency per size.
Therefore I am thinking of radix-2 R as a special case of M which means that NR an NM are the same for radix-2 (and same for RN and MN). I don't see a reason why this is invalid to do or should throw an assertion. Technically a radix2 NTT can be plugged to the mixed-radix algorithm and the top-level table would be all ones in the logn size, such that digit-reversal is exactly bit-reversal and so we have logn stages, each composed of N/2 NTTS of size 2.

You are right that the batch test is only testing that batch computation is equivalent to a simple loop over the elements with btach=1 for each.

User who want to specifically get R should specify R, not M and this is a stronger request. For radix-2 it's free but for mixed-radix alg it's more expensive and therefore if not required (like for poly multiplication) then M is good enough.

Regarding rust tests, TBH I did not think about it too much and thought that most of the time is building but yes you are right I will try to nest the loop and avoid reallocation of arrays etc. The small downside of that is that in-place computations (when/if we add them) may fail or behave different then expected although since we randomize inputs it's maybe not really a problem.

[yshekel]

all in all looks fine, just wanted to ask - did you make sure that the changes to the reordering kernels didn't harm the performance of the simple cases (I don't think the should, but just to verify)

@HadarIngonyama do you mean that NN for example is not slower now? I did not verify since I did not think there should be any difference at all but I will verify just to be 100% sure.