# EvalAdd does not add in some cases **URL:** \ **Category:** Library Questions\ **Created:** [May 2, 2023, 12:17pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517 "2023-05-02T12:17:15Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![lujoho](https://avatars.discourse-cdn.com/v4/letter/l/a587f6/32.png) [@lujoho](https://openfhe.discourse.group/u/lujoho)\ **Post date:** [May 2, 2023, 12:17pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/1 "2023-05-02T12:17:15Z")
Hello together, we are using OpenFHE and CKKS for quite a while now but lately we discovered some strange behaviour around the EvalAdd(InPlace) method. In some cases it does not add up the numbers and everything stays as it its (value, level, precision, …). It happens for Ciphertext-Plaintext addition as well as for Ciphertext-Ciphertext addition. However, if we split the value (let’s say in 20 pieces) and add them together, it works. We tried in several environments and with different crypto parameters but it happened everytime. However, the value at which this behaviour occurs changes and is not always the same. Even when we try to multiply the values with (2\*0.5) before it does not change anything, addition still does nothing. We provide a MWE here: ```auto uint32_t multDepth = 50; uint32_t scaleModSize = 59; CCParams parameters; parameters.SetMultiplicativeDepth(multDepth); parameters.SetScalingModSize(scaleModSize); CryptoContext cc = GenCryptoContext(parameters); cc->Enable(PKE); cc->Enable(LEVELEDSHE); auto keys = cc->KeyGen(); auto val = cc->Encrypt(keys.publicKey, cc->MakeCKKSPackedPlaintext(vector{1})); for(int i = 0; i<41; i++){ auto added = cc -> EvalAdd(val, i); Plaintext p; cc->Decrypt(keys.secretKey, added, &p); p->SetLength(1); cout << "Added " << to_string(i) << ":\t" << p << endl; } ``` Depending on the environment, it fails for i=5 or larger values Is this a bug? ---
**Author:** ![iquah](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/iquah/32/8_2.png) [@iquah](https://openfhe.discourse.group/u/iquah)\ **Post date:** [May 2, 2023, 5:08pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/2 "2023-05-02T17:08:54Z")
Hey there! Thanks for providing us with the MWE. That sped things up on our end. So, I can confirm that I encounter the same bug. Having said that, for a depth of 30, the bug is not present. So, you might want to drop the depth and just bootstrap. I made this issue: [When mult depth is high, repeated additions produces incorrect result](https://github.com/openfheorg/openfhe-development/issues/385) and you can follow that to track it. Hopefully this unblocks you and gives you a path forward (dropping the depth + bootstrapping) ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [May 2, 2023, 9:33pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/3 "2023-05-02T21:33:50Z")
Hi @lujoho, First, I would like to remark that using a depth of 50 is typically not a good idea for performance reasons. In many practical scenarios, 35-40 is at most that makes sense. However, this issue occurs for a smaller scaling factor, too. For instance, I get it for ```auto uint32_t multDepth = 5; uint32_t scaleModSize = 50; ``` This bug is specific to the `FLEXIBLEAUTOEXT` scaling technique, which is used by default. If you change it anything else, e.g., `FIXEDMANUAL`, `FIXEDAUTO`, or `FLEXIBLEAUTO`, the addition will work. In other words, you can add the following line to your code to fix the MWE: ```auto parameters.SetScalingTechnique(FLEXIBLEAUTO); ``` I will now update the issue. ---
**Author:** ![lujoho](https://avatars.discourse-cdn.com/v4/letter/l/a587f6/32.png) [@lujoho](https://openfhe.discourse.group/u/lujoho)\ **Post date:** [May 2, 2023, 9:49pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/4 "2023-05-02T21:49:07Z")
Hi @iquah, @ypolyakov, thank you very much for your quick replies and kind tips! I will reduce my depth and use more bootstrapping in the future. Changing the scaling technique made my workaround obsolete and everything works fine now ---
**Author:** ![lujoho](https://avatars.discourse-cdn.com/v4/letter/l/a587f6/32.png) [@lujoho](https://openfhe.discourse.group/u/lujoho)\ **Post date:** [May 4, 2023, 8:24am UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/5 "2023-05-04T08:24:14Z")
Hey together, sorry to get back to you again, but unfortunately I stepped over the same problem again. Changing the scaling technique worked fine, however, it does only work for scaleModSizes \< 59. If the scaleModSize is exactly 59 it still fails (verified it for FIXEDAUTO and FLEXIBLEAUTO) for i \> 31. I did not check all sizes and all i but for all the other scaleModSizes it seems to work. So for my code changing to scaleModSize=58 works fine, but I wanted to mention the issue nonetheless. ---
**Author:** ![lujoho](https://avatars.discourse-cdn.com/v4/letter/l/a587f6/32.png) [@lujoho](https://openfhe.discourse.group/u/lujoho)\ **Post date:** [May 4, 2023, 2:54pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/6 "2023-05-04T14:54:33Z")
Hey again, in my use case I have to add a value of roughly 400, so I noticed that the problem seems to occur for every scaleModSize. For example for scaleModSize=58 it fails for values \> 63 or for scaleModSize=55 a value \> 512 can not be added. I looked a bit further into it and e.g. for scaleModSize=50 it fails for values roughly \> 16 000 (however, such big values should not be added probably). So for me it seems that for every scaleModSize such a “threshold” value can be found. ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [May 5, 2023, 3:41pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/7 "2023-05-05T15:41:24Z")
Hi @lujoho Please keep in mind that `scaleModSize` and `firstModSize` are two related parameters. `firstModSize` is used for decryption. If the multiplicative depth is set exactly to the depth of circuit, then at the time of decryption you will be working with a single modulus of `firsModSize`. Therefore, your message cannot be larger (in bits) than `firstModSize` - `scaleModSize` (roughly). When you increase `scaleModSize` (closer to `firstModulusSize`), you decrease the room for the message. Most likely, you are getting into this issue (it is a question of using CKKS correctly rather than a bug in OpenFHE). There is an easy way to confirm this. Just increase the multiplicative depth by 1 and see if the issue goes away. If you do this, the message “budget” in bits will increase to `firstModSize`, i.e., `scaleModSize` + `firstModSize` - `scaleModSize`. Everything I described here is expected by CKKS design. ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [May 5, 2023, 3:42pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/8 "2023-05-05T15:42:17Z")
Also note that `firstModSize` = 60 by default. ---
**Author:** ![lujoho](https://avatars.discourse-cdn.com/v4/letter/l/a587f6/32.png) [@lujoho](https://openfhe.discourse.group/u/lujoho)\ **Post date:** [May 6, 2023, 11:28am UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/9 "2023-05-06T11:28:02Z")
Hi @ypolyakov thanks for your answer and explanation. I am not quite sure if I understood you correctly. I upped the depth by one (or other values) but the issue does not go away. For me it seems to be independent from the multiplicative depth. As I have a rough understanding of CKKS I selected a depth that is slightly higher than the circuit depth. However, the issue can still be replicated with the MWE from my first post, because for depth = 20, scale = 58 adding 1 + 64 results in 1. Sorry if I am too dumb and do not see the obvious problem here… ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [May 7, 2023, 2:34pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/10 "2023-05-07T14:34:36Z")
Hi @lujoho It looks you ran into another bug. The high-level story is that when you set scale mod size to 58, you end up adding 2^{58} \* value to the ciphertext. As soon value hits 64, you get 2^{58} 2^6 = 2^{64}, which overflows for 64-bit numbers. I’ve added an issue for this: [Adding a large scalar does not work in CKKS · Issue #393 · openfheorg/openfhe-development · GitHub](https://github.com/openfheorg/openfhe-development/issues/393) Please note that this scenario is not very practical for CKKS (this is why you ran into two bugs). One only needs a large scaling factor in scenarios with CKKS bootstrapping. When using CKKS bootstrapping, the message should be normalized to something like [-1,1]. Otherwise, the modular reduction approximation in CKKS bootstrapping will become inaccurate. See [Questions on CKKS bootstrapping with some computations after bootstrapping - #6 by wupengfei](https://openfhe.discourse.group/t/questions-on-ckks-bootstrapping-with-some-computations-after-bootstrapping/535/6) for a more detailed discussion on this. When one does not use CKKS bootstrapping, a much smaller scaling factor will be sufficient. So this issue is unlikely to come up. With all that said, both are real bugs, and we will address in the next bugfix version (v1.0.4). Thank you for reporting these bugs. ---
**Author:** ![lujoho](https://avatars.discourse-cdn.com/v4/letter/l/a587f6/32.png) [@lujoho](https://openfhe.discourse.group/u/lujoho)\ **Post date:** [May 8, 2023, 10:59pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/11 "2023-05-08T22:59:39Z")
Hi @ypolyakov thanks for your confirmation of the bug. We highly appreciate your explanation and practical tips! It is just an intermediate result that is higher than 1 the next step after it is to scale it down again, so when bootstrapping is applied we are always in [-1,1]. Of course this operation is very costly in terms of precision but without such large additions our algorithm does not work unfortunately. ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [June 19, 2023, 5:21pm UTC](https://openfhe.discourse.group/t/evaladd-does-not-add-in-some-cases/517/12 "2023-06-19T17:21:23Z")
v1.0.4 (with the bugfix) is now released.