Home

Conventionally, Differentially Private ML training relies on Gradient Clipping to guarantee verifiable privacy guarantees. By using 1-Lipschitz networks developped by the deel-lip project. We can propose a new alternative to gradient clipping based DP ML. Indeed, by theoretically bounding the value of the sensitivity of our 1-Lipschitz layers, we can directly calibrate a batchwise noising of the gradients to guarantee (epsilon,delta)-DP.
π Table of contents¶
- π Table of contents
- π₯ Tutorials
- π Quick Start
- π¦ What's Included
- π Contributing
- π See Also
- π Acknowledgments
- π¨βπ Creator
- ποΈ Citation
- π License
π₯ Tutorials¶
π Quick Start¶
Libname requires some stuff and several libraries including Numpy. Installation can be done using Pypi:
pip install dist/lipdp-0.0.1a0-py2.py3-none-any.whl[dev]
Now that lipdp is installed, here are some basic examples of what you can do with the available modules.
π¦ What's Included¶
Code can be found in the lipdp
folder, the documentation ca be found by running
mkdocs build
and mkdocs serve
(or loading site/index.html
). Experiments were
done using the code in the experiments
folder.
π Contributing¶
Feel free to propose your ideas or come and contribute with us on the Libname toolbox! We have a specific document where we describe in a simple way how to make your first pull request: just here.
pre-commit : Conventional Commits 1.0.0¶
The commit message should be structured as follows:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
The commit contains the following structural elements, to communicate intent to the consumers of your library:
-
fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
-
feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
-
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
-
types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
-
footers other than BREAKING CHANGE:
may be provided and follow a convention similar to git trailer format. -
Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commitβs type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
π Acknowledgments¶
π¨βπ Creators¶
If you want to highlights the main contributors
ποΈ Citation¶
π License¶
The package is released under MIT license.