Hello, I found an unexpected behavior in EvalSum function of the python wrapper, as the results are wrong with batch sizes bigger or equal to 1024.
Please check the GitHub issue for the full details EvalSum "bug" · Issue #169 · openfheorg/openfhe-python · GitHub.
Am I missing something? Could it be the combination of component-wise difference and Sum?
This depends on the norm of the input values. If the sum is higher than roughly 2^{60}/2^{50} (for your cryptocontext parameters), then you will have an overflow and need an extra RNS limb (level) to support larger numbers. This issue has been discussed/answered multiple times in the Discourse forum. It does not look like a bug to me.
Actually, the inputs are vectors of 1024 randomly generated elements in [-1,1]. Even with the square, the sum could never reach 2^{50}.
I suggest watching https://www.openfhe.org/portfolio-item/homomorphic-encryption-for-palisade-users/ to understand how CKKS encodes real numbers (or reading the introductory sections of Approximate Homomorphic Encryption with Reduced Approximation Error). At a high level, real numbers are scaled up by the scaling factor (2^{50}) and then rounded to integers (I am skipping the FFT-based packing for simplicity). So the sum (for the first modulus size of 60 bits) should not exceed roughly 2^{10} rather than 2^{50} (see my response where I pointed to to this). Otherwise you will have an overflow. You can either decrease the input size (losing in precision) or add an extra level (to get extra 50 bits) to resolve this.
There are multiple topics in this forum discussing/explaining the overflow behavior, e.g., EvalAdd does not add in some cases - #7 by ypolyakov, Can it come to overflow by multiplication, CKKS Bootstrapping gives incorrect results on scale != 60? - #6 by ypolyakov.
Got it, I’ll study the suggested material. Thanks for your help!