Closed dartdart26 closed 1 week ago
@immortal-tofu Should we pass the number of bits or the upperBalue? If it is upperBound, it would instead be 1, 3, 7, 15, 31 and so on to pass as upperBound, because 0 is always included.
The other alternative would be to pass number of bits, i.e. 1, 2, 3, 4, 5, 6, 7 and 8.
We had this discussion with @mortendahl and it seems to him more logic to have 2/4/8/16. He refers to some implementation in Rust https://rust-random.github.io/rand/rand/distributions/struct.Uniform.html
Cool, I will explain the behaviour in the function doc and state it is not inclusive.
It will fail if the upper bound is not a power of 2, will explain that too.
It seems that non-power-of-2 uniform sampling could happen in the near future (at some performance price)
@mortendahl do you think we should allow any bound for the mock? It would be easily doable now. I guess the question is if we want to expose non-power-of-2 in a separate API call to cater for an explicit higher price for the FHE version.
Good question. I'd say we should keep power of 2 and we'll see later for uniform randomness.
I agree we can keep power-of-2.
Btw, I've added upperBound for 16 bit and 32 bit random generation too, maybe the FHE version becomes impractical for such types, not sure of the implementation.
Implementation would be something like
TFHE.randEuint8(uint8 upperBound)
with valid values 2/4/8/16/...:TFHE.randEuint8(2); // Value between 0 and 1
TFHE.randEuint8(4); // Value between 0 and 3
TFHE.randEuint8(8); // Value between 0 and 7
TFHE.randEuint8(16); // Value between 0 and 15
...