Available with this commit in the development branch: https://github.com/mementum/backtrader/commit/aba90a3ff4e115e3373ea15389410adf10f2b4cf The regular IB functionality doesn't seem broken by these changes.

@backtrader ? I am already placing trade w/ price=self.data.open[0] and cheat_on_open. Backtrader will reject those orders internally due to reasons outlined above. On another thought, how do we place orders on margin? Adding those margin cash will be another way to solve this issue. Does backtrader keep track of gross exposure vs net exposure/unlevered? I can tolerate trading on a few points of margin to get fill in both live/simulation but need a wy to track gross/net exposure.

Thanks for elaborating, this is the output; 016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-03-31, Close, 1.44 2016-04-01, Close, 1.44 Final Portfolio Value: 1000.44

The syntax is ok. But the logic seems doomed to fail: @Taewoo-Kim said in Why skip order.Margin status?: self.buysig = bt.ind.And( self.fast_ema > self.datas[0].close, self.datas[0].close > self.slow_ema, bt.ind.CrossUp(self.datas[0].close, self.fast_ema), self.regime > 0 ) self.fast_ema > self.datas[0].close, self.datas[0].close > self.slow_ema, These 2 place the close in between the fast_ema and slow_ema bt.ind.CrossUp(self.datas[0].close, self.fast_ema), And This one says that the close should have just crossed the fast_ema to the upside. Which looking at the previous statements is not possible (not possible at the same time)

After the different findings in this topic, the following will be the final commit The original behavior for the v7 feed will be retained A new parameter named swapcloses (default: False) will be added If swapcloses=True the allegedly adjusted and non-adjusted closing prices will be swapped, which will allow to place them in the right column. There seems to be no clear pattern to decide when Yahoo will be returning the adjusted price or the unadjusted (leaving aside that as seen above, sometimes it is impossible to reconstruct the prices with the given values)

@mac0 said in Calling data by date: Side question: is there a way to compute TimeReturn on each ticker without having to call addanalyzer(TimeReturn, data=cerebro.datas[x]) for each one of them? No. @mac0 said in Calling data by date: I manually cross-checked the number and they seem fine for all dates but the last , i.e. 31st of January 2011. To get to the result given by the analyzer I need to compute the result from the close of 31/12/2010 to the close of 28/01/2011. Why the last day isn't taken into account? I cheat-on-open so everything should be after the close. It seems your data would end on 2011-01-28. The analyzer doesn't know your data ends there ... and the end of the montha and/or next month has not been seen. It can only calculate it when stopping (stop method) and you can therefore only see that in the corresponding strategy stop method.

See this ... https://community.backtrader.com/topic/1584/extending-a-datafeed/

@Paska-Houso said in A question about next(): @beejaysea said in A question about next(): self.log('{}: Order ref: {} / Type {} @ {} / Status {}'.format( self.data.datetime.date(0), You are not logging the dates related to the order statuses. You are logging the actual time at which things are being seen. And this should let you easily answer the question posed above @Paska-Houso said in A question about next(): How do you get an order submitted, accepted and executed on the same date? Simply: you are logging things at the same point in time, but not logging the time at which they happened. This is what @ab_trader suggested as the most obvious explanation for the apparent mismatch in prices and execution.The mismatch happens because you compare the order price with the wrong prices. Okay. I have changed a few things around, and I think I see what's going on here, and where I need to make changes. Thank you.

@Michael-Scofield: the docs have the same version as the package. What is missing?

Thank you so much, @Paska-Houso . I managed to create a new indicator of OLS to be used in my strategy! :) Here is the code: class TORO_OLS_Slope_InterceptN(bt.Indicator): packages = ( ('pandas', 'pd'), ('sklearn.linear_model', 'lm'), ) lines = ('slope', 'intercept',) params = ( ('period', 10), ) def init(self): self.addminperiod(self.params.period) def next(self): p0 = pd.Series(self.data.close.get(size=self.p.period)) p1 = np.arange(self.p.period).reshape(-1, 1) p1 = sm.add_constant(p1, prepend=True) slope, intercept = sm.OLS(p0, p1).fit().params self.lines.slope[0] = slope self.lines.intercept[0] = intercept

Thank you very much for all your help, much appreciated!

@blonc said in passing data to strategy via an *args: the bellow issue: And what's exactly the issue? That's a well defined and documented behavior of the platform. It has also been discussed before by people who wanted to access data before all warm-up periods were fulfilled and worked using prenext and adding multiple checks.

@backtrader said in Best Approach for Live-Trading With Cheat on Open: So it seems that I have to supply the --replay parameter in oandav20test.py. I don't know. What you need is a data source which is tick based. You said you wanted to be notified of each price change. There should be no need to replay anything for that data feed. Hi, with samples/ibtest/ibtest.py I did some tests with Interactive Brokers livetrading. These are the results: ibtest.py --data0 EUR.USD-CASH-IDEALPRO --timeframe Seconds --compression 30 --port 7497 --no-rightedge ***** DATA NOTIF: LIVE LIVE, Data0, 0962, 736801.8864360515, 2018-04-17T17:16:28.074845, 1.23699, 1.23699, 1.23699, 1.23699, 0, 0, 1.23703 LIVE, Data0, 0963, 736801.8866241798, 2018-04-17T17:16:44.329133, 1.237, 1.237, 1.237, 1.237, 0, 0, 1.237046 LIVE, Data0, 0964, 736801.8866485074, 2018-04-17T17:16:46.431042, 1.2371, 1.2371, 1.2371, 1.2371, 0, 0, 1.237034 LIVE, Data0, 0965, 736801.8866486517, 2018-04-17T17:16:46.443504, 1.237, 1.237, 1.237, 1.237, 0, 0, 1.237002 LIVE, Data0, 0966, 736801.886811497, 2018-04-17T17:17:00.513344, 1.23694, 1.23694, 1.23694, 1.23694, 0, 0, 1.237006 LIVE, Data0, 0967, 736801.8868541777, 2018-04-17T17:17:04.200952, 1.23693, 1.23693, 1.23693, 1.23693, 0, 0, 1.236994 LIVE, Data0, 0968, 736801.8869536915, 2018-04-17T17:17:12.798944, 1.23694, 1.23694, 1.23694, 1.23694, 0, 0, 1.236982 LIVE, Data0, 0969, 736801.8871321745, 2018-04-17T17:17:28.219872, 1.23691, 1.23691, 1.23691, 1.23691, 0, 0, 1.236944 LIVE, Data0, 0970, 736801.8871946137, 2018-04-17T17:17:33.614623, 1.23699, 1.23699, 1.23699, 1.23699, 0, 0, 1.236942 LIVE, Data0, 0971, 736801.8871946996, 2018-04-17T17:17:33.622046, 1.23698, 1.23698, 1.23698, 1.23698, 0, 0, 1.23695 LIVE, Data0, 0972, 736801.8871947962, 2018-04-17T17:17:33.630394, 1.23699, 1.23699, 1.23699, 1.23699, 0, 0, 1.236962 LIVE, Data0, 0973, 736801.8872731669, 2018-04-17T17:17:40.401621, 1.23698, 1.23698, 1.23698, 1.23698, 0, 0, 1.23697 LIVE, Data0, 0974, 736801.8872752264, 2018-04-17T17:17:40.579562, 1.23699, 1.23699, 1.23699, 1.23699, 0, 0, 1.236986 LIVE, Data0, 0975, 736801.8874047493, 2018-04-17T17:17:51.770338, 1.237, 1.237, 1.237, 1.237, 0, 0, 1.236988 ibtest.py --data0 EUR.USD-CASH-IDEALPRO --timeframe Seconds --compression 30 --port 7497 --resample ***** DATA NOTIF: LIVE LIVE, Data0, 0962, 736801.8892361111, 2018-04-17T17:20:30.000000, 1.23689, 1.23706, 1.23689, 1.23701, 0.0, 0, 1.2369620000000001 LIVE, Data0, 0963, 736801.8895833333, 2018-04-17T17:21:00.000000, 1.23702, 1.23703, 1.237, 1.23702, 0.0, 0, 1.23696 LIVE, Data0, 0964, 736801.8899305556, 2018-04-17T17:21:30.000000, 1.23701, 1.23707, 1.23699, 1.23707, 0.0, 0, 1.236974 LIVE, Data0, 0965, 736801.8902777778, 2018-04-17T17:22:00.000000, 1.23708, 1.23708, 1.23696, 1.23702, 0.0, 0, 1.237004 ibtest.py --data0 EUR.USD-CASH-IDEALPRO --timeframe Seconds --compression 30 --port 7497 --replay ***** DATA NOTIF: LIVE LIVE, Data0, 0962, 736801.8905911663, 2018-04-17T17:22:27.076771, 1.23694, 1.23694, 1.23694, 1.23694, 0.0, 0, 1.2369999999999999 LIVE, Data0, 0962, 736801.890625, 2018-04-17T17:22:30.000000, 1.23694, 1.23694, 1.23694, 1.23694, 0.0, 0, 1.2369999999999999 LIVE, Data0, 0963, 736801.8908331305, 2018-04-17T17:22:47.982471, 1.23693, 1.23693, 1.23693, 1.23693, 0.0, 0, 1.236982 LIVE, Data0, 0963, 736801.8908331448, 2018-04-17T17:22:47.983708, 1.23693, 1.23696, 1.23693, 1.23696, 0.0, 0, 1.236988 LIVE, Data0, 0963, 736801.8908638399, 2018-04-17T17:22:50.635766, 1.23693, 1.23698, 1.23693, 1.23698, 0.0, 0, 1.236992 LIVE, Data0, 0963, 736801.8908640771, 2018-04-17T17:22:50.656264, 1.23693, 1.23699, 1.23693, 1.23699, 0.0, 0, 1.236994 LIVE, Data0, 0963, 736801.8908658416, 2018-04-17T17:22:50.808718, 1.23693, 1.237, 1.23693, 1.237, 0.0, 0, 1.236996 LIVE, Data0, 0963, 736801.8908685311, 2018-04-17T17:22:51.041084, 1.23693, 1.23701, 1.23693, 1.23701, 0.0, 0, 1.236998 LIVE, Data0, 0963, 736801.8908700076, 2018-04-17T17:22:51.168654, 1.23693, 1.23702, 1.23693, 1.23702, 0.0, 0, 1.2369999999999999 LIVE, Data0, 0963, 736801.8908825091, 2018-04-17T17:22:52.248782, 1.23693, 1.23702, 1.23693, 1.23701, 0.0, 0, 1.236998 LIVE, Data0, 0963, 736801.890961202, 2018-04-17T17:22:59.047850, 1.23693, 1.23702, 1.23693, 1.23702, 0.0, 0, 1.2369999999999999 LIVE, Data0, 0963, 736801.8909623256, 2018-04-17T17:22:59.144933, 1.23693, 1.23704, 1.23693, 1.23704, 0.0, 0, 1.237004 LIVE, Data0, 0963, 736801.8909629615, 2018-04-17T17:22:59.199871, 1.23693, 1.23705, 1.23693, 1.23705, 0.0, 0, 1.2370059999999998 LIVE, Data0, 0963, 736801.890965801, 2018-04-17T17:22:59.445203, 1.23693, 1.23705, 1.23693, 1.23704, 0.0, 0, 1.237004 LIVE, Data0, 0963, 736801.8909722222, 2018-04-17T17:23:00.000000, 1.23693, 1.23705, 1.23693, 1.23704, 0.0, 0, 1.237004 LIVE, Data0, 0964, 736801.8909756911, 2018-04-17T17:23:00.299714, 1.23705, 1.23705, 1.23705, 1.23705, 0, 0, 1.2369999999999999 LIVE, Data0, 0964, 736801.8909989573, 2018-04-17T17:23:02.309913, 1.23705, 1.23705, 1.23704, 1.23704, 0.0, 0, 1.236998 LIVE, Data0, 0964, 736801.8910004616, 2018-04-17T17:23:02.439886, 1.23705, 1.23705, 1.23703, 1.23703, 0.0, 0, 1.236996 It seems to me, that the --replay parameter really delivers what I need: tick based during live streaming after each candlestick timeframe, len(self.data0) increases by one and also the last call to next() for that block seems to comprise consistent values for OHLC for the whole candlestick.

The logic cannot be elsewhere but next, because it is what will be called on a regular basis. The difference between creating and operating with indicators is explained here: Docs - Platform Concepts - Stage 1 and Stage 2 You may also look at the lifecycle of the Strategy: Docs - Strategy

It appears that somehow I fixed this in the code, and this behavior stopped happening. I'm not exactly sure what I did, unfortunately, but here's some stuff I added that seemed to help get clarity and prevent orders from getting placed on top of each other if len(self._orders) > 1: if datetime - bt.num2date(self._orders[-1].created.dt) < timedelta(minutes=90): print("Orders placed too recently, let's not place more ") self.recent_or_open_orders = 1 else: self.recent_or_open_orders = None elif len(self._orderspending) > 0: self.recent_or_open_orders = 1 print("Current time: {}".format(datetime)) for order in self._orderspending: print("Order {} created at {}".format(order.ref, bt.num2date(order.created.dt))) else: self.recent_or_open_orders = None pos = self.getposition(data).size print(self.recent_or_open_orders) print(pos) if self.recent_or_open_orders == None and not pos: # no market / no orders / no recent orders

You have to check the length of the data feed. It changes when a new bar is delivered. This can happen for both data feeds at the same time, but with different timeframes, it will obviously happend a lot more often for the smaller timeframe

@backtrader said in Matching of stopLimit orders: @sandro-böhme said in Matching of stopLimit orders: Somehow from the notify methods I assumed that everything will be handled asynchronously but it doesn't That's a huge mistake. You may think it's an advantage short-term ... but it isn't. The notify_xxx do simply let you know how things have happened. They imply nothing. That was indeed a big mistake. Thanks for your support @backtrader!

The problem is difficult to comprehend, because things seem to work like they: Snippet1 self.b_bands = bt.ind.BollingerBands() self.rsi = bt.ind.RelativeStrengthIndex(period=self.params.rsi, upperband=70, lowerband=30) Two (2) indicators are declared in the __init__ method of the Strategy and two (2) indicators show up in the char BollingerBands which defaults to plotting along the data (because the values from this indicator are meant to be in line with the value) RSI which defaults to be plotted on a subplot because it has fixed values ranging from 0 to 100 Snippet 2 # self.b_bands = bt.ind.BollingerBands() self.rsi = bt.ind.RelativeStrengthIndex(period=self.params.rsi, upperband=70, lowerband=30) self.bb = BBandsIndicator(mode=self.params.mode) And again two (2) indicators there. The story of RSI is already known. BBandsIndicator is a direct descendent of Indicator and like most indicators the default is to plot on a subplot Both charts are ok

The idea is always to have a generic model, like it is the case with the timezones, in which you may pass pytz instances or something that, more or less, complies to the interface of pytz. A similar approach will be taken.

Only if you want to use: def pretty(d, indent=0): for key, value in d.iteritems(): if isinstance(value, dict): print '\t' * indent + (("%10s: {\n") % str(key).upper()) pretty(value, indent+1) print '\t' * indent + ' ' * 12 + ('} # %s #\n' % str(key).upper()) elif isinstance(value, list): for val in value: print '\t' * indent + (("%30s: [\n") % str(key).upper()) pretty(val, indent+1) print '\t' * indent + ' ' * 12 + ('] # %s #\n' % str(key).upper()) else: print '\t' * indent + (("%10s: %s") % (str(key).upper(),str(value))) tradeAnalyzer = strat.analyzers.getbyname('TradeAnalyzer') pretty(tradeAnalyzer.get_analysis())