@taewoo-kim whats the final script to convert dukascopy data?

Release 1.9.56.122 contains an exception for volume fields which are not convertible to float.

@suresh_trader said in Cancel Order: How to cancel all the pending stop and limit order by end of the day which is not executed due to the market price not reaching the order price level By keeping the references when created or notified as "Accepted" and then canceling them if the system has not notified completion or cancellation.

@backtrader sorry I've missed them, now everything makes more sense.

So after playing with live data around, the only solution with oanda data, that seems to be working would be the way below. If anyone is trying to achieve the same, don't change the session.py as i wrote above since this will most probably generate wrong data. When doing this, you will need to use data[1] in your strategies. datakwargs = dict( timeframe=bt.TimeFrame.Seconds, compression=5, qcheck=0.5, bidask=True, backfill_start=True, backfill=True, bar2edge=True, adjbartime=True, rightedge=True, ) data = store.getdata(dataname="EUR_USD", **datakwargs) data.resample(timeframe=bt.TimeFrame.Seconds, compression=5) data_filled = data.clone(filters=[btfilters.SessionFiller], timeframe=bt.TimeFrame.Seconds, compression=5) cerebro.adddata(data) cerebro.adddata(data_filled)

I can confirm that backtrader is by far the best option compared to zipline, and quantconnect. The zipline code is a mess, they implemented it, then decided to create a new library to implement basic statistics which they got wrong then created a new library to implement the risk metrics. It is inefficient and Quantopian holds back enough code to just make zipline unusable. Quantconnect has a better architecture but it also has a lot of old legacy code.

@richard-o-regan Good afternoon. I just joined BackTrader. Long-time futures trader; technical. Years ago with aid of programmers created own linux-based backtesting and then real time trading. Now looking for back testing platform. Found QuantConnect on IB site, but others recommended Backtrader. I will be working with programmer, but based on number of years experience backtesting tens of thousands of iterations, what we did was to rather than merely take output, and rearrange, place all output into a large spd sheet. That included say all 500 iterations for a test, along with all the indiv vars, and columns such as you suggest, % pft tdes, etc. However, with spd sheet, could easily sort on columns, as well as sub-sorts. Regards,

Many thanks and thank you for your patience

the problem is solved on another line: self.buy(data = ticker_data,...)

I've played a bit with boundoff, daily and resampled weekly data trying to get shifted weekly bar, but wasn't able to make it. Maybe it should be same timeframe specified for both original and target bars in order to force it to work.

Not mine.

The referenced link from above seems to indicate so. But for backtrader there is no distinction as to what is a live and a paper account. Everything is a TCP connection. Data delivery, trading and everything is controlled by TWS. Things that could help in diagnosing your problem: Run ibtest.py against your live account. As long as you don't provide the --broker (create an IBBroker) and --trade (engage into actual trading) nothing will be done If you don't want to blindly trust not using the options mentioned above, you can also: Set the API to read-only in the TWS settings. Even if backtrader wanted to issue orders, these would be rejected. or Remove the trading code from ibtest.py You can also show: The command line you used to run ibtest.py The output the command produced

@btr said in Programmatically extending a datafeed: I needed a break and coffee. It was silly Hilarious! Hope you had a nice break!

@backtrader Got it. Thanks a ton for that. I didn't understand it all, but it gives me enough to start researching / learning/ building. :)

@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.