Skip to content

Ppu history#365

Merged
goodboy merged 7 commits intomasterfrom
ppu_history
Jul 27, 2022
Merged

Ppu history#365
goodboy merged 7 commits intomasterfrom
ppu_history

Conversation

@goodboy
Copy link
Copy Markdown
Contributor

@goodboy goodboy commented Jul 26, 2022 •
edited
Loading

Proper fixes and terminology to get us ready for historical position lifetimes as described in #345.

More to come in terms of explanation... or not 😂

pps.toml format changes:

  • could we maybe just drop the top level .size and be_price values ?
    • so we can't (yet), because the ems uses the Position type internally as well and doesn't track all the
      clears (since that would be more msging overhead) so I think maybe having these is fine but we should probably
      change .be_price -> .ppu?
    • and instead just arrange the clears table to make these rolling values more obvious?, for eg:
[kraken.spot."xbteur.kraken"]
bsuid = "xbteur"
clears = [
 {  accum_size = 0.00639943, ppu = 19620.4996648139, cost = 0.32477, price = 19519.0, size = 0.00639943, dt = "2022-06-17T00:17:53.030664+00:00", tid = "TZVEXD-USARI-COY2ZR"},

which would be easiest to read if we sort clears reverse chronological so that the most recent trades (and thus their ppu and accum_size entries would be closest to the top?

  • it follows that maybe we should adjust the column order for each clears entry maybe to: dt, ppu, accum_size, price, size, cost, tid?
  • [ ] i was hoping to have an indent per account (mentioned it in Positioning system refinements: paper engine, file writing, toml style and perf  #345 as part of a custom encoder) such that it's distinguishable which pps are grouped together by backend, my only concern is then the clears table entries will be a bit cramped horizontally? delaying this one again

goodboy added 3 commits July 25, 2022 12:06
@goodboy
Drop .lifo_upate() add .audit_sizing()
958e542 
Use the new `.calc_[be_price/size]()` methods when serializing to and
from the `pps.toml` format and add an audit method which will warn about
mismatched values and assign the clears table calculated values pre-write.

Drop the `.lifo_update()` method and instead allow both
`.size`/`.be_price` properties to exist (for non-ledger related uses of
`Position`) alongside the new calc methods and only get fussy about
*what* the properties are set to in the case of ledger audits.

Also changes `Position.update()` -> `.add_clear()`.
@goodboy
Minimize clears and audit sizing for all updates in `.update_from_tra…
5520e9e 
…ns()`
@goodboy
Rework "breakeven" price as "price-per-uni": ppu
ddffaa9 
The original implementation of `.calc_be_price()` wasn't correct since
the real so called "price per unit" (ppu), is actually defined by
a recurrence relation (which is why the original state-updated
`.lifo_update()` approach worked well) and requires the previous ppu to
be weighted by the new accumulated position size when considering a new
clear event. The ppu is the price that above or below which the trader
takes a win or loss on transacting one unit of the trading asset and
thus it is the true "break even price" that determines making or losing
money per fill. This patches fixes the implementation to use trailing
windows of the accumulated size and ppu to compute the next ppu value
for any new clear event as well as handle rare cases where the
"direction" changes polarity (eg. long to short in a single order). The
new method is `Position.calc_ppu()` and further details of the relation
can be seen in the doc strings.

This patch also includes a wack-ton of clean ups and removals in an
effort to refine position management api for easier use in new backends:

- drop `updaate_pps_conf()`, `load_pps_from_toml()` and rename
  `load_trands_from_ledger()` -> `load_pps_from_ledger()`.
- extend `PpTable` to have a `.to_toml()` method which returns the
  active set of positions ready to be serialized to the `pps.toml` file
  which is collects from calling,
- `PpTable.dump_active()` which now returns double dicts of the
  open/closed pp object maps.
- make `Position.minimize_clears()` now iterate the clears table in
  chronological order (instead of reverse) and only drop fills prior
  to any zero-size state (the old reversed way can result incorrect
  history-size-retracement in cases where a position is lessened but
  not completely exited).
- drop `Position.add_clear()` and instead just manually add entries
  inside `.update_from_trans()` and also add a `accum_size` and `ppu`
  field to ever entry thus creating a position "history" sequence of
  the ppu and accum size for every position and prepares for being
  and to show "position lifetimes" in the UI.
- move fqsn getting into `Position.to_pretoml()`.
goodboy added a commit that referenced this pull request Jul 26, 2022
@goodboy
Look for transfers after ledger + api trans load
6545efe 
If we don't have a pos table built out already (in mem) we can't figure
out the likely dst asset (since there's no pair entry to guide us) that
we should use to search for withdrawal transactions; so move it later.

Further this ports to the new api changes in `piker.pp`` that will land
with #365.
@goodboy goodboy requested a review from guilledk July 26, 2022 19:05
@goodboy goodboy marked this pull request as ready for review July 27, 2022 15:18
goodboy added a commit that referenced this pull request Jul 27, 2022
@goodboy
Look for transfers after ledger + api trans load
aa3c6ea 
If we don't have a pos table built out already (in mem) we can't figure
out the likely dst asset (since there's no pair entry to guide us) that
we should use to search for withdrawal transactions; so move it later.

Further this ports to the new api changes in `piker.pp`` that will land
with #365.
guilledk
guilledk previously approved these changes Jul 27, 2022
View reviewed changes
Copy link
Copy Markdown

@guilledk guilledk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"could we maybe just drop the top level .size and be_price values and instead just arrange the clears table to make these rolling values more obvious?"
Sure, sounds good.
"it follows that maybe we should adjust the column order for each clears entry maybe to: dt, ppu, accum_size, price, size, cost, tid?"
Agreed.
... "my only concern is then the clears table entries will be a bit cramped horizontally?"
Mmmm not sure, id have to see an example.

Quick review of the code looks great.

@goodboy goodboy added accounting prolly positioning: the accounting of "what/when (is) owned" ledger trade, accounts and other user focal event history tracking, management and storage labels Jul 27, 2022
@goodboy goodboy merged commit d81e629 into master Jul 27, 2022
@goodboy goodboy deleted the ppu_history branch July 27, 2022 16:25
goodboy added a commit that referenced this pull request Jul 27, 2022
@goodboy
Look for transfers after ledger + api trans load
4090b75 
If we don't have a pos table built out already (in mem) we can't figure
out the likely dst asset (since there's no pair entry to guide us) that
we should use to search for withdrawal transactions; so move it later.

Further this ports to the new api changes in `piker.pp`` that will land
with #365.
goodboy added a commit that referenced this pull request Jul 27, 2022
@goodboy
Look for transfers after ledger + api trans load
839a09e 
If we don't have a pos table built out already (in mem) we can't figure
out the likely dst asset (since there's no pair entry to guide us) that
we should use to search for withdrawal transactions; so move it later.

Further this ports to the new api changes in `piker.pp`` that will land
with #365.
goodboy added a commit that referenced this pull request Jul 27, 2022
@goodboy
Look for transfers after ledger + api trans load
b318489 
If we don't have a pos table built out already (in mem) we can't figure
out the likely dst asset (since there's no pair entry to guide us) that
we should use to search for withdrawal transactions; so move it later.

Further this ports to the new api changes in `piker.pp`` that will land
with #365.
@goodboy goodboy mentioned this pull request Jul 29, 2022
Merged
12 tasks
goodboy added a commit that referenced this pull request Jul 30, 2022
@goodboy
Look for transfers after ledger + api trans load
168c986 
If we don't have a pos table built out already (in mem) we can't figure
out the likely dst asset (since there's no pair entry to guide us) that
we should use to search for withdrawal transactions; so move it later.

Further this ports to the new api changes in `piker.pp`` that will land
with #365.
@goodboy goodboy mentioned this pull request Feb 3, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@guilledk guilledk guilledk left review comments

Assignees

No one assigned

Labels

accounting prolly positioning: the accounting of "what/when (is) owned" ledger trade, accounts and other user focal event history tracking, management and storage

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@goodboy @guilledk