search

rosspalmer / bitQuant

Bitcoin data gathering, backtesting, and algorithmic trading solution
MIT License
23 stars 9 forks source link

Trades to price across multiple exchanges #3

Closed multidis closed 9 years ago

multidis commented 9 years ago

When calling

trades_to_price('','btcusd','min',0)

the resulting OHLCV dataframe contains only a single exchange in the exchange-column even if the trades-table contains entries from multiple exchanges. Is this by design? I'd expect price_df called by trades_to_price returns trades across multiple exchanges if the exchange-argument is not specified, thus the OHLC prices would be computed over all of the trades not just those from one specific exchange.

rosspalmer commented 9 years ago

At this point the trades_to_price function is only accurate for a single exchange/freq but will not prevent the issue you are outlining above. If you ran that over multiple exchanges, all of the data would be run as a single set and therefore the resultant price data would be incorrect.

I would like multiple exchange/freq support so that you could do a single SQL query of the trade data and then run multiple conversions. I am thinking the best option will be to create an add(exchange, freq) function in the class and forcing a non '' value to fix the bug.

Just as a reminder to myself as well, I need to set the start (0) variable as optional.

multidis commented 9 years ago

Regarding "all of the data would be run as a single set and therefore the resultant price data would be incorrect": that actually may be needed in some cases to get an OHLCV picture integrated across exchanges, thus providing a more complete bitcoin picture. Quite a few arbitrage opportunities exist between exchanges due to frequent price differences, and collecting all the trades in one set is for some purposes more representative than a single exchange OHLC.

Therefore, I was thinking that exchange = '' but currency pair being specified would pull out all the trades together to produce OHLC, similarly to trades_df that receives all the trades when the exchange argument is not specified. And then add(exchange, freq) function could be there as well to produce exchange-specific OHLC. Would that be too confusing to have all of these options?

rosspalmer commented 9 years ago

ahhh I get what your driving at and it would be nice to have the ability to make custom exchange indexs. If you do input exchange = '' it should run the OLHC function on the combined data but as you noted use a single exchange name. We can either put in the ability to add custom names or automatically name it something like btc_index.

Now, I'm wondering if the next step after that would be to incorporate the some form of "relative price" function when combining exchanges to account for varying commission structures. This could also be used to combine exchanges with different real life currencies and could be used as an "arbitrage detector" in live trading algorithms.

multidis commented 9 years ago

Just to make sure I understand correctly: the current code does produce OHLCV from multiple exchange's trades with exchange = '' but places one of those exchanges as exchange name? Is that correct?

If that is the case, it may be good to just put 'multiple' as exchange name whenever trades from more than one exchange were incorporated into a given OHLC bar.

But I was not sure how the exchange = '' case works since when tried to query 2 exchanges during separate (disjoint) time periods, it appeared from a brief look at epoch stamps that not all of the time interval was used. I did not do any extensive checks on that though and may be mistaken (perhaps for a wish-list: some TDD on price aggregation...)

As far as the "arbitrage detector" and "relative prices": I guess orderbook information collection would be needed for that in addition to completed trades. This seems to be a separate topic, with some code and startup attempts. At the moment bitQuant seems attractive (IMHO) for the data collection use having clear code (I'm not a python person at all so "clear" is very subjective here) for that part.

rosspalmer commented 9 years ago

I cleaned up support for multiple exchanges in this commit.

The exchange variable can accept both a single exchange string and a list of strings. Additionally, if you set exchange='all', all exchanges for a symbol will be pulled.

The exchange column in the output data now can be set manually by setting an optional variable trades_to_price(name=). If all is set or list is provided without a name variable, the exchange column will be multi.

Thanks for the kind words on the clean code, definitely something I obsess about.

multidis commented 9 years ago

Single-exchange as well as 'all' options appear to work properly, thanks for responding so fast! While testing I noticed OHLCV values are written in the beginning (not end) of each time-bin, will open a separate issue on that.