@run-out also, to put this into perspective, I currently run tens of millions of tests across these datasets. Just have to ask if you're able to do that with this strategy?
I was doing a factor analysis and the factor parr (eg first part precalculated) didn't change much. I have also used it in other cases where it slowed down. So not sure how it will work out for you. Good luck.
Do you know if this compression is the same as when done by backtrader (ie bar2edge, boundoff, rightedge etc?
I believe so
I noticed that you can have very different presentation of 5mn, 1h etc data depending of the data provider. For me, it was differences between data from MT5 & data resampled by BT. For example, 1h data from MT5 had a different close value. You may want to check the M5 & H1 open & close values to find if it is the one of neighboring minutes and also check the doc to find if some additional parameters (boundoff, rightedge etc.) can bring you the results you want
Also, I noticed during my tests that if some minutes are missing, the resampling to for ex. H8 may lead to errors (closure of the bar occur later than expected - I still have to find the time to log an issue in BT2 for that)
for anyone else who stumbles across this thread, since some people are still trying to get this working outside of OP's original branch, wanted to pass along the following info:
you can still get this working if you take the BasicTradeStats analyzer class and import it as a custom analyzer of your own.
Finally, in your code, make sure you have something like the following lines:
# import the file at the top of your code where "BasicTradeStats" is the name of the class
from extensions.analyzers import BasicTradeStats
# add the strategy to cerebro
opt_runs = cerebro.run(maxcpus=1, runonce=False)
for run in opt_runs:
for strategy in run:
# finally, this will print the analyzer
I think it's possible to have 1 large bar to form multiple bricks but not with the implementation in backtrader's filter, you have to implement your own renko filter. every extra bricks need to have a small time offset, due to the precision, the smallest value is 10 microseconds which is small enough to use I think.
No, under buy_price, because your are talking about stop-loss (you are in the market), people will understand the price at which you bought your asset and not the expected (and yet unknown) price at which the next order, the stop-loss one will execute.
Got this. I've declared a new variable which is store buy_price and updates it in notify order method with order.executed.price.
Normally when using a list or dictionary to track orders, if you remove the orders from the list at the right spots, there should be no issues with the list.
However, I tend to get a bit cautious (lazy?) and insert a clause at the beginning of next() that checks if:
Are there any open positions, and...
Are there any live orders.
If there are no open positions and no live orders, really the list should be empty. The code looks something like:
if self.position.size == 0 and len([o for o in self.o_li if o.status < 4]) == 0:
self.o_li = list()
Order status of 4 is completed, and higher are all dead orders.
Then another thing I notice in your code is that you have bracket orders with purchase price which is fine. But if the stock trends permanantly away from your purchase price, you will be left with a set of orders that will never fill, blocking future intended orders, since there are open orders.
Since in your bracket orders you entering the market at last close, probably best to leave exectype as Market and no plimit, or alternatively insert a valid period so the bracket expires after so many bars.