ib uses "FIFO" positioning logic - that's super anti-retail.. lame
#307
Assignees
Labels
accounting
prolly positioning: the accounting of "what/when (is) owned"
broker-backend
`brokerd`/`datad` related backend tech
brokers-can-smbz
features that suits should provide
Comments
goodboy
added a commit
that referenced
this issue
May 15, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added a commit
that referenced
this issue
May 15, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added a commit
that referenced
this issue
May 15, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added a commit
that referenced
this issue
May 21, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added a commit
that referenced
this issue
May 24, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added a commit
that referenced
this issue
Jun 3, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added a commit
that referenced
this issue
Jun 5, 2022
In order to expose more `asyncio` powered `Client` methods to endpoint task-code this adds a more extensive and layered set of `MethodProxy` loading routines, in dependency order these are: - `load_clients_for_trio()` a `tractor.to_asyncio.open_channel_from()` entry-point factory for loading all scanned clients on the `asyncio` side and delivering them over the inter-task channel to a `trio`-side task. - `get_preferred_data_client()` a simple client instance loading routine which reads from the users `brokers.toml -> `prefer_data_account: list[str]` which must list account names, in priority order, that are acceptable to be used as the main "data connection client" such that only one of the detected clients is used for data (whereas the rest are used only for order entry). - `open_client_proxies()` which delivers the detected `Client` set wrapped each in a `MethodProxy`. - `open_data_client()` which directly delivers the preferred data client as a proxy for `trio` tasks. - update `open_client_method_proxy()` and `open_client_proxy` to require an input `Client` instance. Further impl details: - add `MethodProxy._aio_ns` to ref the original `asyncio` side proxied instance - add `Client.trades()` to pull executions from the last day/session - load proxies inside `trades_dialogue` and use the new `.trades()` method to try and pull a fill ledger for eventual correct pp price calcs (pertains to #307)..
goodboy
added
broker-backend
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
i got lots more examples of plain old pure nonsense that goes on with this broker (and hint, issues like this are exactly why this project got started by a bunch of weirdos in the first place) but the latest is a truly exemplary inverse-hanlon's, icing-on-cake, can you be more rigged, idiotic, plain-laughable-while-despicable.
The easiest way to understand the issue in it's entirety is to read this elitetrader thread which breaks down the issue in great detail.
synopsis:
ib's stack, despite being probably the most advanced in the retail space, magically can't give you more then 7days worth of your own trade events without using their even shoddier "PLEX RePOrtz" (which you then have to parse and correlate on your own with the traditional APIs, oh and did i mention it's delayed a day...smh**2); even the worst crypto exchanges give you at least your trades history ledger (even if they don't compute pps or PnL for you 😿 ).I'd really love to hear the explanation for why literally the most important ledger as a trader isn't available through the API over a timeframe suitable for actually calculating long running pp pnls..
What
ibwill give you is their horribly calculated FIFO style "average price" in PnL events and by default in TWS's (mosaic) "portfolio view". FIFO is horrible because as you exit a pp your average price changes. This is just plain idiotic: it means the trader has to manually recompute what the "magic price is" that determines whether you exit the pp at a profit or a loss (sorry to anyone who can't grok this but i have no clue how you can even compute a net-zero pnl without this). Using FIFO is mysteriously convenient for the broker (and i'm sure their larger clients who trade against most retail traders who get stuck with this accounting reporting model) yet in pretty much all the ways, makes their client's more susceptible to lose money unless they're saavy enough to compute a LIFO style pp avg price themselves. I'll say it again, i don't know how you can calculate a sane pnl with LIFO - i've experienced it first hand - the avg price will never be the price that determines the net-zero position pnl.technicalities
but why aren't we reporting this issue to them?
bc honestly f#$% them. we'll hack around it ourselves just like we do everything else they have; there's no time around these parts for dealing with clearly incompetant-but-possibly-malicious, absolutely ridiculous nonsense like this.
The text was updated successfully, but these errors were encountered: