Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GaussianSampler #21

Merged
merged 11 commits into from
Feb 24, 2024
Merged

Add GaussianSampler #21

merged 11 commits into from
Feb 24, 2024

Conversation

enricobottazzi
Copy link

@enricobottazzi enricobottazzi commented Feb 14, 2024

The PR contains a simple GaussianSampler. This adopts an approach similar to the one implemented by lattigo.

There's no integration with any other part of the codebase. Opened it as a draft PR to ask you a review on the current implementation and further guidance on how to better integrate it into the rest of the codebase.

@enricobottazzi
Copy link
Author

@enricobottazzi enricobottazzi changed the base branch from main to dev February 19, 2024 10:28
@Janmajayamall Janmajayamall marked this pull request as ready for review February 19, 2024 14:04
/// In particular, `sampled_val` is sampled from a normal distribution with mean 0 and standard deviation `sigma`.
/// If `sampled_val` is within the bounds, it is rounded and returned.
pub fn sample(&mut self) -> i64 {
let discrete_normal = Normal::new(0.0, self.params.sigma).unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is new as no op?

If not then we should avoid creating new for each sample?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep. Good point

pub fn sample(&mut self) -> i64 {
let discrete_normal = Normal::new(0.0, self.params.sigma).unwrap();
let sampled_val = discrete_normal.sample(&mut self.rng);
if sampled_val.abs() < self.params.bound as f64 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the check and the recursive call because it guarantees that sample is within $6\sigma$ with 100% probability, which leaks information and is insecure.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But shouldn't it be the case? Or in other words, wouldn't it be a problem if the sample is not within the bounds?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there will be any problem. Value will be $&gt; 6\sigma$ with very small probability and will not have much effect on noise growth.

Moreover, we aren't shooting for tight bounds at present so bounding seems unnecessary.

}

#[cfg(test)]
mod tests {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need tests here if rand_distr already has tests?

Copy link
Author

@enricobottazzi enricobottazzi Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably the second and third test can be removed. What makes this implementation different from the standard rand_distr is that it is Discrete and Bounded. So probably test 1 should be maintained, but I'm sure that this is the required behavior given your previous comment

Remove the check and the recursive call because it guarantees that sample is within 6σ with 100% probability, which leaks information and is insecure.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah but the discretised value is dependent on sample returned by rand_distr API. We have no control over it, so why are we testing it ?

@Janmajayamall
Copy link
Collaborator

Since we don't add anything on top of rand_distr should we move this directly inside DefaultU64SeededRandomGenerator here ? What do you think?

@enricobottazzi
Copy link
Author

Since we don't add anything on top of rand_distr should we move this directly inside DefaultU64SeededRandomGenerator here ? What do you think?

Yes I think so. Just wanted to check your reply to the previous comments before moving it.

@Janmajayamall
Copy link
Collaborator

commit fixes random_fill in RandomGaussianDist. We hardcode mean to 0 and std_dev to 3.2.

@Janmajayamall Janmajayamall merged commit 51d04d8 into dev Feb 24, 2024
2 checks passed
@Janmajayamall Janmajayamall deleted the enrico-14-gaussian-sampling branch February 24, 2024 06:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants