Feature/recent swing high and low indicators

[TheCookieLab]

Fixes #.

Changes proposed in this pull request:

• Add new RecentSwingHighIndicator

• Add new RecentSwingLowIndicator

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

[francescopeloi]

I have some code to find high and low swings in my ZigZag indicator (that I haven't finished yet), as knowing swings simplify the ZigZag algorithm.

One problem/bug I encountered was how to judge swings when the price doesn't vary, e.g.: 0=1, 1=2, 2=3, 3=3, 4=3, 5=2, 6=1. Which one of these is a swing high? index 2, 3 or 4? or all of them? or none of them?

Does your code handle this case? If so, how did you answer this question? I haven't found a definite answer myself.

Thank you!

[TheCookieLab]

If we define swing high as

A swing high is a bar with a higher high than the bars both before and after it

then none of index 2, 3, or 4 would be a swing high and we would consider the swing high point not yet materialized. In practice I would think these types of exact plateaus would be very unusual. If we want to handle this we could check for strictly lesser than instead of lesser than or equal to.

[francescopeloi]

In the index I am looking at (s&p future) they are not that unusual, and they mess up the ZigZag indicator if you don't choose one of them (i.e. when you plot the graph without choosing one, the zigzag seems wrong). As said I haven't answered myself fully to this and I need to look at it a bit more to have an opinion myself, just wanted to share my preliminary thoughts.

[TheCookieLab]

In that case swing high becomes rather subjective, and you can choose the first, middle, or last bar of the plateau.

[francescopeloi]

True, but I was thinking also at your definition you pasted above. Imagine a scenario where the price is stable and has a big up peak, and then go back to previous stable price. You see the graph of this and you clearly think there's a swing high there. Would you say that, that is not a swing high if the price at the peak is repeated more than once (e.g. twice)? If not, to me the question become, what usefulness has this swing high definition if such (and similar) scenarios are taken out.

Maybe in the application you are imagining this is not a problem (it is in mine (zigzag), and quiet significant)? If so, can you share your application, so I can understand more?

To generalize, there is a parameter that defines the max number of ticks allowed at the top/bottom of a swing high/low, and in your case is 1, in my case might be more than 1 (how much I don't know yet 😄 )

It's like defining when a mountain has a peak, and when it becomes upland instead 😄

[francescopeloi]

That I think I understood but my objection still stands. I tried to exemplify it with a test but got some odd behavior which stopped me doing so, this test fully pass but I believe some assertions shouldn't:

@Test
public void testCalculate_PricePlateau_ReturnsValue() {
    List<Bar> bars = new ArrayList<>();
    bars.add(new MockBar(10, 10, 10, 10, numFunction));
    bars.add(new MockBar(11, 11, 11, 11, numFunction));
    bars.add(new MockBar(12, 12, 12, 12, numFunction));
    bars.add(new MockBar(12, 12, 12, 12, numFunction));
    bars.add(new MockBar(12, 12, 12, 12, numFunction));
    bars.add(new MockBar(11, 11, 11, 11, numFunction));
    bars.add(new MockBar(10, 10, 10, 10, numFunction));
    BarSeries newSeries = new MockBarSeries(bars);

    RecentSwingHighIndicator swingHighIndicator = new RecentSwingHighIndicator(newSeries, 2);

    assertNumEquals(NaN.NaN, swingHighIndicator.getValue(0));
    assertNumEquals(NaN.NaN, swingHighIndicator.getValue(1));
    assertNumEquals(NaN.NaN, swingHighIndicator.getValue(2));
    assertNumEquals(12, swingHighIndicator.getValue(3));
    assertNumEquals(12, swingHighIndicator.getValue(4));
    assertNumEquals(12, swingHighIndicator.getValue(5));
    assertNumEquals(12, swingHighIndicator.getValue(6));
    assertNumEquals(12, swingHighIndicator.getValue(7));
    assertNumEquals(12, swingHighIndicator.getValue(15557));
    assertNumEquals(12, swingHighIndicator.getValue(519812891));
}

In this test case and based on the logic you want to follow, shouldn't only index = 3 return 12, and eveything else NaN?

[TheCookieLab]

I'm not sure why you would think that. The peak occurs and for all bars after that it is the most recent swing high.

[francescopeloi]

ok I understand now the behavior, I missed the "recent" bit. In this test index 2 is not a swing high, but index 3 is, even if they have the same value. Is this what you want to achieve? Start from the middle point of the peak/valley?

[TheCookieLab]

True, but I was thinking also at your definition you pasted above. Imagine a scenario where the price is stable and has a big up peak, and then go back to previous stable price. You see the graph of this and you clearly think there's a swing high there. Would you say that, that is not a swing high if the price at the peak is repeated more than once (e.g. twice)? If not, to me the question become, what usefulness has this swing high definition if such (and similar) scenarios are taken out.

Maybe in the application you are imagining this is not a problem (it is in mine (zigzag), and quiet significant)? If so, can you share your application, so I can understand more?

To generalize, there is a parameter that defines the max number of ticks allowed at the top/bottom of a swing high/low, and in your case is 1, in my case might be more than 1 (how much I don't know yet 😄 )

It's like defining when a mountain has a peak, and when it becomes upland instead 😄

The key to useful technical analysis is to focus on patterns that are unambiguously signals. If you need to squint at it to make it fit ("that could be a peak") then you're not going to be doing this for long. The goal of these indicator is to identify unambiguous swing highs and lows with the core trading tenent of it's OK to miss opportunities because there will always be more. In other words I'm fine with errors of omission, but not of commission. Increasing scope to handle N-bar plateaus and valleys introduces inherent ambiguity and subjectivity which is undesirable. I'm going to revert these indicators back to their previous implementation.

[francescopeloi]

thanks for you detailed explanation

[TheCookieLab]

On second thought while I may consider it a misguided approach, far be it for me to impose my trading philosophy on others. I've re-implemented this to support plateaus as swing highs if desired.

[TheCookieLab]

Looking for a reviewer on this change set. Would you use this indicator? If yes, what else would you like it to have? If no, why not?