Convolution

[lehugueni]

Addition of the convolution API and one reference implementation (+ tests).

The reference implementation for now uses the FFT in the X variable and does a naive convolution along Y.

In this reference implementation, a prepared convolution ZNX vector is computed by taking the FFT of each limb (every ZNX), and then extracting each bulk and storing it contiguously.

The preparation of left and right vectors is identical.

[Pro7ech]

Why does one need both left and right prepare types? There is always at least one input that cannot be known in advance, so one of the prepare can be deferred inside the convolution call. This would simplify the API to something like conv(res: vec_znx, a:vec_znx, b:CNV_PVEC) and have only a CNV_PVEC instead of left and right types.

[lehugueni]

Why does one need both left and right prepare types? There is always at least one input that cannot be known in advance, so one of the prepare can be deferred inside the convolution call. This would simplify the API to something like conv(res: vec_znx, a:vec_znx, b:CNV_PVEC) and have only a CNV_PVEC instead of left and right types.

I guess it's possible that in some cases both sides of a convolution are reused in several computations making it faster to have them both prepared. For instance, if we do the internal product in a naive way, each component $a, b$ of a ciphertext $(a,b)$ is involved in two convolutions. But @ngama75 probably knows best the rational behind this API.

[ngama75]

yes, at first, I wanted to avoid the prepared cnv's.
But it turned out that for RLWE products, it makes sense to compute cross products using things like: (a1+a2)(b1+b2) - a1.a2 - b1.b2, which requires to store and add in DFT space before the actual cnv...

At the very least, the prepared cnv's are meant to be short-lived/local and cnv_prepare should be as fast as possible (unlike vmp_prepare and svp_prepare).

For left and right: even though cnvs are supposed to be symmetric on paper, some arithmetic backends (e.g. NTT120) behave much better if the two operands of a product use different encodings. -> this is why we have left and right, and the two cannot mix by addition.
For the FFT64 backend, exceptionally, left and right are identical.

[ngama75]

looks good! thanks!

[MGeorgie]

ok