Refactor AnalysisCriterion to make it an Indicator

[nimo23]

Actually, our AnalysisCriterion can only be used for backtesting purposes and does not provide the capabilities of an Indicator (e.g. perform an action on each bar, use the cache instead of recalculation, etc.).

If our "analysis criterion" had the possibilities of an "indicator", then we would have the following possibilities:

• use the ta4j cache also for criteria
• measure the performance at the end of each bar (or for the latest bar in realtime) and take an action according to a common Strategy - this would allow us portfolio and performance rebalancing features within ta4j and would also solve automatically Position-based indicators #742 and Enable calculated amount to open trade (based on entry bar) #1013.
• our betterThan would fit nicely into the new concept (e.g. perf1.betterThan(perf2)).
• use our PerformanceIndicators (formerly known as Criterion) also in combination with our Rules and Strategies, because it is now an ordinary Indicator.
• remove redundant/overlapping classes within criteria/helper and indicator/statistics (e.g. StandardDeviation, StandardError, Variance, etc.) because as a criterion is now a special indicator, it can use the classes of indicator/statistics.

We are used to calling it AnalysisCriterion, although the essence of this concept simply reflects the measurement of a (key) performance indicator, thus a far better and comprehensable name would be "PerformanceIndicator" and this also implies that our AnalysisCriterion is nothing else but an indicator which measures a type of performance.

Describe the solution you'd like
(1) Rename AnalysisCriterion to PerformanceIndicator and let it be an Indicator:

/**
 * A performance indicator. It can be used to:
 * 
 * <ul>
 * <li>analyze the performance of a {@link Strategy strategy}
 * <li>compare several {@link Strategy strategies} together
 * <li>calculate the performance in realtime
 * </ul>
 */
public interface PerformanceIndicator extends Indicator<Num>{
..
}

(2) rename package criteria to performance and put it into package indicators

(3) delete redundant/overlapping classes within of indicator/performance/helper and indicator/statistics

Describe alternatives you've considered
I cannot find a better alternative and I really think we need to do it to enable the features described above. We must free ourselves from old constrained concepts and dare this abstraction step. With this abstraction step, this lib can do much more and the merging of both concepts (criterion, indicator) in one is also a significant simplification for the future.

What do you think?

I hope I don't hear something like "That would break the API" etc. again. We must look to the future and not to the past. So please: No old-fashioned statements - I want to hear constructive ideas and suggestions. And if someone is against it, then please provide a better solution for those issues like #742 and #1013 and issues which are coming in the future because of this limitation.

Note, that it would be far easier to provide a solution like #761 or #757 (without the need fo the refactorings described in this issue) but it was not merged, because we need to find a more general solution as said in #757 (comment). This issue wants to be the "more general solution". But maybe, there is a better solution - I don't know. Feel free to help.

[team172011]

You already mentioned my comment #757 (comment) . And I still think refactoring the "AnalysisCriterion to make it an Indicator" will mix up the two use cases:

• backtesting
• live trading

Issues like #742 and #1013 are related to live trading. In my opinion if we want to solve these issues, we should think about complete new concepts instead of enhancing the api that is meant to be used only for backtesting.

[nimo23]

if we want to solve these issues, we should think about complete new concepts instead of enhancing the api that is meant to be used only for backtesting.

This issue is here to discuss/find such concepts.

Backtesting can be done as well with the concept "PerformanceIndicator" described above. Mixing these two concepts is unavoidable if we want to use both the criteria for backtesting and live trading. Currently only the indicators can be used for live trading - to use the criterion for live trading as well, I don't see any other clean way to simply extend these as (performance) indicators.

Or do you or anyone else see other solutions?