delvtech / hyperdrive-rs

Rust SDK for the Hyperdrive AMM.
https://docs.rs/crate/hyperdrive-math/latest
Apache License 2.0
2 stars 0 forks source link

update sdk docstrings for consistency of variables used #36

Open dpaiton opened 4 months ago

dpaiton commented 4 months ago

We sometimes use equation letters for multiple purposes, which can lead to confusion. For example, in the docstring for short::open::calculate_open_short we say:

    /// $x$ is the number of bonds being shorted and $P(x)$ is the amount of
    /// shares the curve says the LPs need to pay the shorts (i.e. the LP
    /// principal).

p is "spot price" or "price" nearly everywhere else; we shouldn't use it for the lp principal.

We use x for generic "input variable" some times in the docs, but then elsewhere specifically mean "base amount". And when we say \Delta x we always mean "change in base". We should avoid using it as a generic variable, and we should especially not use it to mean anything to do with "bonds".

\Delta x, $\Delta x$, and \Delta y, $\Delta y$, are also used sometimes to represent "[base or bond] token coming from a user's wallet into the pool" and also to represent "[base or bond] token removed from the pool". Because of fees, these two quantities are not equal. To avoid confusion, we should clearly delineate when we are talking about pool reserves (e.g. \Delta y_{\text{pool}}, $\Delta y_{\text{pool}}$, or the "in" vs "out" syntax that we use elsewhere) vs user funds.

dpaiton commented 4 months ago

We should also investigate standardizing when we use tfrac vs frac. e.g. if the numerator & denominator have fewer than 3 symbols then we use frac? This might not be possible to use a hard rule, though. When the fractions are nested then we are usually forced to use tfrac to keep the font size reasonable.

dpaiton commented 4 months ago

We also occasionally use k(x), which should be k since the fn has no dependent arguments.