Alexander Viand

> I'm considering renaming this pass something like `materialize-layouts` or `convert-to-simd-ciphertext-ops` or something. 👍 I think it'd be great for documentation/explainability if we settled on some names for the two...

In the future, we should seriously consider going for a https://marimo.io/ based notebook rather than Jupyter, as it seems to have much more powerful features for embedding MLIR syntax properly,...

> > it could still be a plaintext rotation index > > Agreed about the semantic distinction, but I don't see a real use case for this, do you? The...

> This was done in a basic manner by #696 Oh, nice! I also didn't realize that there's already https://github.com/google/heir/blob/9eccd81b21f925fb31bd2dd17ca5c5257fc5d98f/lib/Dialect/Openfhe/Transforms/ConfigureCryptoContext.cpp#L44-L53 So we'd need to pull this out, add the NAF...

I think this touches on a deeper issue with the CKKS pipeline, which is that we don't really have a semantic for the types. My intuition would be that any...

It's odd that most benchmark papers just report a single multiplication/etc speed per parameter set, as there's a significant difference between the first multiplication of two fresh ciphertexts (let's say...

I think the issue might be that you're manually specifying a very small parameter setting (n=2048), and there's just not enough "room" (coefficient modulus q) to do relinearization (a form...

Conceptually, rotation algebra probably isn't part of the BGV scheme, as the scheme doesn't even really care whether you use SIMD batching at all, so the idea of `bgv.rotate` might...

Yep, I think adding this across the whole stack (scheme dialects, lwe dialect, backend* dialects) would be a great idea! In addition to the noise benefits (and saving the encoding...

@asraa do you know what the status of this PR is? It looks like it's useful additions (squat packing) that aren't in `main` right now, but there's clearly also some...