The problem here is that the broker, being unaware of the order being issued during next_open, tries to see if you are submitting an order which exceeds your current cash reserves (and the current price is already the close) You can disable the submission check with checksubmit=False. See Docs - Broker And this other topic for example: https://community.backtrader.com/topic/782/help-with-simple-bband-strategy

@yi-fang said in I want to apply multiple filters to a stock universe of 193 stocks: Even if it was another indicator, the original data info should be pass by. An indicator can have many inputs and these can belong to multiple data feeds, indicators and ...

Ok, thanks once again.

@ab_trader Thankyou for sharing, your information and code is verry help me 🙂

See: Community - Release 1.9.44.116 For Cheat-On-Open see Blog - Cheat On Open

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/

Hi, very nice tool kit -- thanks for sharing! Is it still available? It seems like the links above are dead, unfortunately.

@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