asraa

OK, fixed the first two TODOs, so that the attribute and base GLWEPlain/CiphertextType is now present! Please take a look at syntax, naming, and doc-strings. And also please suggest any...

> I'm also mildly annoyed about the use of G for GLWE Part of this was to avoid conflict with the old types, but I can also put something like...

> Can you link me to the discussion/notes where this was hashed out? We had some notes here under the heading `2024-08-09 (LWE Types & Attributes Design)` (https://docs.google.com/document/d/10WTpdVaLz4mgmTwlJ3lVMGD4qmiNEl2Uvt3R3h0XFmc/edit?hl=en&forcehl=1) - I...

Hey! Should I start working on the migration if the types & attributes at least seem mostly ok?

Hey! @j2kun @AlexanderViand-Intel could you PTAL at the PR now? I separated out the new types and attributes into a new file for ease of searching, but the build treats...

K! Rebasing and I'll merge

You're right: ``` $ bazel query "rdeps(@openfhe//:all, @rapidjson//:rapidjson)" @cereal//:cereal @openfhe//:binfhe @openfhe//:core @openfhe//:pke @rapidjson//:rapidjson ``` https://github.com/google/heir/blob/317b1a60300e9018dcffe2f2f408468c7b2f8b3a/bazel/openfhe/cereal.BUILD `@cereal` depends on rapidjson. But it seems like https://github.com/openfheorg/cereal/tree/984e3f194862b17916536b5fade40cba6e47a6fe/include/cereal/external/rapidjson includes a vendored copy of rapidjson...?

Thank you for this! + @lawrencekhlim just for visibility into program optimizations for CKKS

> but I do think they should only be tackled after things like ciphertext maintenance optimizations The intention here is to write some rewrite patterns for the intern project before...

Thanks for such a detailed issue! > What fixed it for me was telling bazel to link to the output location of wherever the abc binary was once it was...