There isn't enough information to even attempt anything. For example: the only provided output is from the modified source, without having the actual command line execution As such one can only try to point the low hanging fruits. One would be: Are you pointing to the right port? (usually 7496 for production and 7497 for paper trading) The default port used by the sample and the IB ecosystem is 7496. You quote above the following command: ./ibtest.py --data0 EUR.USD-CASH-IDEALPRO --resample --timeframe Minutes --compression 1 and this is theoretically working with the demo. But the demo also runs (default, can be of course be changed) on port 7497. Cash Products like EUR.USD-CASH-IDEALPRO are allowed (afaik) to all IB customers (as long as your account is funded I think). Whether demo, paper trading or real account, that product is available for everyone. And the code (which relies on IBPy for interfacing to TWS) doesn't know what it is connecting to. The account type is controlled by the TWS (or IbGateway) instance you connect to.

You are absolutely correct. Thanks for your help.

Such calculation is probably what's already being done: the unleveraged value. The idea seems to be to swap the current value with the current unleveraged value, so that the actual value curve doesn't spike. The leveraged value would still be accessible. It makes sense

You may post code snippets. That's what this is for. In any case this is not a code check service.

@steffen Is there a quantitative trading platform support the new python3 tws api? I'm looking for something could backtest and trade using Interactive Brokers, just like the BackTrader, but the ibpy is too old to use.

@backtrader you are welcome. Feel free to make any suggestions for further improvement.

The idea of capturing your own ticks is in theory sound, but has always practical problems. And that's why companies that collect and curate data make money out of it. Collecting ticks or minute bars or anything else with backtrader is just a python statement away (see for example the trace that run with 2 instruments collecting 1-minute bars during approximately 35 minutes) The data points could have been stored somewhere (hierarchically or not) instead of simply having printed them out.

Actually, weekly indicator value is correct but the presentation on the graph is wrong.

Thank you for the post! Currently I am looking on the testing couple ideas for american futures. The way that I think to go forward is to use back-adjusted prices and have continuous contacts. I've checked Quandl already and their continuous contracts are not suitable for me. I was thinking to chain data series based on max volume to match reality, so in the continuous contract I have prices only from the months with max volumes, but Quandl just chains contracts based on expiration months. backtrader makes continuous contracts based on certain conditions (date and volume), but does not shift prices. As a result you will have gaps between contracts. So to make this shift ones need to re-write bt rollover method or just write a strategy which will make it and save prices into csv files. I am not a super-python guy, so I will probably go second way. I don't think that adjusted prices in the past will harm the tests. I am going to use dollar value stats, no % stats. Also trades price delta will be the same as for real prices.

Thanks @backtrader, yes I understand the definition of prenext() as your quotes above show.. but they don't show how to use it to manage differing timeframes :-) The sample code looks like it is useful though! It appears all I need after all is this?! def prenext(self): self.next()

Use next_open and cheat_on_open See: Community - Release 1.9.44.116 For Cheat-On-Open see Blog - Cheat On Open

My hack above worked today, so I will take your much more elegant bit of python and replace a few lines. My python foo is still a bit green... Thanks!

@backtrader How to read dataset in following cases: When there is no time column: Date,Open,High,Low,Close,Volume 12/29/2000,30.87,31.31,28.69,29.06,31655500 12/28/2000,30.56,31.12,30.37,31.06,25055600 12/27/2000,30.37,31.06,29.37,30.69,26441700 When time is in separate column: "Date","Time","O","H","L","C","U","D" 01/02/2006,1530,2821.10,2836.70,2804.00,2819.80,0,0 01/03/2006,1530,2823.00,2872.00,2815.10,2868.70,0,0 01/04/2006,1530,2885.00,2896.00,2873.30,2890.40,0,0 01/05/2006,1530,2892.30,2895.80,2868.00,2886.00,0,0 For "1" case I am trying in this way but is it not working: bt.feeds.GenericCSVData( dataname='orcl-2000.csv', fromdate=datetime.datetime(2000,12,29), dtformat=('%m/%d/%y'), datetime=0, open=1, high=2, low=3, close=4, volume=5, openinterest=-1) It is giving me this error: data_string[found.end():]) ValueError: unconverted data remains: 00

@jf not sure what to answer. I just wrote a code posted above. Within the strategy I defined self.sl_price variable which kept stop price calculated for every open position. This variable can be obtained from observer using self._owner.sl_price name.

@Roman-Semko said in Backtesting oanda/forex: I guess my question is whether the size calculation takes into the account that the price/margin needed for one unit of a currency pair depends on the currency pair being traded. That's why custom sizers can be used. You override _getsizing and then provide the actual exchange rate, which may actually be dynamically fetched from somewhere. Or else directly in the CommissionInfo object.

@asuralm said in How to correctly trade on data1 and data2?: Am I using the bt.observers.BuySell._stclock=True correctly? There is nothing right or wrong about it. It was a hack. @asuralm said in How to correctly trade on data1 and data2?: Yes they are indeed different data feeds but it seems the plotting is not correct when multi data feed the testing engineer no matter what. If each example you present has different feeds, different logic (summary: everything is different) there is no way to discern where a/the problem may be.

@ab_trader In theory yes, because there was a use case with spreads (which oscillate around 0). The problem there was that some of Python tests for existence would fail because the price was zero. It was dealt with a long time ago.

That's all in the link above: Docs - Platform Concepts There is a section about indexing and how 0 is the current point in time. Last is the last produced value before the current point in time and addressable with -1