openfhe: support cyclic repetition for MakePackedPlaintext

[ZenithalHourlyRate]

Partially address #645.

This PR adds cyclic repetition code in openfhe emitter to address the client-interface issue and add_plain/mul_plain issue.

All existing tests/Example passes with this change.

Problems

• In the generated client-interface, should we add assertions that input vector length equals what has been specified (ciphertext-degree), and slot num divides input vector length, so that user wont provide malformed input.

• I added a dot_product example for CKKS, which turned out to be not working works now.

In the execution, I got the following log.

v5=EvalMultNoRelin v1, v2
result decrypted: (2, 6, 12, 20, 30, 42, 56, 72,  ... ); Estimated precision: 44 bits
                                                                                         
v6=Relinearize v5
result decrypted: (2, 6, 12, 20, 30, 42, 56, 72,  ... ); Estimated precision: 44 bits
                                                                                         
v8=EvalAdd v6, v7
result decrypted: (12, 16, 22, 30, 40, 52, 66, 82,  ... ); Estimated precision: 44 bits

v9=EvalRotate v8, 6
result decrypted: (66, 82, 12, 16, 22, 30, 40, 52,  ... ); Estimated precision: 44 bits

v10=EvalRotate v6, 7
result decrypted: (72, 2, 6, 12, 20, 30, 42, 56,  ... ); Estimated precision: 44 bits

v11=EvalAdd v9, v10
result decrypted: (138, 84, 18, 28, 42, 60, 82, 108,  ... ); Estimated precision: 43 bits

v12=EvalAdd v11, v6
result decrypted: (140, 90, 30, 48, 72, 102, 138, 180,  ... ); Estimated precision: 43 bits

v13=EvalRotate v12, 6
result decrypted: (138, 180, 140, 90, 30, 48, 72, 102,  ... ); Estimated precision: 43 bits

v14=EvalAdd v13, v10
result decrypted: (210, 182, 146, 102, 50, 78, 114, 158,  ... ); Estimated precision: 43 bits

v15=EvalAdd v14, v6
result decrypted: (212, 188, 158, 122, 80, 120, 170, 230,  ... ); Estimated precision: 43 bits

v16=EvalRotate v15, 6
result decrypted: (170, 230, 212, 188, 158, 122, 80, 120,  ... ); Estimated precision: 43 bits

v17=EvalAdd v16, v10
result decrypted: (242, 232, 218, 200, 178, 152, 122, 176,  ... ); Estimated precision: 43 bits

v18=EvalAdd v17, v6
result decrypted: (244, 238, 230, 220, 208, 194, 178, 248,  ... ); Estimated precision: 43 bits

v19=EvalRotate v18, 7
result decrypted: (248, 244, 238, 230, 220, 208, 194, 178,  ... ); Estimated precision: 43 bits

v20=EvalAdd v19, v6
result decrypted: (250, 250, 250, 250, 250, 250, 250, 250,  ... ); Estimated precision: 42 bits

v22=EvalMult v20, v21
result decrypted: (-0.964405, -3.17029, 2.08717, 0.390794, -2.29587, -1.21179, -2.3761, 1.5405,  ... ); Estimated precision: 43 bits

v23=EvalRotate v22, 7
result decrypted: (1.5405, -0.964405, -3.17029, 2.08717, 0.390794, -2.29587, -1.21179, -2.3761,  ... ); Estimated precision: 43 bits

Expected: 250
Actual: (1.5405,  ... ); Estimated precision: 43 bits

The error part comes from the following code. Apprently the onehot selection is not working. Is that the way I treat MakeCKKSPackedPlaintext wrongly?

  std::vector<double> v3 = {0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, 1.000000e+00};

  auto v3_filled_n = v0->GetCryptoParameters()->GetElementParams()->GetRingDimension() / 2;
  auto v3_filled = v3;
  v3_filled.clear();
  v3_filled.reserve(v3_filled_n);
  for (auto i = 0; i < v3_filled_n; ++i) {
    v3_filled.push_back(v3[i % v3.size()]);
  }
  const auto& v21 = v0->MakeCKKSPackedPlaintext(v3_filled);
  const auto& v22 = v0->EvalMult(v20, v21);

[ZenithalHourlyRate]

Expected: 250

This overflows CKKS encoding space... clearly we do not have that much space before the decimal point when reduced to the last level. Changed the values to 2.5 and everything works now.

[ZenithalHourlyRate]

Rebased to pass the CI.

[AlexanderViand-Intel]

Another great quality-of-life improvement around RLWE, thanks!

[asraa]

Nice! Thanks - just a qq on the unit test

[ZenithalHourlyRate]

Fixed //tests/Transforms/mlir_to_openfhe_ckks:naive_matmul.mlir.test