@vladisld said in How to make Market order valid.:
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.
@dasch :facepalm: Thank you so much! It's so obvious now, the only reason it was working before with non-live data was because preload parameter defaults to true with non-liva data. If I manually set preload as false when using GenericCSVData, the same behaviour occurs & the current value of the indicator is alway nan.
Updated my strategy so it now looks at the indicator values in the past, it is working as intended.
I suspected that this could be a timezone mis-match issue so I tried changing IB's timezone to UTC (GMT+0) and setting the expiry time works fine now.
I think what happens is this:
Backtrader's does this (pseudocode):
dt = current date & time in UTC
expiry_date_time = dt + valid
place order with expiry_date_time
Order reaches IB. On IB's end, expiry_date_time is interpreted in the user's IB client's timezone (e.g. for someone running IB in australia, expiry_date_time is assumed to be in australia's timezone).
@vladisld Had the same issue. problem is that arange returns numpy datatypes which causes this operation to return a numpy array:
stddev = self.p.devfactor * StdDev(self.data, ma, period=self.p.period,
Converting self.p.devfactor to a standard float fixes the problem