Is it really necessary to confine the range of the random numbers? about federatedscope

[xieyxclack]

Thanks for your interest!
The random numbers are used in secret sharing to "hide" the plain number, which might cause the arithmetic overflow due to the summing up operation. Thus we confine the range of random numbers and apply the mod operation. The range can be adjusted according to the applications. And we encourage setting a large upper bound to ensure the privacy protection strength.

[YongGuCheng]

If you confine the range of the random numbers, then it is not safe any more, in the sense that the distribution of the random numbers is no longer uniform. Particularly, the random numbers should also take negative values (and then take mod operation).

[xieyxclack]

Thanks for your suggestions! Maybe we can improve our implementation later.
BTW, such ''no longer uniform'' phenomenon is caused by the implementation of np.random.randint ?

[YongGuCheng]

Thanks for your suggestions! Maybe we can improve our implementation later. BTW, such ''no longer uniform'' phenomenon is caused by the implementation of np.random.randint ?

Due to the confinement of "low=0".
For example, maybe use "np.random.randint(low=-self.mod_number, high=self.mod_number, size=shape)", and "np.random.randint(low=-2*self.mod_number, high=2*self.mod_number, size=shape)", etc.

[xieyxclack]

Got it. I have misunderstood the ''confine'' (refer to the high=mod_number) before.
Thanks again for your comments :)

[YongGuCheng]

Got it. I have misunderstood the ''confine'' (refer to the high=mod_number) before. Thanks again for your comments :)

You are more than welcome.
For "high=self.mod_number", it is fine, since we need a "high end (range)" anyway in practical implementations.

[tanjuntao]

都是国人，非要用英文来交流吗🤣