Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update sdk docstrings for consistency of variables used #36

Open
dpaiton opened this issue Apr 12, 2024 · 2 comments
Open

update sdk docstrings for consistency of variables used #36

dpaiton opened this issue Apr 12, 2024 · 2 comments
Labels
documentation Improvements or additions to documentation good first issue Good for newcomers

Comments

@dpaiton
Copy link
Member

dpaiton commented Apr 12, 2024

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 dpaiton added documentation Improvements or additions to documentation good first issue Good for newcomers labels Apr 12, 2024
@dpaiton
Copy link
Member Author

dpaiton commented Apr 15, 2024

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
Copy link
Member Author

dpaiton commented Apr 30, 2024

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

@ryangoree ryangoree transferred this issue from delvtech/hyperdrive May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant