@RandyT said in Pyramiding support: Thanks Randy for getting back.

@steffen Thanks for the link. I was thinking to create simple strategy in bt which will go thru all of the contracts and return me continuous contract data feed built by my rules. Since I am using daily bars I am not so concerned about live trading right now. I is beneficial, but not mandatory.

Here is the approach - compare length of the daily data feed on each next() call. This will help to avoid excessive next() calls due to resampling. You might be able to come up with the only next() call at the end of the week. class MasterStrategy(bt.Strategy): def __init__(self): self.daily_length = 0 def next(self): if len(self.datas[0]) > self.daily_length: print('daily:{} len: {} | weekly:{} len: {} | monthly:{} len: {}'\ .format(bt.num2date(self.datas[0].datetime[0]), len(self.datas[0]),\ bt.num2date(self.datas[1].datetime[0]), len(self.datas[1]),\ bt.num2date(self.datas[2].datetime[0]), len(self.datas[2]))) self.daily_length = len(self.datas[0]) Output: daily:2017-10-16 23:59:59.999989 len: 98 | weekly:2017-10-13 23:59:59.999989 len: 20 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-17 23:59:59.999989 len: 99 | weekly:2017-10-13 23:59:59.999989 len: 20 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-18 23:59:59.999989 len: 100 | weekly:2017-10-13 23:59:59.999989 len: 20 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-19 23:59:59.999989 len: 101 | weekly:2017-10-13 23:59:59.999989 len: 20 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-20 23:59:59.999989 len: 102 | weekly:2017-10-13 23:59:59.999989 len: 20 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-23 23:59:59.999989 len: 103 | weekly:2017-10-20 23:59:59.999989 len: 21 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-24 23:59:59.999989 len: 104 | weekly:2017-10-20 23:59:59.999989 len: 21 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-25 23:59:59.999989 len: 105 | weekly:2017-10-20 23:59:59.999989 len: 21 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-26 23:59:59.999989 len: 106 | weekly:2017-10-20 23:59:59.999989 len: 21 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-27 23:59:59.999989 len: 107 | weekly:2017-10-20 23:59:59.999989 len: 21 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-30 23:59:59.999989 len: 108 | weekly:2017-10-27 23:59:59.999989 len: 22 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-10-31 23:59:59.999989 len: 109 | weekly:2017-10-27 23:59:59.999989 len: 22 | monthly:2017-09-29 23:59:59.999989 len: 5 daily:2017-11-01 23:59:59.999989 len: 110 | weekly:2017-10-27 23:59:59.999989 len: 22 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-02 23:59:59.999989 len: 111 | weekly:2017-10-27 23:59:59.999989 len: 22 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-03 23:59:59.999989 len: 112 | weekly:2017-10-27 23:59:59.999989 len: 22 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-06 23:59:59.999989 len: 113 | weekly:2017-11-03 23:59:59.999989 len: 23 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-07 23:59:59.999989 len: 114 | weekly:2017-11-03 23:59:59.999989 len: 23 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-08 23:59:59.999989 len: 115 | weekly:2017-11-03 23:59:59.999989 len: 23 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-09 23:59:59.999989 len: 116 | weekly:2017-11-03 23:59:59.999989 len: 23 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-10 23:59:59.999989 len: 117 | weekly:2017-11-03 23:59:59.999989 len: 23 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-13 23:59:59.999989 len: 118 | weekly:2017-11-10 23:59:59.999989 len: 24 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-14 23:59:59.999989 len: 119 | weekly:2017-11-10 23:59:59.999989 len: 24 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-15 23:59:59.999989 len: 120 | weekly:2017-11-10 23:59:59.999989 len: 24 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-16 23:59:59.999989 len: 121 | weekly:2017-11-10 23:59:59.999989 len: 24 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-17 23:59:59.999989 len: 122 | weekly:2017-11-10 23:59:59.999989 len: 24 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-20 23:59:59.999989 len: 123 | weekly:2017-11-17 23:59:59.999989 len: 25 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-21 23:59:59.999989 len: 124 | weekly:2017-11-17 23:59:59.999989 len: 25 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-22 23:59:59.999989 len: 125 | weekly:2017-11-17 23:59:59.999989 len: 25 | monthly:2017-10-31 23:59:59.999989 len: 6 daily:2017-11-24 23:59:59.999989 len: 126 | weekly:2017-11-17 23:59:59.999989 len: 25 | monthly:2017-10-31 23:59:59.999989 len: 6

@sunnyalgotrader Hmm... I must be crazy because now I see only entry bars.

I am using this approach since a while now and I have to say that I am quite happy with it: https://github.com/verybadsoldier/backtrader/commit/f03a0ed115338ed8f074a942f6520b31c630bcfb Makes it possible for me to evaluate OptReturn objects without the need of any further input (like a cerebro object).

@ed-bartosh ccxt had some unique properties that made it possible to implement the broker straight from BrokerBase and give access to more then 1 exchange simultaneously in a way that feel very integrated and easy to use. remember that ccxt project is all about unifying the variety of exchanges under one api. and a key part of my development was that the feed had some exchange info inside it. but to make a more generic broker means to really create a broker that hold a collection of brokers inside (that are not really unified) and switching between them like you proposed before. The biggest problem this way, is that there are still methods that will get called by Backtrader in the background on the 'active' broker without the intention of the user. A better solution that may work more like what i wrote is if every feed will hold some broker information in a well known way and then you don't need to guess on what broker.

@ab_trader I see. I'll figure out what's best for me. Thanks!

@backtrader Yes,you are right!

@gminorcoles I am just a user of the bt, not an owner. Sometimes I share pieces of the code. @backtrader is an owner. if you want/can offer any enhancements, then just create pull request with that enhancement. @backtrader will check it and incorporate if it will be suitable from his point of view.

@backtrader Why wouldn't you close the position with close? already did that. I used order_target as my zipline code that I'm porting to backtrader used order_target* APIs.

See the news release, Community - Release 1.9.50.117 and this note Community - YahooFinace Data Feeds

@backtrader oke, Thans for helping me, and it work complete. :) this is my fully code: from datetime import datetime import backtrader as bt import math %matplotlib notebook class ZigZag(bt.ind.PeriodN): ''' Identifies Peaks/Troughs of a timeseries ''' lines = ( 'trend', 'last_pivot_t', 'last_pivot_x', 'last_pivot_ago', 'zigzag_peak', 'zigzag_valley', 'zigzag', 'last_zigzag', ) # Fancy plotting name # plotlines = dict(logreturn=dict(_name='log_ret')) plotinfo = dict( subplot=False, plotlinelabels=True, plotlinevalues=True, plotvaluetags=True, ) plotlines = dict( trend=dict(marker='', markersize=0.0, ls='', _plotskip=True), last_pivot_t=dict(marker='', markersize=0.0, ls='', _plotskip=True), last_pivot_x=dict(marker='', markersize=0.0, ls='', _plotskip=True), last_pivot_ago=dict(marker='', markersize=0.0, ls='', _plotskip=True), zigzag_peak=dict(marker='v', markersize=4.0, color='red', fillstyle='full', ls=''), zigzag_valley=dict(marker='^', markersize=4.0, color='red', fillstyle='full', ls=''), zigzag=dict(_name='zigzag', color='blue', ls='-', _skipnan=True), last_zigzag=dict(_name='last_zigzag', color='blue', ls='--', _skipnan=True), ) # update value to standard for Moving Averages params = ( ('period', 2), ('up_retrace', 0.1), ('dn_retrace', 0.1), ('bardist', 0.015), # distance to max/min in absolute perc ) def __init__(self): super(ZigZag, self).__init__() if not self.p.up_retrace: raise ValueError('Upward retracement should not be zero.') if not self.p.dn_retrace: raise ValueError('Downward retracement should not be zero.') if self.p.up_retrace < 0: self.p.up_retrace = -self.p.up_retrace if self.p.dn_retrace > 0: self.p.dn_retrace = -self.p.dn_retrace self.p.up_retrace = self.p.up_retrace / 100 self.p.dn_retrace = self.p.dn_retrace / 100 self.missing_val = float('nan') def prenext(self): self.lines.trend[0] = 0 self.lines.last_pivot_t[0] = 0 self.lines.last_pivot_x[0] = self.data[0] self.lines.last_pivot_ago[0] = 0 self.lines.zigzag_peak[0] = self.missing_val self.lines.zigzag_valley[0] = self.missing_val self.lines.zigzag[0] = self.missing_val self.lines.last_zigzag[0] = self.missing_val def next(self): data = self.data trend = self.lines.trend last_pivot_t = self.lines.last_pivot_t last_pivot_x = self.lines.last_pivot_x last_pivot_ago = self.lines.last_pivot_ago zigzag_peak = self.lines.zigzag_peak zigzag_valley = self.lines.zigzag_valley zigzag = self.lines.zigzag last_zigzag = self.lines.last_zigzag x = data[0] r = x / last_pivot_x[-1] - 1 curr_idx = len(data) - 1 trend[0] = trend[-1] last_pivot_x[0] = last_pivot_x[-1] last_pivot_t[0] = last_pivot_t[-1] last_pivot_ago[0] = curr_idx - last_pivot_t[0] zigzag_peak[0] = self.missing_val zigzag_valley[0] = self.missing_val zigzag[0] = self.missing_val last_zigzag[0] = x if trend[-1] == 0: if r >= self.p.up_retrace: piv = last_pivot_x[0] * (1 - self.p.bardist) zigzag_valley[-int(last_pivot_ago[0])] = piv zigzag[-int(last_pivot_ago[0])] = last_pivot_x[0] trend[0] = 1 last_pivot_x[0] = x last_pivot_t[0] = curr_idx elif r <= self.p.dn_retrace: piv = last_pivot_x[0] * (1 + self.p.bardist) zigzag_peak[-int(last_pivot_ago[0])] = piv zigzag[-int(last_pivot_ago[0])] = last_pivot_x[0] trend[0] = -1 last_pivot_x[0] = x last_pivot_t[0] = curr_idx elif trend[-1] == -1: if r >= self.p.up_retrace: piv = last_pivot_x[0] * (1 - self.p.bardist) zigzag_valley[-int(last_pivot_ago[0])] = piv zigzag[-int(last_pivot_ago[0])] = last_pivot_x[0] trend[0] = 1 last_pivot_x[0] = x last_pivot_t[0] = curr_idx elif x < last_pivot_x[-1]: last_pivot_x[0] = x last_pivot_t[0] = curr_idx elif trend[-1] == 1: if r <= self.p.dn_retrace: piv = last_pivot_x[0] * (1 + self.p.bardist) zigzag_peak[-int(last_pivot_ago[0])] = piv zigzag[-int(last_pivot_ago[0])] = last_pivot_x[0] trend[0] = -1 last_pivot_x[0] = x last_pivot_t[0] = curr_idx elif x > last_pivot_x[-1]: last_pivot_t[0] = curr_idx last_pivot_x[0] = x idx = 1 while idx < len(self.zigzag) and math.isnan(zigzag[-idx]): last_zigzag[-idx] = self.missing_val idx += 1 if idx < len(self.data): last_zigzag[-idx] = zigzag[-idx] class SmaCross(bt.SignalStrategy): params = (('pfast', 10), ('pslow', 30),) def init(self): sma1, sma2 = bt.ind.SMA(period=self.p.pfast), bt.ind.SMA(period=self.p.pslow) self.signal_add(bt.SIGNAL_LONG, bt.ind.CrossOver(sma1, sma2)) cerebro = bt.Cerebro() data = bt.feeds.YahooFinanceData(dataname='MSFT', fromdate=datetime(2011, 1, 1), todate=datetime(2012, 12, 31)) cerebro.adddata(data) cerebro.addstrategy(SmaCross) cerebro.addindicator(ZigZag) cerebro.run() cerebro.plot(style='candlestick')

@blonc said in Strategy Selection Pattern: The concept I am trying to achieve is to have many strategies all being monitored by a master strategy. This way, the master strategy could be using a markov chain to monitor returns to turn on and off individual strategies based on the total returns of all strategies. It seems the best path is to , correct me if wrong, put the strategies logic into indicators and bring them into one master strategy. @backtrader said in Strategy Selection Pattern: Sub-strategies is not a pattern which does exist in backtrader. Using Indicator instances could do the trick. Was also thinking about utilizing the concept of having a "master" strategy turning on and off "micro strategies", so I'm glad I found this post :) I can think of a lot of use cases for using a master strategy that based on a wide overview of a market/s can control what micro strategies are suited to be used. the idea of using indicators as sub-strategies seem brilliant (haven't tested it yet). but from my understanding strategies can be better analyzed and give valuable insights. I hope we can wider the discussion just to explore more solutions (as @backtrader mentioned nested strategies are not supported) one idea I have that I don't think break backtrader structure is: declaring a 'master' that run first and based on whatever user logic it creates a 'signal dictionary' that is then passed to all other micro strategies. allowing them to decide if to run or not in next(). this way all strategies are kept in the same level of operation (not nested)

After testing the code above and plotting the divergences that it found, I think that the issue is with this line: self.hfi = bt.ind.FindFirstIndexHighest(self.data.high, period=self.p.hl_period) It looks for the highest point (same for the lowest) within the hl_period (100 bars) Then in the following line it looks again backwards from that point to find the second high h_iterable = self.data.get(size=self.p.hl_period, ago=-int(self.hfi[0]) - self.p.hl_min) So basically the code returns signals for very old divergences. If you are on daily chart, you will try to trade on a divergence that is 100 days old. So the first day after the high point it signals a sell, then for the next 100 days it still signals a sell ! I have amended the first line to look for a high/low point for the last day only. In this way if the divergence is growing then it's fine you still get a sell signal, but if the divergence is gone then you don't try to keep selling for 100 days.

@scottz1 Answering my own question, I found how analyzers can easily access attributes in the strategy. This would allow me to avoid creating a duplicate ATR indicator in the analyzer, but I've run into a problem with this. If I use a buystop order to open a trade, the strategy doesn't know the fill price until notify_order. I therefore use strategy notify_order order.Completede to calculate a stop loss in ATR units and submit a stop loss order. My analyzer needs to know that stop loss measurement, but... Analyzer notify_trade is called before strategy notify_order. What would be a good design for this?

@backtrader Thank you!! I didn't realize I needed an external thing, but it actually works now. Can finally get to the actual fun part of coding out the strategy.

@nicola-prada I think this can be done by creating subclass of existing indicator, effectively 'extending' an indicator

@ab_trader said in IndexError: array index out of range: In the __init()__ indexing should be done with (), not with [] brackets, ref Docs - Lines: DELAYED indexing: Pointed out some days ago by @ab_trader

@cortex hello, I'm learn to use backtrader ,and I'm trying to use the Oandatest.py with some problem. errormsg is the same with you. I want to know how to run oandatest.py succeed, I have oanda account and token. and pip install oandapy. but I can't run it succeed. please give me a hand. thanks very much.

So I can loop through all my data in the Next.. self.datas is an array and you can loop over it. How do I plot the portfolio performance? instead of backtrader printing 1000 different charts... Depends on what you have defined as performance for your portfolio. There is for example a TimeReturn observer which is intended to plot exactly what the name implies. If you want to plot other performance indicator, you will need to define it as an indicator or observer The default is to plot the evolution of the cash and the actual portfolio value which should give a quick indication as to where the system is And only a single chart will be printed per strategy. Is there an integrated solution to do this in Backtrader? There are several samples, blog and documentation pages. See for example: Docs - Benchmarking Here the performance is defined as the comparison against another asset.