MACD-V won the NAAIM Founders Award for technical analysis last year.
It incorporates volatility into the MACD,. normalizing the indicator across multiple assets.
MACD-V =[(12-period EMA - 26-period EMA) / ATR (26)] * 100
Signal line = 9-period EMA of MACD-V
Histogram = MACD-V - Signal Line
where
EMA = exponential moving average
MACD-V Histogram
MACD-V = [(12-period EMA – 26-period EMA)/ATR (26)] * 100
Signal line = 9-period EMA of MACD-V
Histogram = MACD-V – Signal Line
where
EMA = exponential moving average
It incorporates volatility into the MACD,. normalizing the indicator across multiple assets.
MACD-V =[(12-period EMA - 26-period EMA) / ATR (26)] * 100
Signal line = 9-period EMA of MACD-V
Histogram = MACD-V - Signal Line
where
EMA = exponential moving average
MACD-V Histogram
MACD-V = [(12-period EMA – 26-period EMA)/ATR (26)] * 100
Signal line = 9-period EMA of MACD-V
Histogram = MACD-V – Signal Line
where
EMA = exponential moving average
Rename
Looks like a worthy addition, I'll add it to the Power Pack for the next release cycle.
QUOTE:
... the MACD,. normalizing the indicator across multiple assets....
What multiple assets are we talking about? Are you talking about applying the MACD-V to build a composite index (say via IndexLab)?
I'm assuming you want to normalize each stock against its own ATR before IndexLab computes the composite MACD-V index for the given trading dataset. I just trying to connect the dots here.
I hadn't considered using the MACD-V in the index lab, yet. I only saw the initial paper today and thought it was interesting.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4099617
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4099617
Would it be possible to add an overload to the MACDV implementation that would take a TimeSeries as an input source instead of a BarHistory input?
---
By the way, the paper cited it the link above is an excellent paper. It includes a nice history of the MACD and PPO indicators and breaks down their shortcomings. It then illustrates how the new MACDV indicator overcomes many of these shortcomings by normalizing against the ATR.
Appreciate normalizing any metric with the ATR is a very good idea. For example, the Chandelier Stop is represented in terms of ATRs. When I have the WL optimizer set a threshold for a parameter, its typically in terms of ATRs--not dollars. This way the parameter threshold settings apply to all stocks in my dataset independent of their price ranges.
CODE:The problem is I often use the decorrelated line (decorrelated against the S&P500) as an input source, and that is a TimeSeries, not a BarHistory.
MACDV(TimeSeries source, TimeSeries atr, int period1, int period2); MACDVHist(TimeSeries source, TimeSeries atr, int period1, int period2, int signalLinePeriod);
---
By the way, the paper cited it the link above is an excellent paper. It includes a nice history of the MACD and PPO indicators and breaks down their shortcomings. It then illustrates how the new MACDV indicator overcomes many of these shortcomings by normalizing against the ATR.
Appreciate normalizing any metric with the ATR is a very good idea. For example, the Chandelier Stop is represented in terms of ATRs. When I have the WL optimizer set a threshold for a parameter, its typically in terms of ATRs--not dollars. This way the parameter threshold settings apply to all stocks in my dataset independent of their price ranges.
QUOTE:
Would it be possible to add an overload to the MACDV implementation that would take a TimeSeries as an input source instead of a BarHistory input?
A BarHistory is required to calculate the ATR for which a TimeSeries is insufficient.
QUOTE:
A BarHistory is required to calculate the ATR for which a TimeSeries is insufficient.
So as my API prototype code shows in Post #4, two separate TimeSeries are being passed in. One is the "source" and the other TimeSeries is the "ATR". Since the ATR TimeSeries is given (as input), you no longer need the BarHistory.
Right, but isn't it cumbersome and non-intuitive and would require documentation.
It's not cumbersome if the BarHistory version simply won't work for you because there isn't a BarHistory in the first place. Not all metrics have a BarHistory, yet there's still a need to track them with a momentum indicator (like MACD).
Read Post #4 again. I said an overload implementation. Of course the BarHistory version should be included (and documented) first. But the overloaded prototype, which doesn't require a BarHistory, should be offered just below. And WL is setup to offer an example of each prototype.
Moreover, I think users are smart enough (cross my fingers) to use the first prototype if a BarHistory is available. As you said, the second option is more cumbersome and is only being offered as a last resort.
Read Post #4 again. I said an overload implementation. Of course the BarHistory version should be included (and documented) first. But the overloaded prototype, which doesn't require a BarHistory, should be offered just below. And WL is setup to offer an example of each prototype.
Moreover, I think users are smart enough (cross my fingers) to use the first prototype if a BarHistory is available. As you said, the second option is more cumbersome and is only being offered as a last resort.
The current MACDV implementation won't take a TimeSeries input, and I need a momentum indicator that does. The current implementation is useless to me.
What I need is an implementation that can take a TimeSeries input and a volatility TimeSeries as well. Can you add an overload for that, or do I need to write my own indicator?
---
Off topic, but using the ATR for the volatility metric here is not ideal if the MACDV is processing Closes, which it is. What we really need is a volatility metric that measures the volatility of Closes themselves, not one that models High-Low ranges (such as ATR). The bad news is that the StdDev indicator, which does model the volatility of Closes, is not a good candidate either because it's sensitive the outliers. What we really need is a "robust" StdDev indicator to pass into the MACDV for normalizing that is based on the volatility of Closes.
I thought about writing a robust StdDev myself, but I haven't had time. Moreover, this problem is complicated because we cannot assume normally distributed error around the StdDev calculation; otherwise, I could just detect and reject outliers based on their Z-scores.
What I need is an implementation that can take a TimeSeries input and a volatility TimeSeries as well. Can you add an overload for that, or do I need to write my own indicator?
---
Off topic, but using the ATR for the volatility metric here is not ideal if the MACDV is processing Closes, which it is. What we really need is a volatility metric that measures the volatility of Closes themselves, not one that models High-Low ranges (such as ATR). The bad news is that the StdDev indicator, which does model the volatility of Closes, is not a good candidate either because it's sensitive the outliers. What we really need is a "robust" StdDev indicator to pass into the MACDV for normalizing that is based on the volatility of Closes.
I thought about writing a robust StdDev myself, but I haven't had time. Moreover, this problem is complicated because we cannot assume normally distributed error around the StdDev calculation; otherwise, I could just detect and reject outliers based on their Z-scores.
QUOTE:
Can you add an overload for that, or do I need to write my own indicator?
The notion of using an external symbol's ATR sort of breaks indicator's encapsulation and does require documentation. Maybe it's a clever idea but it's not evident because it's not meant to be used this way. Hence it's not MACD-V but something new.
QUOTE:
Hence it's not MACD-V but something new.
Well, you're still normalizing by volatility whether you do it by ATR or something different. But if you want to called MACDV2, I'm good with that.
Bottom line, I want to run a normalized MACD on something that's a TimeSeries, not a BarHistory. Fundamental problem is I use the MACD to process the output of other indicators, which will always be a TimeSeries. We can call the new indicator MACDV2 if you like.
The generated example code for MACDVHist returns an error.
Thank you for the heads-up, I just spotted a bug in its code and fixed it for B94.
Your Response
Post
Edit Post
Login is required