@backtrader Thank you for the reply. I guess I'll just read the web cache version of algotopian whitepaper.

@Ed-Bartosh Yes you're right, I don't think ccxt knows when the transition between daily candles occurs for each exchange. The conservative approach of regularly fetching ohlcv without trying to guess when a new ohlcv occurs is safer.

OCO orders are all active at the same time. Bracket orders (the ones you submit with parent) have a different lifecycle: parent is 1st alive. children are inactive If the parent is cancelled the children are simply discarded (they weren't active) If the parent is executed, the children are activated Both children behave now like OCO orders

Haha - it was hiding in plain sight! or I was just being blind! Thanks a lot guys!

after testing and debugging there is some limitation that should be noted: for both data feed to be properly synced both need to invoke the filter mechanism, otherwise the conversion filter doesn't get any data form the currency rate data. to solve this I resampled the currency rate data feed (which is a filter). first raw of main data get called prior to currency data so there is no rate reference. making the data not consistence to the conversion trying to delete the raw to solve problem (2) just make it propagate to the next raw causing problem (2) recursively. so a workaround i used is to change all values to 0 in the main code: data.addfilter(CurrencyConverterFilter, rate = data_rate) filter: class CurrencyConverterFilter(): def __init__(self, data, *args, **kwargs): self.currencyRate = None if 'rate' in kwargs: self.currencyRate = kwargs['rate'] def __call__(self, data, *args, **kwargs): bar = [data.lines[i][0] for i in range(data.size())] if len(self.currencyRate): rate = self.currencyRate[0] # adjust data with new rate bar[data.Open] = bar[data.Open] / rate bar[data.Close] = bar[data.Close] / rate bar[data.High] = bar[data.High] / rate bar[data.Low] = bar[data.Low] / rate # update stream data.backwards(force=True) # remove the copied bar from stream data._add2stack(bar) # bar is ready to be proceesed return False # bar couldn't be converted due to rate data havn't been initialized # can happen if data feed for currency: # 1. was not passed at all # 2. was pass for future date (no rate reference was given yet) # 3. wasn't initialize by the system (can happen in first iteration) #data.backwards() # remove bar from data stack #return True # tell outer data loop to fetch a new bar # unfortunately removing bars cause the sync between data feeds to fail so data need to be removed manualy bar[data.Open] = 0 bar[data.Close] = 0 bar[data.High] = 0 bar[data.Low] = 0 bar[data.Volume] = 0 # update stream data.backwards(force=True) data._add2stack(bar) return False

@hlad said in How to code a trading system that works with Backtrader?: Is each feed capable of storing such state variables? Why shouldn't? The statement of problem is really unclear. You can store things in additional lines defined for the data feed and you store and access the entire history. You can add your own attributes and store as many as you like in for example a list or just the last value in a simple instance attribute.

@HONGYI-ZHENG Any chance you could share an example of how you did this? Any unexpected downsides?

@backtrader, ok. I'm going to deep-dive in the platform once again from the beginning, so then hopefully those questions/topics will be clearer. Don't you consider having a discord channel for very interactive chats? Thanks anyway.

Really nice discussion. Check out this talk by John Reese on multithreading out of GIL and asyncio (be warned that your laptop may spontaneously combust :P ) : https://www.youtube.com/watch?v=0kXaLh8Fz3k&feature=youtu.be&t=10m30s To learn more on asyncio : https://realpython.com/async-io-python/#the-asyncio-package-and-asyncawait To learn more on GIL : https://realpython.com/python-gil/ Keep the good work guys ;)

No. Different lengths are perfectly supported. You can simultaneously trade the SPX and the DAX, which have different trading calendars and different lengths. Your concrete problem is the warm-up or minimum period which is needed to ensure all buffers can produce something at [0]. If you have things starting at different dates, the buffers cannot be guaranteed to deliver until the latest date has been reached.

Just a not on this issue, we tried to recreate the problem to implement a fix but could not recreate the problem. The Jupyter issue has popped up from time to time and as best we can tell it's an installation issue with Jupyter. If someone has the problem again please let the community know as well as how your Jupyter was installed. Here is the link to github.

I figured it out, I think! Since I was placing limit orders in both directions, and limit orders executed at your defined price or better, both long and short brackets were trying to execute simultaneously. I changed these to 'Stop' orders (which is kind of like market-buy-if-touched, for this purpose, right?) I get normal cancellation behavior, or like I would expect: *SUBMITTED* 185.56 LL_style open long trade (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *SUBMITTED* 182.78 LL_style close long trade SL (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *SUBMITTED* 186.95 LL_style close long trade TP (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *SUBMITTED* 184.01 LL_style open short trade (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *SUBMITTED* 182.63 LL_style close short trade TP (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *SUBMITTED* 186.77 LL_style close short trade SL (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *ACCEPTED* 185.56 LL_style open long trade (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *ACCEPTED* 182.78 LL_style close long trade SL (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *ACCEPTED* 186.95 LL_style close long trade TP (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *ACCEPTED* 184.01 LL_style open short trade (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *ACCEPTED* 182.63 LL_style close short trade TP (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *ACCEPTED* 186.77 LL_style close short trade SL (184.62, 184.95) 2018-09-14 2018-09-14 14:45:00 *COMPLETED* 184.01 LL_style open short trade (184.62, 184.95) 2018-09-14 2018-09-14 16:00:00 *CANCELING* LL_style open long trade LONG 2018-09-14 16:00:00 *COMPLETED* 183.27 LL_style open short trade (184.05, 184.45) 2018-09-13 2018-09-14 17:00:00 Until I find out later that something else mysteriously is going wrong, I think that solves it :) Hopefully this trail of tears helps someone in the future

Regardless of the joke, you seem to completely miss the point, because you post the chart from the main page. To what purpose, unknown. If you do something and the results are not the expected ones ... a chart IS NOT the answer. Any attempt at being profitable at algotrading will require producing lots of information. How do you think that I quickly identified the problem and why the actual data delivered by Yahoo doesn't match what is displayed as an example on the main page? 0242,2011-12-15,21.44,21.57,21.29,21.30,smas,21.31,21.39,crossover,0.00 0243,2011-12-16,21.40,21.81,21.36,21.67,smas,21.38,21.38,crossover,0.00 0244,2011-12-19,21.69,21.77,21.22,21.28,smas,21.36,21.36,crossover,0.00 0245,2011-12-20,21.55,21.75,21.51,21.70,smas,21.39,21.35,crossover,0.00 As you may see the first thing was producing output to understand that the moving averages were converging during two days to have exactly the same values 21.38 and 21.36. That's why the original definition of the CrossOver indicator is not able to cope with the scenario, because when sma1 > sma2, the condition for the previous day isn't met (it was sma1 < sma2), because the moving averages had exactly the same value. Hence the need to change the definition and make the crossover formula consider the last non-zero-difference between the input data feeds, which as shown in the data is -0.08 from 2011-12-15 where the values are 21.31 and 21.39 You have to consider additionally that the input data will keep on changing, fact which you apparently ignore because you seem fixed on the chart from the main pge, because the prices will be adjusted for dividends and splits. In one year, the prices from MSFT may be halved or doubled and bear no apparent relationship to the chart from the main page. This adjustment is what actually created the no-difference conundrum which shows that the simple formula to define a crossover (present in the documentation) was too simple and needed to be extended.

@cwse said in Make an Indicator off a Custom 'Line': I am sorry this is turning to be a difficult to answer, it must be very complex process to add a line to an indicator in Backtrader IT IS NOT. Your code is broken and you are the only one making things difficult. @cwse said in Make an Indicator off a Custom 'Line': I am passing many lines into my strategy at present and do not need help with extending data feeds, this process works just fine thank you. Apparently YOU NEED HELP. If if works so smoothly, can you please say why this happens @cwse said in Make an Indicator off a Custom 'Line': For example, if my line is called 'X'; this doesnt appear to work? for i, d in enumerate(d for d in self.datas): self.smaX[d] = bt.indicators.SimpleMovingAverage(d.lines.X, period=5) I get this error: AttributeError: 'Lines_LineSeries_DataSeries_OHLC_OHLCDateTime_Abst' object has no attribute 'X' Because the translation to plain English is: "data feed d has no line with the name X". @cwse said in Make an Indicator off a Custom 'Line': I just didn't want to copy my over 2000 lines of code as I think it is distracting from the question at hand Posting, reposting, non-working snippets, broken code is a lot easier than doing something simple. Of course ... because you have 2000 lines. You can only do complex things Doing this was very difficult for someone who can write 2000 lines of code class GenericCSV_X(bt.feeds.GenericCSVData): lines = ('X',) params = dict(dtformat='%Y-%m-%d', X=4) # X same as close class St(bt.Strategy): def __init__(self): bt.ind.SMA(self.data.lines.X) # or self.data.X cerebro = bt.Cerebro() cerebro.adddata(GenericCSV_X(dataname='../../datas/2006-day-001.txt')) cerebro.addstrategy(St) cerebro.run() And it works ... Holy Cow! A total of 10 code lines + 2 blanks. You can add the import backtrader as bt. @cwse said in Make an Indicator off a Custom 'Line': Given it appears to not be a straightforward process to pass a line to an indicator IT IS STRAIGHTFORWARD. Your code is broken. But you prefer to post, repost and remix broken questions and broken snippets rather than asking straightforward questions and presenting straightforward code.

This help could not run on Colab anymore.

@ab_trader that did the trick. so silly i missed that. I will do some more testing as i need to verify it's working the way i intend.

Hi @Rodrigo Brito, On another note, have you faced any other major/minor issues/bugs while running the Backtrader+CCXT live so we need to be aware of before go live? Any special error handling or Binance broker specific issues we might face? Thanks

@pipeline-punch said in Struggling to implement custom Pandas data feed: If the custom Pandas DataFrame contained the same columns as we have been working with, but multiple "assets" instead of just one (as in the example we've been working with) - how would everything work? Similar to how we've done it above, or something a bit different to deal with the dual-indexing? bt's PandasData requires separate DataFrame for each stock ticker. But since Now that I know the structure of how to do this, I feel confident I can now pull in any custom Pandas data frame I would like! than you can write your own Pandas data feed which will take care about multiple assets in the single DataFrame. It depends on the amount of time you have and your python skills.

atom.io , with some plugins for python installed, linter, linter-python, autocomplete-python, bracket-colorizer , file-icons, minimap, python-autopep8

@B-U I believe that it is easier to count bars for which condition not self.position is True and reset the counter every time the position exists. Something like def __init__(self): outofposition = 0 def next(self): if not self.position: outofposition +=1 else: outofposition = 0