[Potential Bug Report] Two potential FIXEDMANUAL bugs in CKKS (bootstrap nsd, EvalLinearWSumMutable crash)

Library Questions
1

Hi all,

I ran into two issues with FIXEDMANUAL that I believe may be bugs, but I’d like confirmation before opening GitHub issues. Tested on a recent dev clone (commit hash 6ba41303), and main clone (commit hash ed361af2).

1. EvalBootstrap returns NoiseScaleDeg == 2 under FIXEDMANUAL

With FIXEDMANUAL, the user is responsible for all rescaling, so I expect nsd == 1 after every operation.

However, the ciphertext returned by EvalBootstrap has nsd == 2.

The cause is that the final SlotsToCoeffs step triggers EvalMultExt, which does:

result.nsd += plaintext.nsd

There is no FIXEDMANUAL correction after this step, unlike what happens after CoeffsToSlots.

Is this intended, or should the output be normalized back to nsd == 1 in FIXEDMANUAL mode?

2. EvalLinearWSumMutable crashes on FIXEDMANUAL ciphertexts at different levels

When passing ciphertexts at different levels:

  • FLEXIBLEAUTO path aligns them via AdjustLevelsAndDepthInPlace
  • FIXEDMANUAL path skips alignment
  • Then it directly calls EvalAddInPlaceNoCheck

This leads to a crash:

ModAddEq(): Called on NativeVectorT's with different parameters.
Aborted (core dumped)

Workaround

Manually reducing all inputs to the same level before calling fixes the issue:

for (auto &ct : inputs) {
    ct.LevelReduceInPlace(maxLevel);
}

Should the library not handle this internally, instead of leaving it over to the user?

2

FIXEDMANUAL is for advanced users that want to have more control over rescaling and modulus switching, and take advantage of better efficiency.

For the first issue, this behavior is intended as the developer decides on their own when to invoke Rescale. The developer may want to run more operations before calling Rescale.

For the second issue, the NoCheck function is used to make the execution faster. Again, it is intended for an advanced user (as compared to FLEXIBLEAUTO).