Feature: trade-dependent indicators

[MarcDahlem]

Fixes #742.

Changes proposed in this pull request:

• Allow trade based indicators, which can easily calculate their values by using the last executed trade

• Added a break even indicator based on the last executed entry position

• added an entry with related ticket number(s) to the unreleased section of CHANGES.md

[team172011]

I have reservation against this indicator type. Similar to #761 why should we mix up Trades and indicators? Wouldn't a Rule be the place for such a decisions? In a Rule you have access to the TradingRecord of the current run. Having access to a TradingRecord in an Indicator means that you have to create another Strategy with Rules and Indicators and so on just to apply this TradingRecord to this indicator. There may be special cases for this, but I am not sure if ta4j should support this by default and within the current architecture of this framework

[team172011]

Please change Implemented ... to Added ...

[MarcDahlem]

I have reservation against this indicator type. Similar to #761 why should we mix up Trades and indicators? Wouldn't a Rule be the place for such a decisions? In a Rule you have access to the TradingRecord of the current run. Having access to a TradingRecord in an Indicator means that you have to create another Strategy with Rules and Indicators and so on just to apply this TradingRecord to this indicator. There may be special cases for this, but I am not sure if ta4j should support this by default and within the current architecture of this framework

Mhm, not sure if that can be handled in Rules. If you have any ideas how to do it, I'm open to every suggestion.

I use the trade-based indicator quite much in my trading bot.
Examples:

• Break even indicator
  • --> if break even is reached, the exit criterion of the strategy is changed (needs only true and false)
  • --> place an order 2% above the break even (needs the concrete value/Num of the break even for every trade. Thats why it is an "calculator"(Indicator) and not a "condition"(Rule))
• Lowest/highest since last sell
• Restart of rules/conditions after a sell
  • --> example: Buy if EMA(20)>EMA(200). Sell on 2% gain. Without a "reset", the bot would directly buy again if the EMA(20) is still over EMA(200).
• BuyPrice-Indicator --> Indicator which holds the buy price during the lifetime of a trade
• IsBuyPhase indicator ..> true if in BuyPhase and false if not
• ...

If it is an indicator, other indicators and rules can easily depend on it.
For example TransformIndicator.muplitply(breakEvenIndicator, 1.04) directly contains the value which is 4% above the break even in EVERY Buy-Phase. new OverIndicatorRule(closePrice, breakEven) is true if the break even is reached...No need to handle multiple indicators, swich rules, swich strategies, adapt indicators... The only thing that must be handled is storing TradingRecords in my bot on every real executed trade on the market while it is running.

And those indicators can easily be used also in backtesting. They are really powerful!

[nimo23]

Wouldn't a Rule be the place for such a decisions? In a Rule you have access to the TradingRecord of the current run.

Yes, I also think you should create a new Rule instead of an Indicator. Because Indicator is linked with Bars and nothing else. I will look to create a new PR CriterionRule which is an improvement over #761. Maybe this CriterionRule is also sufficent for your use case. If not, please create a new Rule and call it BreakEvenRule.

[nimo23]

After rethinking, I guess, such trade based decisions would not be solely possible with a Rule because we need the already executed TradingRecord (till the observed index) to look for. We need to add Indicators within Rules to determine if the Rule is satisfied. That's why we could make use of the CriterionIndicator (from #761) within a Rule (but a Rule cannot replace the CriterionIndicator). In this context, this also means that it would not be easily possible to replace the TradeBasedIndicator with a Rule.

To demonstrate this, look at the following code which ought to replace the CriterionIndicator with a CriterionRule:

/**
 * Criterion rule.
 * 
 * <p>
 * Satisfied when the AnalysisCriterion satisfies a required criterion value.
 */
public class CriterionRule extends AbstractRule {

    private final BarSeries barSeries;
    private final AnalysisCriterion criterion;
    private final Num requiredCriterionValue;

    /**
     * @param barSeries              the bar series
     * @param criterion              the criterion to get the calculated criterion
     *                               value on a bar index
     * @param requiredCriterionValue the required criterion value to test against
     *                               the calculated criterion value
     */
    public CriterionRule(BarSeries barSeries, AnalysisCriterion criterion, Num requiredCriterionValue) {
        this.barSeries = barSeries;
        this.criterion = criterion;
        this.requiredCriterionValue = requiredCriterionValue;
    }

    @Override
    public boolean isSatisfied(int index, TradingRecord tradingRecord) {
        boolean satisfied = false;
        if (tradingRecord == null || tradingRecord.getPositions().isEmpty()) {
            satisfied = false;
        } else {
            Num calculatedCriterionValue = criterion.calculate(barSeries, tradingRecord);
            satisfied = criterion.betterThan(calculatedCriterionValue, requiredCriterionValue)
                    || calculatedCriterionValue.isEqual(requiredCriterionValue);
        }
        traceIsSatisfied(index, satisfied);
        return satisfied;
    }
}

You see that the tradingRecord cannot be filled without another rule or indicator. That's also the case for this TradeBasedIndicator - you cannot replace it solely by a Rule.

I think this TradeBasedIndicator (and the CriterionIndicator) has its need. Because currently, it is impossible to create a decision solely by a TradingRecord.

[team172011]

I think we have to distinguish between different use cases: live trading (e.g. implementing a bot) and backtesting. So far the only use case for AnalysisCriterions in ta4j has been backtesting.

• After creating one or several Strategies you can execute them and get the results in form of TradingReports. After that you can analyze results by using AnalysisCriterions. It makes no sense here to have a backtesting run with Indicators that depend on an AnalysisCriterion and this criterion depends on a TradingRecord (that needs to be the result of another run?).

• For live trading once could imagine use cases where you need access to the TradingRecord and the (current) value of an AnalysisCriterion and where you want to implement logic that modifies the TradingRecord and so on. If you are using it in a trading bot for live trading this is also fine, but there is no general concept for using it together within an Indicator and/or AnalysisCriterions during a session.

We cannot add trade based indicators or criterion based indicators to this lib just because you are using it during live trading in a specific situation. It will get confusing for the user if we mix things up this way.
I am open for improvement or extension for more live trading support in ta4j. But first we need a general and separated concept for live trading that can be discussed.

[MarcDahlem]

For the moment, I dont need Crtierion.

I personally need Indicators, which can calculate their current value according the the current trade state.
Especially LowestSinceLastExit and BreakEven and BuyPrice are very important indicators for me.
I need them especially during backtesting!

For live-trading I could workaround that by replacing my complete strategy with new indicators and rules as soon as a position changed.

But for Backtesting, I need calculators, which change if the last position is opened, closed or there is no last position. (And here I cannot change the complete Strategy and indicators, because Backtesting would not work). There are simple features like wait at least 200 ticks after an exit. Or get the current buy price in running open positions to calculate borders for gain and loss accordingly.

Its no problem for me if you are not interested in this (in my opinion very useful) indicator and dont want to merge it into your project.

--> PR closed