Chart-Patterns-Engine-Override-for-PeakTroughs-List

Sounds good Rich.
Be sure to check on Preferences > Chart Patterns and then hit F1 for help. You can adjust the ATRPercent increase value for each pass.

Did you derive your class from the base PTC? We’d need to have a common ancestor or support a common interface to make this work.

I did not start ClearMethod as a derived class. I guess this old dog has to work on improving C# skills and finally learn how to manage inheritance and overrides! Back in a month...

QUOTE:
Did you derive your class from the base PTC? We’d need to have a common ancestor or support a common interface ...

So is it better to build one's own PeakChartCalculator from base PTC, or would passing in a Predicate procedure that redefines the peak determining paradigm make more sense? I "guessing" building the new PeakChartCalculator from base PTC would be more efficient (include only what's needed) and flexible (add new metrics), but it requires a little more work.

I started looking for the PeakTroughCalculator base class (mentioned above in Reply# 2), but the VS Object Browser can't seem to find one (or find an interface for it). Am I missing something?

I like the idea of detecting peaks by ATR, but that requires BarHistory data when only TimeSeries data may be available. So I was going to write a PeakTroughCalculator for MedianAbsoluteDeviation (MAD) instead, which would work with TimeSeries data. But I can't seem to find the base class (or interface) for PeakTroughCalculator. What am I missing?

MAD would be a better peak detection criteria than ATR anyway since it's a robust metric.

It's documented here in the QuickRef fully loaded with example code for the various properties and methods.

And here is the link to the QuickRef entry here on the site:
https://www.wealth-lab.com/Support/ApiReference/PeakTroughCalculator

I read all that already. But this is not a suitable base class. I can't inherit from it and create an overriding type to add PeakTroughReversalTypes.MAD to its enum. I don't even think PeakTroughReversalTypes is "virtual" so one can override it. At least the VS Object Browser doesn't think so.

Are you suggesting I create a derived type instead of an inherited type? But wouldn't an inherited type follow the same interface guidelines better?

I guess what I was envisioning was a PTC abstract class that contained a PeakTroughReversalTypes "virtual protected" type a developer would override to add new function. And the PTC abstract class would have its own "virtual protected" methods the developer might override or amend. But that's not what I'm seeing.

I don't think the current architectural design is extensible by inheritance. And a derived type may not follow the same API (interface). Having a PTC abstract class with virtual protected methods to inherit from would be more powerful.

Well, this isn't a high priority. And documenting a PTC abstract class with virtual protected methods would take time. But it would be nice to have something like this once the feature request list is whittled down more. Until then, I can come up with an ad hoc solution like the other WL user did with his own peak detector.

Passing in a Predicate function (defining the peak detection paradigm) into the existing PTC would be another (and simpler) option. Many .NET methods use that approach. And honestly, I like the Predicate function approach better because one doesn't have to create another class. It's less work. Maybe I can make this Predicate-function approach a feature request.