This has been discussed here: Community - Reach _trades list

notify_trade was meant for users to collect trades if wished.

Uhh yeah.. option #1 seems a lot easier. ;)

Thank you

@backtrader thx I fixed it with your help !!!

@JohnShiu said in Extracting variables defined in strategy:

(1) Is it possible to extract the variables defined in the strategy, e.g. indicator_log, in analyzer?

See Docs - Analyzers

Each analyzer has automatically an attribute named strategy which obviously points to the strategy in which the analyzer is inserted.

Shifting is implemented with the (x) operators in lines objects.

See: Docs - Concepts and look for delayed. The use of the term delayed was meant to indicate that looking into the future is not possible. But it is possible for indicators to project values into the future (like Ichimoku does), although it is seldom used.

Basically:

newline = self.rsi + self.rsi(-1)

Notice how the first term doesn't use the (x) notation and with it it simply takes the current value. One could of course also do it formally as:

newline = self.rsi(0) + self.rsi(-1)

which is functionally 100% equivalent but not 100% memory equivalent because self.rsi(0) will create an extra buffer for the copies of itself.

RSI has a single line, so there is not much need to address the specific lines and by simply using the indicator itself the 1st line in the indicator is automatically used.

But for indicators with multiple lines like a MACD, one can also do things like:

newline = self.macd + self.macd(-1) # 1st line newline = self.macd.lines.macd + self.macd.lines.macd(-1) # the 1st line is also called macd newline = self.macd + self.macd.lines.signal(-1) # sum of present 1st line + delayed line "signal"

@backtrader
Sorry. I missed this commit :)
But it works !

Thanks

As with ta-lib the best approach would be to autogenerate indicators/functions for the things in those packages.

ta-lib provides that meta-information. In the case of standard libraries, the signature can be parsed but the return values cannot.

New changes have only uncovered a typo in the ta-lib integration by which auto-generated wrappers had the module itself in the __module__ attribute instead of the module name. Corrected in the development branch

In __init__

Operations like self.x = (self.data.high + self.data.low) / 2.0 generate a lazily evaluated lines object.

Even this generates that: self.y = self.data.close > self.data.open

In next

Here the [] operator is used to access the values provided by lines objects like the generated self.x or self.y or standard lines like self.data.high

if self.data.close[0] > self.data.open[0]: do_something()

Thanks to operator overloading the following is equivalent also in next

if self.data.close > self.data.open: do_something()

But unlike in __init__, this comparison generates a bool.

One can generate a complete indicator just by using operations and logic in __init__. See for example an old friend of everybody like MACD (removing documentation and plotting preparation boilerplate)

class MACD(bt.Indicator): lines = ('macd', 'signal',) params = ( ('period_me1', 12), ('period_me2', 26), ('period_signal', 9), ('movav', MovAv.Exponential), ) def __init__(self): super(MACD, self).__init__() me1 = self.p.movav(self.data, period=self.p.period_me1) me2 = self.p.movav(self.data, period=self.p.period_me2) self.lines.macd = me1 - me2 self.lines.signal = self.p.movav(self.lines.macd, period=self.p.period_signal)

No need to use scalar operations/logic in next. Everything is defined in terms of lines objects.

Some indicators may need next. Some help from things defined in __init__ can be used. For example the ZeroLagIndicator

class ZeroLagIndicator(MovingAverageBase): alias = ('ZLIndicator', 'ZLInd', 'EC', 'ErrorCorrecting',) lines = ('ec',) params = ( ('gainlimit', 50), ('_movav', MovAv.EMA), ) def __init__(self): self.ema = MovAv.EMA(period=self.p.period) self.limits = [-self.p.gainlimit, self.p.gainlimit + 1] # To make mixins work - super at the end for cooperative inheritance super(ZeroLagIndicator, self).__init__() def next(self): leasterror = MAXINT # 1000000 in original code bestec = ema = self.ema[0] # seed value 1st time for ec price = self.data[0] ec1 = self.lines.ec[-1] alpha, alpha1 = self.ema.alpha, self.ema.alpha1 for value1 in range(*self.limits): gain = value1 / 10 ec = alpha * (ema + gain * (price - ec1)) + alpha1 * ec1 error = abs(price - ec) if error < leasterror: leasterror = error bestec = ec self.lines.ec[0] = bestec

Here the base ema for the calculations is defined in __init__ but the core of the operations which is a loop over several values is best done in next.

The code by @randyt is 100% ok. Some versions ago and to reduce the number of needed imports, the main package gives direct access to subpackages, so you may also do

import backtrader as bt ... hi_bar = bt.indicators.Highest(...) ...

of for even less typing

import backtrader as bt ... hi_bar = bt.ind.Highest(...) ...

The final implementation, already pushed to the development branch, respects the original implementation by Ehlers and rather than expecting the price component to have high and low it takes simply self.data (which unless changed is the close from regular data feeds)

Using it for the midpoint of the bar is easy:

midpoint = (self.data.high + self.data.low) / 2.0 lrsi = bt.ind.LRSI(midpoint)

The advantage of not having specifics like high and low in the code is that the LRSI can be calculated for anything which is a data feed or descendant of ... you could create the LRSI of a SimpleMovingAverage

@backtrader I've looked on it, and I am going to use it as a baseline for dd length observer.

In case anyone would be tempted to try it, here a pre-packaged CumulativeRSI indicator.

class CumulativeRSI(bt.Indicator): lines = ('cumrsi',) params = (('period', 14), ('count', 2),) alias = ('CumRSI',) def __init__(self): rsi = bt.ind.RSI(self.data, period=self.p.period) self.lines.cumrsi = bt.indicators.SumN(rsi, period=self.p.count)

Another strategy using Super Trend and SAR
Indicators/Settings:
-SUPERTREND(8, 1.5)
-SAR(0.2.0.2)

WHEN TO ENTER A TRADE:

Enter: a BUY trade when SUPERTREND is in a bullish trend(line is green), and SAR gives a BUY signal. (Don't enter a SELL trade if SUPERTREND is bullish and SAR gives a SELL signal.

Enter: a SELL trade when SUPERTREND is in a bearish trend(line is red), and SAR gives a SELL signal. (Don't enter a BUY trade if SUPERTREND is bearish and SAR gives a BUY signal.

Get out of a BUY trade when SAR give a SELL signal, and the opposite for a SELL trade.

Thanks for the reply, I will test and post results soon

Several

Post some sample code (it really helps)

If the target is to write the values of indicators use the standard functionality Writer

See: https://www.backtrader.com/docu/writer.html Don't forget to do this with your indicator: self.mysma = bt.indicators.SMA(self.data, period=30) self.mysma.csv = True

The default behavior is to not write the value of indicators with a writer to avoid cluttering in the csv output and thus selected indicators must have the csv flag activated.

If a single data feed is added to the system with replaydata, only this data will be output. In this case the only data known to cerebro is the one with timeframe=bt.TimeFrame.Minutes and compression=15. The original is NOT in the system

Add it too with: cerebro.adddata(data)

The original behavior of backtrader enforced adding the larger timeframe data feeds after the smaller timeframe feeds. With the new sychronization mechanism available since 1.9.x., this is no longer needed. In any case the suggestions would be for this:

Add the larger timeframe (your replaydata) after the smaller timeframe (adddata) In that case: self.data0 will be the smaller timeframe and self.data1 the larger timeframe. Use the appropriate reference when creating the indicators Although not strictly needed use cerebro.run(next=True). This will keep the buffers fully sync'ed and allows plotting.

@backtrader Thanks.

Thank you. This is now working as you suggest.

@dafyddd

As pointed out by RandyT you can port the indicator easily, imho.

If it's a data feed there is direct support for loading a pandas.Dataframe. See:

https://www.backtrader.com/docu/dataautoref.html (look for PandasData)

If you have something precalculated which is not a data feed the use case is about synchronization, because you probably want to use it as an indicator. You should then check the datetime of the data feed passed to the indicator to fetch the proper data from the dataframe.

A more detailed use case would help in understanding what may (or may not) missing.

This is a non-expected usage pattern and for sure one which is not going to work.

LineBuffer is an internal object which is not meant for user consumption. And of course self.dval1 is turning into a float, you are assigning a float to the member attribute you created yourself.

This is not the same as self.lines.xxx = yyy during the __init__ phase, because in that case self.lines is an object, and xxx is constructed by means of Descriptors, which allows controlling things like assignment (via __set__). But assignment cannot be controlled on a member attribute you have created.

The use case is actually a lot easier:

def __init__(self): self.dval1 = bt.ind.Lowest(self.data.low, period=10) # or bt.ind.MinN(self.data.low, period=10) def next(self): print('the current lowest value is:', self.dval1[0])

The indicator family is big and tries to cover all possible aspects

http://www.backtrader.com/docu/indautoref.html