To me it would seem sensible to try a from parameter.
The problem is the limit=6, which seems arbitrary. Backfilling is difficult, because you may know what you want, but APIs have to cope with facts like non-trading hours. That's why you usually says from => to and get the number of bars that are available, regardless of non-trading days and non-trading hours.
@Tim-Brug said in Plotting Problems:
How do I get access to the portfolio time series information directly?
What's exactly the meaning of portfolio time series? A "per-timestamp record of the portfolio value"? If so, that's not stored.
You would need to plug in an analyzer which records that.
To me it would seem your code does not work properly. But I cannot know, neither can anyone, because there is no code (which would let people understand how you have configured things) and no logs beyond an isolated line (which lacks information such as ... size for example)
As far as the story goes, you say you stared with a portfolio value of $100k (all in cash), have made a trade in the wrong direction and the value of your portfolio is $5k. It is what usually happens when one makes a trade in the wrong direction. You can even go negative (in real life ... too)
@MarkWhatson said in It seems like 'margin call' does not work properly.:
if my position should be sold by force?
If you are implying that the simulation broker is going to liquidate your positions, I would kindly ask for a pointer to where you have read that will happen. It is not a functionality of the broker.
@swibby Hey did you ever find a solution to this? I have been plugging in the spread (ask - bid) as the open-interest value as this always yields the most recent value (see dataseries.py, line 206) which is what you would want when making decisions/ penalizing based on the spread and resampling to higher timeframes
The calendars are not there to filter out some data points for you. Second sentence in the documentation for calendars:
This is useful when resampling in for example the following scenarios
From: Docs - Trading Calendar - https://www.backtrader.com/docu/tradingcalendar/tradingcalendar/
If you provide data that has price points for day X and you want to consider this a non-trading day, you will have to manually do it.
You may remove the "non-trading" days by implementing a specific filter
Docs - Filters - https://www.backtrader.com/docu/filters/
I've encountered the similar issue and it seem to be a bug in backtrader code. In my case the 'minimal fix' was to just patch the ibdata.py 'reqdata' method to issue the subscription request only in case the feed status wasn't _ST_LIVE. Please see my post here. However a more proper fix should avoid multiple feed initializations altogether (it's more involved though).
You can always read a CSV as a data feed and use the value as an indication to trigger something.
Given the lack of information about the content of the CSV (timestamp or not, for example) it is difficult to judge if that's the best way.
The same is true for a "webhook". Just like a data feed for Interactive Brokers waits for events to feed the data to the strategy, a data feed could wait for a "webhook".
I am revisiting this old thread as it seems to be a good jumping off point for a problem I'm stuck on. How might we extend this code to incorporate multiple unique symbols?
@backtrader said in Strategy execution on different timeframes and multi-data:
next is called for any tick which any data produces. Concentrating on a specific data is a matter of looking at the len of the data.
When the len of the data changes (it will always go up) you know you got a tick of that data
self.lendata1 = 0
if len(self.data1) > self.lendata1:
self.lendata1 += 1
I am trying to run a test across multiple symbols by evaluating trade signals on one time frame and completing executions on another.
When using the aforementioned code within an enumeration, only trades for the first added data feed are acted upon.
This is a snippet of the code I am working with, which parallel's that @backtrader outlines above:
self.datas.len = 0
for i, d in enumerate(self.datas):
if len(self.datas) > self.datas.len:
self.datas.len += 1
It seems like something else needs to be done other than just wrapping this in enumerate(). I have tried many different versions and have been stuck on this problem for the last several weeks, so any help is appreciated. If needed, I can create a unique thread for this problem.