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
Thanks for the reply!
Actually the output in question is generated by Writer cerebro.addwriter(bt.WriterFile, csv=True).
So my question is how can I get a date-only print out when using writer?
@Taewoo-Kim said in Charts & TradeID:
Are only completed trades shown in the chart? (i.e. open positions don't show?)
Currently, I am passing a tradeid (generated by str(uuid.uuid4())[:8]) to every order, so that I can keep references to them in an internal dict. If order is long, i would call self.sell(tradeid=some_tradeid). I've noticed in other forum posts that this isn't how people close out their positions. Is my understanding incorrect?
tradeid has no specific requirements. It is just an identifier. It would seem simpler to use something like mytradeid = itertools.counter(1) and then use mynewtradeid = next(mytradeid) to have a unique reference which is a lot more palatable for human consumption. But any tradeid will actually do.
If you use the tradeid and want to undo a buy(tradeid=x), you should either do sell(tradeid=x). Of course sell doesn't guarantee you close a position unless you specifiy the same size or have a sizer that does it for you. You may also use close(tradeid=x), becauseclose` calculates the right size for you.
TypeError: unsupported operand type(s) for /: 'LinesOperation' and 'LinesOperation'
The error is generated because you, likely, are not using this:
from future import division
and the code is likely being run under Python 2.7.x (a chain of assumptions here)
That means that the / operation is using the old division style. This was also uncovered by another use case a few days ago and support for old style division has been added to the development branch.
This other error
---> 14 self.lines.RET = math.log(self.data.close) - math.log(self.data.close[-1])
happens because the statement is wrong. math.log is not a built-in operation and cannot be overridden. Furthermore, during the __init__ phase, one uses de delay notation which would be self.data.close(-1) (notice the round parenthesis rather than the square brackets)
This is a calculation which has to happen in next.
In any case, backtrader already contains an Analyzer which calculates logarithmic returns. It defaults to do so using the same timeframe as the data under analysis. But you can for example calculate weekly logarithmic returns of daily data.
See Docs - Analyzers Reference and look for LogReturnsRolling. It doesn't calculate the sign, but you can probably simply extend it to do so.
first need to reverse those ticks because lower ticks have an old timestamp.
Your ticks are in the wrong order. The resampling process can only work forward. That's the reason your ticks are not being resampled.
The more recent timestamps are at the top of the file and most of the world (Yahoo being an exception) works with files which have the more recent timestamps at the bottom.