mirror of
https://github.com/luxfi/torus-ml.git
synced 2026-10-30 15:15:23 +00:00
zeekay
e037e8f7ea
The distribution called itself torus-ml while shipping a package directory named concrete, so the name a user installs and the name they import disagreed — and most of the tree already said torus.ml, which could not resolve against src/concrete. Moved src/concrete to src/torus and pointed the include at it. The dependency was Zama's concrete-python from their index. It is torus-fhe from ours, which is what luxfhe/torus already ships: that frontend declares torus-fhe and ships a torus/fhe module, so every 'from torus.fhe' in this tree was already naming our compiler and only the dependency lagged. Two distributions share one namespace, which is the shape the upstream this forked from used and the reason the split works: torus-fhe gives torus.fhe, torus-ml gives torus.ml. Swept every other spelling — identifiers, enum members, workflow variables, filenames, notebooks. LICENSE and NOTICE keep the upstream attribution a fork owes; the figures carry the old name in JPEG metadata a text sweep cannot reach.
2.0 KiB
2.0 KiB
Conventions
The only place we can say we/our is in a blog post written by a named author. Anything signed Lux should not use we/our. So, no "We" or "Our" in our documentation.
Let's use following conventions for the docs. If a new convention needs to be decided, let's agree and then add it here.
Style
- The documentation can address the user directly e.g., "you can find out more at ..", but this style should not be abused, do not be too colloquial !
- The documentation should not refer to its writers or to Torus ML developers/Lux as "we", and thus it should not use "our" either.
Terms
- Use hyphenated versions for portmanteaus, unless the term is in the dictionary, example:
- bit-width [not: bitwidth, bit width]
- input-set, data-set
- database, codebase is fine (not data-base, code-base)
- de-quantize/re-quantize
- "an FHE program" not "a FHE program"
- Machine Learning or machine learning, depends on the context
- google is a verb ("you can google" but not "you can Google") : but try to avoid this
- Programs:
- Jupyter
- Torus ML (no Torus ML)
- pytest except when title where it is capitalized
- Python
- torch (for the code) and PyTorch (for the product)
- scikit, sklearn and scikit-learn are acceptable
- Hummingbird
- Docker (for the product) or docker (for the binary)
- Poetry (for the product) or poetry (for the binary)
- Make (for the product) or make (for the command line)
- PoissonRegression or Poisson Regression (depends on the context, we'll fix it in Lux)
- macOS
- bare OS
Variables
- Variables names should use ticks:
variable_nameorvariable_name=10.5 - If a number is just stated, not in a code block, then it's just 10.5 not
10.5.
Titles
- Main titles (with a single #) are
Capitalized at Each Letter - Sub titles (with two or more #s) are
Capitalized only for first letter
Links
- Use links from doc root (i.e., ../../user/explanation/quantization.md) instead of using the smallest number of ../ that works; it makes files easier to move