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.
dpsynth/discrete_mechanismscurrently relies on the internalaccounting.pymodule, which is intended to be deprecated bydp_accountingI looked into the remaining usages to understand whether the discrete mechanisms could be migrated.
There appear to be direct equivalents for the event representation:
dp_accountingalso explicitly uses the same Gaussian/zCDP relationship when handling aZCDpEventwithxi == 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.