There was another thread which already addressed this problem, which is due to the rounding around midnight.
The sample might be in need of refreshing, due to the stricter usage of sessionend when for example doing resampling operations. ibtest was created long before that was done to actually be safer in synchronizing data feeds.
? I am already placing trade w/ price=self.data.open 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.
By the way: There is a little bug in another blog post regarding this topic:
import pyfolio as pf
I didnt want to open a new topic for this..
@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.
Upon further examination, the reason not to pass **kwargs with Oanda, unlike with Interactive Brokers, is:
With Interactive Brokers the order object gives a hint as to where the key in **kwargs is actually present in the order and can therefore be applied
With Oanda the order is simply a dictionary of values to be filled. The end user could actually be sending anything and this would be in the JSON sent to Oanda (whether that's simply digested with no complain by Oanda is something untested)
Looks like it's my mistake. I've wrongly assumed that it's rounding currency calculations to 2 decimal places - but it's not.
I've corrected numbers format printing and it's OK.
So thank You for inspirational question.
And I'm sorry for bothering with simple problem.
It doesn't seem to be a problem. Your timeframe is daily and the resolution plays an important role:
timedelta(0) - You are basically expiring the order on creation. No surprise.
timedelta(1) - You ask for the order to expire on the next day. The next day is actually the first chance for the order to be evaluated. The broker tries to evaluate and sees you asked for the order to be expired.
To simulate a raw tick data one can assign the value of the tick to the fields of the OHLC. See
Community - backtest with tick data, get period datas
With that in mind the value of close (for example) can be used as the tick value (And has to be added with addata)
The 2nd stream, the resampled one, is created, as already present in the code, by issuing resampledata.
The tick data would be in data0 and the resampled in data1