Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Migrate discrete mechanisms from internal accounting utilities to dp_accounting

Open
#118 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
security

Research direction

Start by tracing the remaining usages from dpsynth/discrete_mechanisms into the internal accounting.py module, then compare the relevant event and conversion APIs in dp_accounting, including RdpAccountant. Run or add equivalence tests for zCDP and GDP conversions where applicable; done requires a confirmed migration path or documented reasons for helpers that must remain local.

Written by the indexing model from the issue text.

Description

dpsynth/discrete_mechanisms currently relies on the internal accounting.py module, which is intended to be deprecated by dp_accounting

I looked into the remaining usages to understand whether the discrete mechanisms could be migrated.
There appear to be direct equivalents for the event representation:

  • ZCDpEvent(rho) → dp_accounting.dp_event.ZCDpEvent(rho)
  • ComposedDpEvent → dp_accounting.dp_event.ComposedDpEvent

dp_accounting also explicitly uses the same Gaussian/zCDP relationship when handling a ZCDpEvent with xi == 0:

noise_multiplier = 1 / sqrt(2 * rho)

which is mathematically equivalent to the current zcdp_gaussian_sigma() implementation:
sqrt(0.5 / rho).

The remaining helpers in the internal module include conversions/calibration such as zcdp_eps, zcdp_delta, zcdp_rho, zcdp_exponential_eps, and the GDP helpers. Some may be replaceable through RdpAccountant (get_epsilon/get_delta), while others appear to be simple mechanism-calibration formulas that may need to remain local.

Before working on the migration, I wanted to check whether there are known numerical or semantic differences between the existing zCDP accounting implementation and dp_accounting, or another reason the discrete mechanisms have intentionally remained on the internal accounting utilities.

If migration is the intended direction, I'm interested in working on it and can first add equivalence tests for the relevant conversions.

Dominant language
Python
Stars
32
Forks
13
Avg merge
1d 19h
Merged PRs (30d)
20

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/dpsynth

All issues in google/dpsynth

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.