@ab_trader If I can use the fractal indicator to reference the true/false for any candle, like fractal[-14] to find out if 14 candles back was a high or low, then it will work, because I have to be able to get the high/low value from the fractal, not just knowing whether or not it is. I'll mess around with it, definitely looks cleaner than my method lol.
File "/home/user/PycharmProjects/backtrader/Strategies/VixLive.py", line 615, in notify_timer
self.initial_position = self.position.size
File "/home/user/PycharmProjects/backtrader/venv/lib/python3.8/site-packages/backtrader/lineseries.py", line 461, in _ _ getattr _ _
return getattr(self.lines, name)
AttributeError: 'Lines_LineSeries_LineIterator_DataAccessor_Strateg' object has no attribute 'position'
The error backtrace above seems strange. Accessing the position property in the strategy should call the bt.Strategy's getposition method:
def getposition(self, data=None, broker=None):
data = data if data is not None else self.datas
broker = broker or self.broker
position = property(getposition)
This should be reflected in the error backtrace. It looks like the self.position was called from the indicator and not from the strategy.
It could be useful to if you could share the whole VixLive.py code?
By default data0 is used as the "primary", correct?
vx2_1_min = cerebro.rolloverdata(*rollfeeds_vx2_minute, **rollkwargs_vx2_minute) -- is data0 since it's called & added first.
@Laurent-Michelizza Thank you very much! when I log the position,I also find this question and use almost your way to solve it.
But in the future,I guess,we do a auto-close function when the future expires, it is more easy to use. After this four times reading the source code,I maybe try this function.
Thanks again for the long reply!
I just tried cheat on open, but the result is the same.
I thought about including a buy margin and it seems this is the way to go... for that example...
Hence, i assume the orders are not done by theirs reference numbers otherwise order 75 would not be canceled?
Here is the approach - compare length of the daily data feed on each next() call. This will help to avoid excessive next() calls due to resampling. You might be able to come up with the only next() call at the end of the week.
@ed-bartosh ccxt had some unique properties that made it possible to implement the broker straight from BrokerBase and give access to more then 1 exchange simultaneously in a way that feel very integrated and easy to use. remember that ccxt project is all about unifying the variety of exchanges under one api.
and a key part of my development was that the feed had some exchange info inside it.
but to make a more generic broker means to really create a broker that hold a collection of brokers inside (that are not really unified) and switching between them like you proposed before.
The biggest problem this way, is that there are still methods that will get called by Backtrader in the background on the 'active' broker without the intention of the user.
A better solution that may work more like what i wrote is if every feed will hold some broker information in a well known way and then you don't need to guess on what broker.
So if some old bar is stored in the order, and somehow referenced in the future - will it still be in memory at the time of reference? IMHO worth to take a look.
I created a script to check this. I ran a simple moving average from the beginning of the year with period=22 so that the min period would start at the beginning of February. I then made an order with no exit.
Next I added the bar length to the order using self.o.obar = len(self)
Next I ran the script to the end of the year and printed out the self.o.obar and the actual length using len(self).
Then I ran the script using all of the possible variables for exactbars:
With the default False value each and every value stored in a line is kept in memory
True or 1: all “lines” objects reduce memory usage to the automatically calculated minimum period.
If a Simple Moving Average has a period of 30, the underlying data will have always a running buffer of 30 bars to allow the calculation of the Simple Moving Average
This setting will deactivate preload and runonce
Using this setting also deactivates plotting
-1: datas and indicators/operations at strategy level will keep all data in memory.
For example: a RSI internally uses the indicator UpDay to make calculations. This subindicator will not keep all data in memory
This allows to keep plotting and preloading active.
runonce will be deactivated
-2: datas and indicators kept as attributes of the strategy will keep all data in memory.
For all input parameters for exactbars the results were the same. The bar length references held steady for the order and the length of the bars run. This would seem to indicate you could use the self.o.obar method to keep track of the starting bar of the order and make use later on in the order's life.
As a side note, I have made extensive use of adding information to orders as attributres when I will need to evaluate that information bar by bar over the order's life. This has been very convenient.