Integrated the random allocation directory#414
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
arung54
left a comment
There was a problem hiding this comment.
Hi Moshe,
No comments on the logic / implementation. Most of these comments are about style (and stuff that we will probably have to address anyway to pass the style checks) which are hopefully easy to fix. Some of these could have been prevented if I shared our style guide in advance, apologies for only pointing you to it during the review! If you haven't already, I'd also suggest fixing any issues raised by:
$ flake8 random_allocation/*.py
$ pyink random_allocation/*.py
$ pydocstyle --convention=google --add-ignore=D101,D102,D103,D105,D202,D402 random_allocation/*.py
$ pylint random_allocation/*.py
$ pytype random_allocation/*.py -k
Some top-level comments:
- Since this library is already in a folder named 'random_allocation', consider renaming some of the libraries to be shorter (e.g. from 'random_allocation_convolution' to 'convolution') for brevity.
- See https://google.github.io/styleguide/pyguide.html#22-imports - a lot of these libraries are importing methods, whereas the style guide suggests importing modules and then calling the method from the package name. Renaming to shorter module names might help with doing this while maintaining brevity.
- For the test files, can you match the style of the other test files in dp_accounting here?:
- Use absltest instead of pytest
- Prefer absltest.TestCase or numpy.testing assertions over assert ..., since these will give more verbose failures.
- Put "Test" at the end of test class names rather than beginning
|
A few minor comments |
|
|
|
Thank you.
I'm in the midst of going over all the comments and ensuring they are all
resolved.
…On Sun, 7 Jun 2026 at 18:13, Ryan McKenna ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In
python/dp_accounting/dp_accounting/pld/random_allocation/random_allocation_convolution.py
<#414 (comment)>
:
> + fft1 = rfft(dist_1.prob_arr, n=fft_size)
+ if is_self_convolve:
+ fft1 *= fft1 # in-place square
+ else:
+ fft2 = rfft(dist_2.prob_arr, n=fft_size)
+ fft1 *= fft2 # in-place multiply
+ del fft2 # free second complex buffer immediately
+ conv_full = irfft(fft1, n=fft_size, overwrite_x=True)
+ del fft1 # free complex buffer
+ conv_pmf = conv_full[:conv_full_len].copy() # copy needed portion
+ del conv_full # free full irfft output
+
+ # Zero negative roundoff and ghost mass outside reachable support
+ conv_pmf[conv_pmf < 0] = 0.0
+ conv_pmf[:min_idx] = 0.0
+ max_idx_plus_one = max_idx + 1
Can probably inline max_idx+1 rather than giving it a name
------------------------------
In
python/dp_accounting/dp_accounting/pld/random_allocation/random_allocation_convolution.py
<#414 (comment)>
:
> + fft2 = rfft(dist_2.prob_arr, n=fft_size)
+ fft1 *= fft2 # in-place multiply
+ del fft2 # free second complex buffer immediately
+ conv_full = irfft(fft1, n=fft_size, overwrite_x=True)
+ del fft1 # free complex buffer
+ conv_pmf = conv_full[:conv_full_len].copy() # copy needed portion
+ del conv_full # free full irfft output
+
+ # Zero negative roundoff and ghost mass outside reachable support
+ conv_pmf[conv_pmf < 0] = 0.0
+ conv_pmf[:min_idx] = 0.0
+ max_idx_plus_one = max_idx + 1
+ if max_idx_plus_one < conv_pmf.size:
+ conv_pmf[max_idx_plus_one:] = 0.0
+
+ current_finite_mass = math.fsum(map(float, conv_pmf))
I see this pattern also above, what's the benefit of this compared to
np.sum(conv_pmf)? Can you add an inline comment?
------------------------------
In
python/dp_accounting/dp_accounting/pld/random_allocation/random_allocation_convolution.py
<#414 (comment)>
:
> + if zero_prob == 0.0:
+ return pmf_conv
+
+ return _numba_add_single_zero_atom_cross_term(
+ pmf_out=pmf_conv,
+ x_vals=np.asarray(x_arr, dtype=np.float64),
+ prob_arr=np.asarray(prob_arr, dtype=np.float64),
+ zero_prob=float(zero_prob),
+ x_out_0=float(x_out_0),
+ log_r=float(geom_step),
+ dominates=(bound_type == BoundType.DOMINATES),
+ )
+
+
***@***.***(cache=True)
+def _numba_add_single_zero_atom_cross_term(
Numba is a large dependency that I believe dp_accounting doesn't currently
have. Can this be written efficiently in plain numpy? If it's needed for
performance reasons we can keep it, but figured I'd ask since it looks like
a pretty simple function to vectorize efficiently.
1. If pure numpy can be nearly yas efficient, prefer that.
2. If not, then prefer treating numba as an optional dependency of
dp_accounting. If it's installed, use this codepath, otherwise use a
(vectorized) numpy codepath, and include a "Performance Warning" that users
should install numba if using this code. Would be good to include test
coverage that the two code paths match in that case.
------------------------------
In python/dp_accounting/dp_accounting/dp_event.py
<#414 (comment)>
:
> @@ -494,3 +494,23 @@ class TruncatedSubsampledGaussianDpEvent(DpEvent):
sampling_probability: float
truncated_batch_size: int
noise_multiplier: float
+
+
***@***.***(frozen=True, slots=True, auto_attribs=True)
+class RandomAllocationDpEvent(DpEvent):
+ """Represents the random-allocation mechanism.
+
+ In this event, each element in the dataset is independently allocated to k
+ uniformly sampled calls to the mechanism out of t total calls.
+
+ Currently only GaussianDpEvent is supported as the inner event.
+
+ Attributes:
+ event: The DpEvent for each call to the mechanism (e.g., GaussianDpEvent).
+ k: Number of calls each element participates in.
For the public API it might be worth giving k and t slightly more
descriptive names. But if k/t matches the notation used in the paper, then
I could see an argument for keeping it as is, so consider this optional.
—
Reply to this email directly, view it on GitHub
<#414?email_source=notifications&email_token=AA5FNSXFANUU6FVHGNT7QC346XSHLA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMRQHA4DQNBYHAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4208884882>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5FNSQYOEREQKEFFLKKWOD46XSHLAVCNFSM6AAAAACYMYRXYCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DEMBYHA4DIOBYGI>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AA5FNSX57TLMGEFIHYQWHXL46XSHLA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMRQHA4DQNBYHAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/AA5FNSXHZPOV37AOUEFL5KD46XSHLA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMRQHA4DQNBYHAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
- Rename RandomAllocationDpEvent.k/.t to .num_selected/.num_steps (r3170917978). - Add arxiv paper reference to the docstring (r3171223123). - Remove ra_event alias in PLDAccountant._maybe_compose (r3170942975). - Add test_random_allocation_basic to pld_privacy_accountant_test.py (r3170933999). - Remove test_random_allocation_event_has_no_discretization_override (r3198173993). Instead, renamed AllocationSchemeConfig.loss_discretization to .value_discretization_interval for consistency with PLDAccountant's existing _value_discretization_interval.
Add soft-import guard (_HAS_NUMBA / _optional_njit() / has_numba()) in random_allocation_types.py and replace all @njit(cache=True) decorators with @_optional_njit(), so the package loads and runs without numba installed (r3198378368, r3228974300). For the two performance-critical kernels (_numba_geometric_kernel, _numba_rediscretize_prob) add pure-NumPy fallbacks and dispatch via has_numba() at call time. _add_single_zero_atom_cross_term is fully vectorised with np.add.at, removing its hard numba dependency. Add parity and fallback-dispatch tests for all three paths (r3171209246).
Convert all intra-package imports from relative to absolute module-level imports (dp_accounting.pld.random_allocation.module), and call internal helpers via module._fn() rather than importing them by name — matching the project's Google-style import convention (r4208613559 import bullet).
Add _ prefix to all implementation-only symbols across random_allocation_{types,distributions,utils,convolution,core}, so the public API is limited to the names in __init__.__all__ (r3229395649, part of r3229486152).
- Add paper link to algorithm docstrings (r3230294534, r3230302356, r3230234883, r3230282798, r3230097765, r3229713035). - Add Attributes: sections to classes (r3229028609, r3229277278, r3229347201). - Add inline comment explaining why math.fsum is preferred over np.sum for numerical stability (r3171163734). - Rewrite mass-conservation ValueError (r3228994798, r3228999157). - Inline trivial max_idx_plus_one temporary variable (r3171158087). - Introduce assertion helpers in random_allocation_utils, replacing ad-hoc isinstance blocks (r3230280947, r3230069168). - Remove post-convolution return-value check of _binary_self_convolve which is verified by pytype and is an overkill (r3230081238) - Remove stale comment from truncate_edges docstring (r3229005737). - Add del max_ind # Unused. style comment (r3229414402). - Fix typos: "distributsion" -> "distribution" (r3228981292), "TestDiscritizeRange" -> "TestDiscretizeRange" (r3229767210).
- Change branches to always use elif/else validation (r3229336820, r3229342023, r3229407683). - Rename continuous-discretization helper and clarify its docstring (r3229679129). - Rename lowercase variables and test alias (r3229709372, r3229794562). - Use x_0 notation in discretization comments and remove the stale docstring blank line (r3229702549, r3229736292). - Switch random-allocation tests to module imports instead of direct functions import (r4208613559 import bullet). - Run pyink over the random-allocation package and close flake8, pydocstyle, and pytype gaps found during audit (r4208613559 style-check request).P
- Replace pytest assertions and free functions with absltest.TestCase classes, numpy.testing assertions, and Test-suffixed class names to match the rest of dp_accounting. - Add absltest.main() for module execution. Resolves top-level review comment 4208613559 test-style bullets.
- Reorder functions in ra_distributions, ra_convolution, and ra_utils so that every helper is defined before the first call site that uses it, matching the project's internal style (all reviewer ordering comments). - Rename _assert_dense_linear_dist and _assert_dense_geometric_dist to _validate_dense_linear_dist and _validate_dense_geometric_dist to match the _validate_* naming convention used by all other guard helpers in ra_utils.
…e pylint warning
- Place third-party numpy/scipy imports above first-party dp_accounting.
- Fix line-too-long violations.
- Add missing property docstrings.
- Add # pylint: disable=invalid-name on every T: int parameter (3230066401).
- Apply pyink reformatting.
Verified with:
- flake8 dp_accounting/pld/random_allocation --max-line-length=100 -> clean
- pyink --check dp_accounting/pld/random_allocation -> clean
- pydocstyle --convention=google ... dp_accounting/pld/random_allocation -> clean
- pylint dp_accounting/pld/random_allocation/ --ignore=*_test.py -> 9.06/10
- pytest ra_{api,distributions,convolution}_test.py -> 56 passed
… comments - Replace get_x_array/x_array distribution API with private _x_array access - Store sparse support in _x_arr and keep dense support derived from RegularGrid - Use shared dense-linear validation in dp_accounting PMF conversion - Use copy.deepcopy for rediscretization working distributions
…names - Replace 9 inline DenseDiscreteDist spacing guards in ra_core with the _validate_dense_linear_dist/_validate_dense_geometric_dist helpers (3230280947). - Import pld_pmf and common as modules rather than individual symbols. - Strip leaked ra_*. prefixes from error messages, docstrings, and comments.
- Run pyink with --pyink-indentation 2 --line-length 80 to match the dp_accounting code style (files were 4-space).
- git mv ra_*.py -> *.py (api, convolution, core, distributions, utils, and their tests). - Rename ra_types.py -> definitions.py (not types.py) to avoid shadowing the stdlib `types` module. - Update all intra-package imports and qualified references (ra_* -> *) across the package.
There was a problem hiding this comment.
Hi Moshe,
Overall looks good. One minor comment below. In addition, I think the linter will complain if you are accessing protected methods from other classes (unless you are in a test class accessing a protected method from the tested class). I think the 'public API' methods in api.py / core.py are the main culprits for where the linter would complain.
Also, I think we will need to add a BUILD.bazel (similar to https://github.com/google/differential-privacy/blob/main/python/dp_accounting/dp_accounting/BUILD.bazel) to this folder, and update the BUILD.bazel in the parent folder. For the most part it should be pattern-matchable (also happy to help you with writing it), but since we are adding a numba dependency that may introduce some complications. Let me chat w/ other folks on our team at the right way to add numba (since right now it's not in the pip deps) and get back to you.
| from dp_accounting import privacy_accountant | ||
| from dp_accounting.pld import common | ||
| from dp_accounting.pld import privacy_loss_distribution | ||
| from dp_accounting.pld import random_allocation as _random_allocation |
There was a problem hiding this comment.
Just for consistency, I think it's fine to import without 'as _random_allocation'
- Drop the `_random_allocation` import alias in pld_privacy_accountant.py - Fix pylint protected-access (W0212) in production code: de-underscore the helper functions that are called across modules within the package. Test-only internals keep their underscores. - Make the DiscreteDist `x_array` property public (was `_x_array`). - Rename the invalid-name `_st` locals in utils.py to `spacing`. - Add random_allocation/BUILD.bazel (per-file py_library + py_test targets) and depend on it from pld/BUILD.bazel's pld_privacy_accountant target.
|
I think I fixed the remaining issues.
Before you check the changes, I just want to make sure I got the rules
right this time.
In the last round you had this comment
<#414 (comment)>
about Grid Spacing Utilities where you asked if these functions are "used
outside this library" and recommended making them private if not.
I took the "outside this library" to mean that if a method is called from a
different file inside the RA directory, it should start with an underscore,
but it seems like I've overdone it.
If I understand correctly, the right format for such functions is - remove
underscore but exclude from init. If the function is used only within the
same file, then it should start with underscore.
Did I get it this time?
Also, I hope I got the bazel style right. Please let me know if I missed
something.
Thanks
Moshe
…On Thu, 25 Jun 2026 at 22:46, arung54 ***@***.***> wrote:
***@***.**** commented on this pull request.
Hi Moshe,
Overall looks good. One minor comment below. In addition, I think the
linter will complain if you are accessing protected methods from other
classes (unless you are in a test class accessing a protected method from
the tested class). I think api.py / core.py are the main culprits for where
the linter would complain.
Also, I think we will need to add a BUILD.bazel (similar to
https://github.com/google/differential-privacy/blob/main/python/dp_accounting/dp_accounting/BUILD.bazel)
to this folder, and update the BUILD.bazel in the parent folder. For the
most part it should be pattern-matchable (also happy to help you with
writing it), but since we are adding a numba dependency that may introduce
some complications. Let me chat w/ other folks on our team at the right way
to add numba (since right now it's not in the pip deps) and get back to you.
------------------------------
In python/dp_accounting/dp_accounting/pld/pld_privacy_accountant.py
<#414 (comment)>
:
> @@ -23,6 +23,7 @@
from dp_accounting import privacy_accountant
from dp_accounting.pld import common
from dp_accounting.pld import privacy_loss_distribution
+from dp_accounting.pld import random_allocation as _random_allocation
Just for consistency, I think it's fine to import without 'as
_random_allocation'
—
Reply to this email directly, view it on GitHub
<#414?email_source=notifications&email_token=AA5FNSTPZXFBGDGRJKRCRMD5BV6RFA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJXGQYDKMZWGE2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4574053614>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5FNSRSR3W7KDXHBBSU3JL5BV6RFAVCNFSNUABFKJSXA33TNF2G64TZHMZDANRTGIYDSMZYHNEXG43VMU5TIMZWGEZDMNJWGIYKC5QC>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AA5FNSTLNVLCKLDHNR4A2ZL5BV6RFA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJXGQYDKMZWGE2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/AA5FNSTYKLU2JQRWDHNTQJD5BV6RFA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJXGQYDKMZWGE2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Sorry for the lack of clarity earlier! Yes, if a method in foo.py is only used in foo.py (and maybe foo_test.py) it should start with underscore. If it is used in bar.py in the same folder, the linter will complain if it starts with an underscore, which we need to avoid to pass style checks. And yes, if it is only used within the same folder, not including it in the init is good. Thanks for your patience with the comments, at this point I think it's looking good generally. Let me check internally the right way to get numba added as a dependency, then I might suggest a change to one of the BUILD.bazels and then we are probably good to go to internal approval, which we can hopefully make fast. I will be OOO for the next few days due to the US holiday, but will try to check back in soon. |
|
In this case, I think the delivered code matches your instructions.
I also checked the possibility of removing numba, which I discussed in a
separate thread.
Moshe
…On Wed, 1 Jul 2026 at 00:24, arung54 ***@***.***> wrote:
*arung54* left a comment (google/differential-privacy#414)
<#414 (comment)>
Sorry for the lack of clarity earlier! Yes, if a method in foo.py is only
used in foo.py (and maybe foo_test.py) it should start with underscore. If
it is used in bar.py in the same folder, the linter will complain if it
starts with an underscore. And yes, if it is only used within the same
folder, not including it in the init is enough to privatize.
Thanks for your patience with the comments, at this point I think it's
looking good generally. Let me check internally the right way to get numba
added as a dependency, then I might suggest a change to one of the
BUILD.bazels and then we are probably good to go to internal approval,
which we can hopefully make fast. I will be OOO for the next few days due
to the US holiday, but will try to check back in soon.
—
Reply to this email directly, view it on GitHub
<#414?email_source=notifications&email_token=AA5FNSVDYWMADS4KCM6UMMD5CQV2VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUHAYDIMJUGMY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4848041431>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5FNSQHVYVFPHGYJZEUAVT5CQV2VAVCNFSNUABFKJSXA33TNF2G64TZHMZDANRTGIYDSMZYHNEXG43VMU5TIMZWGEZDMNJWGIYKC5QC>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AA5FNSUC4TKHV6ONJRS2AVD5CQV2VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUHAYDIMJUGMY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/AA5FNSXEO47BNS7WV24OIIL5CQV2VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUHAYDIMJUGMY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
…tations that are practically identical accuracy-wise and <= X2 slower.
|
Hi Moshe, Thanks for the updates! I think to migrate this into an internal PR we need to resolve the merge conflicts? Otherwise I will try to keep things moving on our end once that's done. |
|
I'm either missing something or don't have the required permissions to see
them.
I can see the "This branch has conflicts that must be resolved" message but
cannot click the "resolve conflicts" button, and didn't find any other way
to see those conflicts.
…On Fri, 10 Jul 2026 at 00:57, arung54 ***@***.***> wrote:
*arung54* left a comment (google/differential-privacy#414)
<#414 (comment)>
Hi Moshe,
Thanks for the updates! I think to migrate this into an internal PR we
need to resolve the merge conflicts? Otherwise I will try to keep things
moving on our end once that's done.
—
Reply to this email directly, view it on GitHub
<#414?email_source=notifications&email_token=AA5FNSXYHWOZLRD5545GRWT5EAILXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJSHE4TAOJWG432M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4929909677>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5FNSURVSGDXRLZBEAESWT5EAILXAVCNFSNUABFKJSXA33TNF2G64TZHMZDANRTGIYDSMZYHNEXG43VMU5TIMZWGEZDMNJWGIYKC5QC>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AA5FNSRN6OVYPGIAFYRSY4D5EAILXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJSHE4TAOJWG432M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/AA5FNSUE6UEA52IOYOJDNJT5EAILXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJSHE4TAOJWG432M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Got it, I'll ask someone on our side who's more familiar with the OSS process for how to proceed then! |
|
I'm not 100% sure, but one thing that might be happening is if the resolution of conflicts is non-trivial, you can't do it in the web interface, but you have to do it manually via the command line w/ git. I actually don't have a ton of experience with this, but I believe if you "git pull" it will sync to latest version at head and you will be forced to resolve merge conflicts before proceeding |
|
Locally I don't see any indication of a conflict.
I'm seemingly fully synced with the remote version.
Is it possible I'm in the wrong branch or something similar, or perhaps
it's something only someone from within the organization can view?
…On Sat, 11 Jul 2026 at 00:14, Ryan McKenna ***@***.***> wrote:
*ryan112358* left a comment (google/differential-privacy#414)
<#414 (comment)>
I'm not 100% sure, but one thing that might be happening is if the
resolution of conflicts is non-trivial, you can't do it in the web
interface, but you have to do it manually via the command line w/ git. I
actually don't have a ton of experience with this, but I believe if you
"git pull" it will sync to latest version at head and you will be forced to
resolve merge conflicts before proceeding
—
Reply to this email directly, view it on GitHub
<#414?email_source=notifications&email_token=AA5FNSQYURLESUWGZMXTWK35EFMD3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHE2TSMJQGQ2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4939591044>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5FNSQLWZANBGDNFFW4YHL5EFMD3AVCNFSNUABFKJSXA33TNF2G64TZHMZDANRTGIYDSMZYHNEXG43VMU5TIMZWGEZDMNJWGIYKC5QC>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AA5FNSS3SDDRYGZ6Q6H7WHD5EFMD3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHE2TSMJQGQ2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/AA5FNSXQXKTPUBYWMVO7PDT5EFMD3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHE2TSMJQGQ2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Can you try following these steps? |
Added a new pld/random_allocation package which implements the accounting algorithm proposed in "Efficient privacy loss accounting for subsampling and random allocation".
It contains public builders for Gaussian and explicit-realization random allocation PLDs in random_allocation_api.py.
It also wires the feature into dp_accounting as RandomAllocationDpEvent in dp_event.py, and makes PLDAccountant handle Gaussian inner events in pld_privacy_accountant.py.