You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
af761ba added "MixtureGaussianPrivacyLoss" to dp_accounting/pld/privacy_loss_mechanism.py, which enables privacy accounting for mechanisms that are dominated by a single Gaussian and a mixture of Gaussians.
For certain use cases, it might be nice to generalize this to mechanisms dominated by two mixture of Gaussians, each with different mixture weights and means/sensitivities.
For instance, such a "DoubleMixtureGaussianPrivacyLoss" can be used for efficient (albeit non-tight) accounting when considering substitutions of records, see Sections 6.2 & 6.3 in https://proceedings.mlr.press/v108/koskela20b.html.
It is also needed for tight accounting of group privacy under insertion/removal, see Theorem 3.8 in https://arxiv.org/abs/2403.04867.
Thanks for offering to contribute! We would be interested in adding your accounting code, please go ahead and submit a PR when you feel the code is ready.
To anticipate some feedback on that PR - it seems like both DoubleMixtureLaplacePrivacyLoss and DoubleMixtureGaussianPrivacyLoss reuse many methods from MixtureGaussianPrivacyLoss - do you think it's possible to, as part of your cleanup, inherit these methods instead (e.g. from a new abstract class that all three could inherit the shared methods from)? This will make it easier to maintain the new code on our end after the PR is accepted :)
Hi,
af761ba added "MixtureGaussianPrivacyLoss" to
dp_accounting/pld/privacy_loss_mechanism.py
, which enables privacy accounting for mechanisms that are dominated by a single Gaussian and a mixture of Gaussians.For certain use cases, it might be nice to generalize this to mechanisms dominated by two mixture of Gaussians, each with different mixture weights and means/sensitivities.
For instance, such a "DoubleMixtureGaussianPrivacyLoss" can be used for efficient (albeit non-tight) accounting when considering substitutions of records, see Sections 6.2 & 6.3 in https://proceedings.mlr.press/v108/koskela20b.html.
It is also needed for tight accounting of group privacy under insertion/removal, see Theorem 3.8 in https://arxiv.org/abs/2403.04867.
I already had to implement this for my last project, see https://github.com/jan-schuchardt/group_amplification/blob/master/group_amplification/privacy_analysis/composition/pld/accounting.py.
So if you'd like, I could clean my code up a bit and create a pull request.
Let me know if you think that this would be useful addition :)
The text was updated successfully, but these errors were encountered: