fix: make prv accountant robust to larger epsilons #606
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Types of changes
Motivation and Context / Related issue
Hi,
this PR fixes #601 and #604.
It will introduce the same fix as in microsoft/prv_accountant#38. Lukas (author of prv accountant, @wulu473) said that
In general, adding any additional points is safe and won't affect the robustness negatively.
The cause of these errors seems to be the grid for computing the
mean()
function of thePrivacyRandomVariableTruncated
class. The grid (points
variable) used to compute the mean is constant apart from the lowest (self.t_min
) and highest point (self.t_max
).This PR determines the grid (
points
variable) based on the lowest and highest point. More information is below.Best
Observation
I debugged the code and arrived at some point at the
mean()
function of thePrivacyRandomVariableTruncated
class. The grid (points
variable) used to compute the mean is constant apart from the lowest (self.t_min
) and highest point (self.t_max
). See the line of code here. It looks like this[self.tmin, -0.1, -0.01, -0.001, -0.0001, -1e-05, 1e-05, 0.0001, 0.001, 0.01, 0.1, self.tmax]
.It seems that the
tmin
andtmax
are of the order of[-12,12]
for the examples that I posted above and even up to[-48,48]
for the example that @jeandut posted in the #604 issue whereas they are more like[-7,7]
for the readme example for DP-SGD.We suspect that the integration breaks down when the gridspacing between between
tmin
/tmax
get's too large.Proposed solution
Determine the points grid based on
tmin
andtmax
but determines the start and end of the logspace based ontmin
andtmax
.Before: (
opacus/opacus/accountants/analysis/prv/prvs.py
Lines 99 to 106 in 95df090
After:
How Has This Been Tested (if it applies)
I ran the examples from the issues #601 and #604 and they don't break anymore.
Checklist
Not able to run all tests locally and unsure if new tests should be added.