I am trying to code an indicator for the average of the difference between the
Close and the Open. Not sure if this is possible since a BarHistory-based indicators CANNOT be based on other indicator as a source. If so what would be the alternative? I have started coding in see below. I know I can use the IndOnInd Indicator and it works ok but can it be coded. Thanks for your help.
Close and the Open. Not sure if this is possible since a BarHistory-based indicators CANNOT be based on other indicator as a source. If so what would be the alternative? I have started coding in see below. I know I can use the IndOnInd Indicator and it works ok but can it be coded. Thanks for your help.
CODE:
public override void Populate() { BarHistory source = Parameters[0].AsBarHistory; Int32 period = Parameters[1].AsInt; DateTimes = source.Close.DateTimes; if (period <= 0)//SAFEGUARD return; //modify the code below to implement your own indicator calculation for (int n = period + 1; n < source.Close.Count; n++) { double rb;// = source.Close[n] - source.Open[n]; double avgrb; rb = source.Close[n] - source.Open[n]; avgrb = new SMA(rb, period); Values[n] = avgrb; } } //generate parameters protected override void GenerateParameters() { AddParameter("Source", ParameterType.BarHistory, null); AddParameter("Period", ParameterType.Int32, 14); }
Rename
A few things, first off, your variable avgrb is being assigned the complete SMA TimeSeries, so I don't think this code will compile. Values[n] requires a floating point double, not a TimeSeries. Also, you should avoid creating SMA within a loop, you'll winding recalculating the whole indicator each iteration of the loop.
Finally, we already have you covered, you can access the average of open and close using the standard Price Component.
Finally, we already have you covered, you can access the average of open and close using the standard Price Component.
Thanks that's what thought. I was able to create the indicator for "rb" and then use the IndOnInd indicator for the average.
CODE:
for (int n = period + 1; n < source.Close.Count; n++) { double rb;// = source.Close[n] - source.Open[n]; rb = source.Close[n] - source.Open[n]; Values[n] = rb; }
That looks much better!
Since source.Close and source.Open are both TimeSeries then you don't need the loop. You should be able to just do this...
Values = (source.Close - source.Open).Values;
The TimeSeries overload of the minus operator will take care of the loop for you.
Values = (source.Close - source.Open).Values;
The TimeSeries overload of the minus operator will take care of the loop for you.
@Paul986, thanks for the info. I was just wondering myself too because the sample SMA in the Indicator Builder has TimeSeries and also uses the for Loop. I'm still new to WealthLab script and having trouble grasping the TimeSeries vs BarHistory conditions.
Might be a good idea to do a table side by side showing a list of the 2 conditions.
Might be a good idea to do a table side by side showing a list of the 2 conditions.
There's really only one simple consideration. Does the indicator require multiple parts of the BarHistory, like High, Low (example ATR), or does it require volume (example AccumDist)? If so, then it needs a BarHistory source. If not, then it just needs a TimeSeries source (example SMA, RSI).
Thanks, so in reality I could use BarHistory for all?
QUOTE:
Thanks, so in reality I could use BarHistory for all?
No. Take SMA for example. A moving average-like indicator requires a TimeSeries as input but the series can be completely synthetic and not related to an existing BarHistory. In such case you'd prefer a TimeSeries input.
QUOTE:
... so in reality I could use BarHistory for all?
In theory, yes. But a good OOPs programmer will expose only what's absolutely necessary to the calling routine (your "indicator" in this case) to get the job done. This reduces the chance of inadvertent data corruption and minimizes the setup time for pointers (or "references" we say in C#) into elements of the BarHistory that will never be used.
There's also a usability issue in this case. Most indicators return a TimeSeries, not a BarHistory. So you would like your indicator to accept a TimeSeries as a parameter whenever possible so you can pass other indicators into it.
If you use BarHistory for all then you’re stuck using only the OHLC/V information. You wouldn’t be able to apply your indicator to anything else, like you can for example apply an SMA to the RSI, or even apply a Bollinger Band to a Stochastic.
But technically it will work it will not cause WL to freeze or anything it just will not have the advantages TimesSeries has that you mentioned correct?
Let's do a recap here, including posts from the other thread where I believe you were asking about BarHistory and TimeSeries:
I stated:
Glitch most eloquently described it in a nutshell...
Glitch then reinforced his point...
And in this thread Glitch states:
Furthermore, you stated here in response to my example of use of an operator overload:
Well, in a nutshell, indicators and strategies are going to use different inputs and processing depending on what is trying to be achieved. The SMA sample uses a TimeSeries parameter because it calculates a simple moving average based on a set of double values as an input. It doesn't need a BarHistory. It shouldn't take a BarHistory as a parameter (instead of the TimeSeries) because then it would only be able to calculate the SMA from Open, HIgh, Low, Close, or Volume properties versus any set of double values that can be represented in a TimeSeries.
The SMA sample has a loop because that is how the result can be achieved. There is no operator overload for that loop because, at the very least, that would be an extreme edge case. The simplification that I provided for your loop is the operator overload for subtracting the two TimeSeries. That is a common thing to do. Hence, that is why it exists as part of the TimeSeries class.
I stated:
QUOTE:
Its not a preference, but a decision based on what data you want your custom indicator to process. For example you could have a custom indicator that takes as its source a BarHistory. That would give it access to the bars' Open, Close, etc., but that is particular to a BarHistory. However, you can't provide something like a moving average (e.g. SMA) because that is not a BarHistory.
Instead if your custom indicator takes a TimeSeries as its source, you can provide, say, an SMA (or any TimeSeries). But, you can't provide it a BarHistory because a BarHistory is not a TimeSeries. Both TimeSeries and BarHistory inherit from TimeSeriesBase. They're siblings.
Glitch most eloquently described it in a nutshell...
QUOTE:
Exactly, and if your indicator doesn't need a BarHistory (doesn't need OHLC, but can be applied to just one data series) then use TimeSeries. Because if you use BarHistory then you won't able to apply your indicator onto ANOTHER indicator, like you can apply an SMA or EMA to an RSI or a CMO.
Glitch then reinforced his point...
QUOTE:
The TimeSeries-based indicator can access only ONE of the OHLC/V items, and the "High" that you called out there is just the default value. It could also use another indicator, like an RSI, as a source.
The BarHistory-based Indicator can access all 5 OHLC/V items, not only one of them.
A BarHistory-based indicator, however, CANNOT be based on other indicator as a source. For example like the SMA which can use another indicator like RSI as its source.
And in this thread Glitch states:
QUOTE:
If you use BarHistory for all then you’re stuck using only the OHLC/V information. You wouldn’t be able to apply your indicator to anything else, like you can for example apply an SMA to the RSI, or even apply a Bollinger Band to a Stochastic.
Furthermore, you stated here in response to my example of use of an operator overload:
QUOTE:
I was just wondering myself too because the sample SMA in the Indicator Builder has TimeSeries and also uses the for Loop.
Well, in a nutshell, indicators and strategies are going to use different inputs and processing depending on what is trying to be achieved. The SMA sample uses a TimeSeries parameter because it calculates a simple moving average based on a set of double values as an input. It doesn't need a BarHistory. It shouldn't take a BarHistory as a parameter (instead of the TimeSeries) because then it would only be able to calculate the SMA from Open, HIgh, Low, Close, or Volume properties versus any set of double values that can be represented in a TimeSeries.
The SMA sample has a loop because that is how the result can be achieved. There is no operator overload for that loop because, at the very least, that would be an extreme edge case. The simplification that I provided for your loop is the operator overload for subtracting the two TimeSeries. That is a common thing to do. Hence, that is why it exists as part of the TimeSeries class.
Thanks for the summary, makes perfect sense.
Your Response
Post
Edit Post
Login is required