Holds the scale in TenSEALContext about tenseal HOT 5 CLOSED

This is a good start to the right idea, but I also feel it would add an effort to ensure this doesn’t break in future versions of SEAL implementation or even this library.

I would propose a separate helper tool to help define the appropriate encryption parameters and scale based off of the desired algorithmic depth. This could be thought of as the equivalent to theCoeffModulus::BFVDefault function used to generate the coeff moduli for the BFV scheme.

This tool should not be coupled strongly to the native SEAL API nor this library any way, therefore posing no risk to either.

In TenSEAL, we assume that the user doesn't have enough experience in HE to deal with relin and rescaling, it would certainly be difficult on our side to deal with all these details while assuming general usage, but I think motivation(2) is a good assumption that simplify this solution. And of course we will need to give experienced user the ability to use different scale, for instance, users can still create CKKSVector with a different scale, but if they don't provide then we just use our context's scale. They should also be able to disable all these operations done after every multiplication if they want to deal with rescaling differently, but a rescaling strategy is really important for TenSEAL to be really simple to use.

from tenseal.

Good idea to simplify the API.
But since the scale is related to CKKS tensor, why don't we make it a CKKS tensor attribute, and generate or set it during tensor creation?

Mainly because of motivation(2), we don't need to set the scale for every tensor, all tensors should be having the same scale. The scale isn't a big field, using it in the TenSEALContext for CKKS and wasting that space for BFV isn't a big deal.

from tenseal.

In TenSEAL, we assume that the user doesn't have enough experience in HE to deal with relin and rescaling, it would certainly be difficult on our side to deal with all these details while assuming general usage, but I think motivation(2) is a good assumption that simplify this solution. And of course we will need to give experienced user the ability to use different scale, for instance, users can still create CKKSVector with a different scale, but if they don't provide then we just use our context's scale. They should also be able to disable all these operations done after every multiplication if they want to deal with rescaling differently, but a rescaling strategy is really important for TenSEAL to be really simple to use.

Okay, if you're already building a lot of helper logic then this makes sense to encapsulate as long as it is overridable.

from tenseal.

This is a good start to the right idea, but I also feel it would add an effort to ensure this doesn’t break in future versions of SEAL implementation or even this library.

I would propose a separate helper tool to help define the appropriate encryption parameters and scale based off of the desired algorithmic depth. This could be thought of as the equivalent to theCoeffModulus::BFVDefault function used to generate the coeff moduli for the BFV scheme.

This tool should not be coupled strongly to the native SEAL API nor this library any way, therefore posing no risk to either.

from tenseal.

Good idea to simplify the API.
But since the scale is related to CKKS tensor, why don't we make it a CKKS tensor attribute, and generate or set it during tensor creation?

from tenseal.