The parameter docs for PlotIndicatorOscillator disagree for the QuickRef and IntelliSense as shown in the screenshot. I assume the IntelliSense documentation overrides everything else.
The QuickRef indicates this is a virtual member function. Is that really true? Are users creating their own CustomUserStrategyBase to build strategies from? My concern is, if they post their strategy code to the forum using a customized base with overriding members, it might be hard to analyze and follow it for the rest of us.
The QuickRef indicates this is a virtual member function. Is that really true? Are users creating their own CustomUserStrategyBase to build strategies from? My concern is, if they post their strategy code to the forum using a customized base with overriding members, it might be hard to analyze and follow it for the rest of us.
Rename
Your screenshot is showing PlotIndicatorOscillator in the QuickRef and PlotTimeSeriesOscillator in the editor.
I see that now.
What I intended to do was use PlotIndicatorOscillator with the SchaffTrendCycle oscillator, but its indicator definition is not defining it as an "oscillator" as it should, so I resorted to using PlotTimeSeriesOscillator instead so I could introduce an oversold and overbought level into its plot.
Perhaps the SchaffTrendCycle oscillator could be defined as an oscillator with a default oversold=25 and overbought=75. Then the PlotIndicatorOscillator method would work as expected, so the PlotTimeSeriesOscillator wouldn't need to be substituted instead.
Editorial comment: I like the concept of combining the MACD and stochastic indicators into a single SchaffTrendCycle oscillator. But the signaling of the SchaffTrendCycle oscillator lags about two or three bars behind the ideal time to trade, which is a problem. The SchaffTrendCycle implementation is missing something.
What I intended to do was use PlotIndicatorOscillator with the SchaffTrendCycle oscillator, but its indicator definition is not defining it as an "oscillator" as it should, so I resorted to using PlotTimeSeriesOscillator instead so I could introduce an oversold and overbought level into its plot.
Perhaps the SchaffTrendCycle oscillator could be defined as an oscillator with a default oversold=25 and overbought=75. Then the PlotIndicatorOscillator method would work as expected, so the PlotTimeSeriesOscillator wouldn't need to be substituted instead.
Editorial comment: I like the concept of combining the MACD and stochastic indicators into a single SchaffTrendCycle oscillator. But the signaling of the SchaffTrendCycle oscillator lags about two or three bars behind the ideal time to trade, which is a problem. The SchaffTrendCycle implementation is missing something.
QUOTE:
Perhaps the SchaffTrendCycle oscillator could be defined as an oscillator with a default oversold=25 and overbought=75.
Good catch. Makes perfect sense to do. Consider it done for B36.
P.S. And I've renamed the topic to reflect the issue accordingly.
Thanks for renaming the topic. I can post my SchaffTrendCycle demo code once B36 fixes it.
But the demo code shows SchaffTrendCycle signals about two or three bars late (via its oversold and overbought points after optimization), which is somewhat worse than when MACDHisto signals. Clearly the SchaffTrendCycle design has problems.
What's weird is that SchaffTrendCycle gets a great deal of press. Why would a lagging indicator get so much press? It needs some re-engineering where the MACD portion is given more weight than the stochastic portion. And there needs to be a third indicator added that acts as a leading indicator for SchaffTrendCycle. That third leading indicator can perform a statistical test on the bars SchaffTrendCycle brackets just prior to its trading signal. We're looking for a significant statistical change in the leading bar behavior here.
But the demo code shows SchaffTrendCycle signals about two or three bars late (via its oversold and overbought points after optimization), which is somewhat worse than when MACDHisto signals. Clearly the SchaffTrendCycle design has problems.
What's weird is that SchaffTrendCycle gets a great deal of press. Why would a lagging indicator get so much press? It needs some re-engineering where the MACD portion is given more weight than the stochastic portion. And there needs to be a third indicator added that acts as a leading indicator for SchaffTrendCycle. That third leading indicator can perform a statistical test on the bars SchaffTrendCycle brackets just prior to its trading signal. We're looking for a significant statistical change in the leading bar behavior here.
Your Response
Post
Edit Post
Login is required