-
Notifications
You must be signed in to change notification settings - Fork 17
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
LIFO/"breakeven" pps for ib
#336
Conversation
Marking this ready to get some eyes, but it's still super ib-specific and I want to still finesse a buncha stuff and make follow up issues for a more general solution / API for ledgers. |
Aight, as of right now [ib.algopaper."mnq.globex.20220916"]
size = 58.0
be_price = 11703.458965517251
bsuid = 497954580
expiry = "2022-09-16T00:00:00+00:00"
clears = [
{ tid = "0000e1a7.629f3c2d.01.01", cost = 0.57 },
{ tid = "0000e1a7.629fa5c0.01.01", cost = 0.57 },
{ tid = "0000e1a7.62a0a898.01.01", cost = 0.57 },
{ tid = "0000e1a7.62a0fb24.01.01", cost = 0.57 },
] includes a table of As further refinemen we could probably,
|
0311e24
to
800715e
Compare
…er>_<acct>.toml` files
Start a generic "position related" util mod and bring in the `Position` type from the allocator , convert it to a `msgspec.Struct` and add a `.lifo_update()` method. Implement a WIP pp parser from a trades ledger and use the new lifo method to gather position entries.
Since "flex reports" are only available for the current session's trades the day after, this adds support for also collecting trade execution records for the current session and writing them to the equivalent ledger file. Summary: - add `trades_to_records()` to handle parsing both flex and API event objects into a common record form. - add `norm_trade_records()` to handle converting ledger entries into `TradeRecord` types from the new `piker.pps` mod (coming in next commit).
Add a `TradeRecord` struct which holds the minimal field set to build out position entries. Add `.update_pps()` to convert a set of records into LIFO position entries, optionally allowing for an update to some existing pp input set. Add `load_pps_from_ledger()` which does a full ledger extraction to pp objects, ready for writing a `pps.toml`.
This makes it possible to refresh a single fqsn-position in one's `pps.toml` by simply deleting the file entry, in which case, if there is new trade records passed to `load_pps_from_toml()` via the new `reload_records` kwarg, then the backend ledger entries matching that symbol will be filtered and used to recompute a fresh position. This turns out to be super handy when you have crashes that prevent a `pps.toml` entry from being updated correctly but where the ledger does have all the data necessary to calculate a fresh correct entry.
- use `tomli` package for reading since it's the fastest pure python reader available apparently. - add new fields to each pp's clears table: price, size, dt - make `load_pps_from_toml()`'s `reload_records` a dict that can be passed in by the caller and is verbatim used to re-read a ledger and filter to the specified symbol set to build out fresh pp objects. - add a `update_from_ledger: bool` flag to `load_pps_from_toml()` to allow forcing a full backend ledger read. - if a set of trades records is passed into `update_pps_conf()` parse out the meta data required to cause a ledger reload as per 2 bullets above. - return active and closed pps in separate by-account maps from `update_pps_conf()`. - drop the `key_by` kwarg.
Before we weren't emitting pp msgs when a position went back to "net zero" (aka the size is zero) nor when a new one was opened (wasn't previously loaded from the `pps.toml`). This reworks a bunch of the incremental update logic as well as ports to the changes in the `piker.pp` module: - rename a few of the normalizing helpers to be more explicit. - drop calling `pp.get_pps()` in the trades dialog task and instead create msgs iteratively, per account, by iterating through collected position and API trade records and calling instead `pp.update_pps_conf()`. - always from-ledger-update both positions reported from ib's pp sys and session api trades detected on ems-trade-dialog startup. - `update_ledger_from_api_trades()` now does **just** that: only updates the trades ledger and returns the transaction set. - `update_and_audit_msgs()` now only the input list of msgs and properly generates new msgs for newly created positions that weren't previously loaded from the `pps.toml`.
Gah, was a remaining bug where if you tried to update the pps state with both new trades and from the ledger you'd do a double add of transactions that were cleared during a `update_pps()` loop. Instead now keep all clears in tact until ready to serialize to the `pps.toml` file in which cases we call a new method `Position.minimize_clears()` which does the work of only keep clears since the last net-zero size. Re-implement `update_pps_conf()` update logic as a single pass loop which does expiry and size checking for closed pps all in one pass thus allowing us to drop `dump_active()` which was kinda redundant anyway..
Proper attempt at #307 and a local "trades" ledger system using
.toml
files under<confdir>/ledgers/
where files will be named something like:trades_<brokername>_<accountname>.toml
So far ledger contents looking something like this:
Click to expand!
And, as of right now
pps.toml
entries lookin more or less like this (example only):REQUIREMENT:
TODO: (oustandings moved to #345)
pps.toml
local position tracking/summary fileid
,cost
,(date-)timestamp
, maybe something else?breakeven_price
lifo_price
?Client.trades()
methodPostionTracker
UX on chartsProbably as follow up PR(s): -> See #345 for all deferrals and detailed write up of all these
kraken
ledger parsing and generalize into a top level module?piker ledger
subcommand?piker pps
subcommand with openspps.toml
in editor/pager?toml
encoder?toml
encoder to output things sanely, i think it's just worth writing a super fast custom encoder that writes adhoc-ly in the format we want forpps.toml
, the reader-writer separation is already whattomli
does (the fastest pure py reader soon to land in the stdlib) and and then we can just droptoml
outright and worry about getting a general encoder later.pps.toml
updates ingit