I discovered this behavior while trying to use peak() to identify local maxima of priceHigh()'s for range estimation. peak() is not capable of detecting flat-topped, square-shaped peaks consisting of 2 (or more) identical values. In the cases where a peak consists of two repeated values, peak() reports 0 (no peak) for both the first and second value. In other words it totally misses the presence of the peak. Proof
And of course this kind of peak can happen in real price data. For example if you are trying to detect local maxima of Highs. The 60m+0 sampling of "GBP/JPY" on 20140715 has two highs with the same value. A peak-detector using peak() misses the peak at Bar 243 because Bar 244 has the same value (174.410004). See chart
Your implementation of crossOver/Under is also naive. In the following example, the Blue line has clearly crossed over the Red line at bar 67, where Blue=2 and Red=1. But crossOver(Blue, Red) is consistently zero throughout.
Code:
function run() {
set(PLOTNOW);
MaxBars = 250;
asset("");
PlotHeight1 = 0;
PlotHeight2 = 256;
vars Red = series(2 - (int)(genSine(120, 120) * 3));
plot("Red", Red, LINE+NEW, RED);
vars Blue = series((int)(genSine(120, 120) * 3))+3;
plot("Blue", Blue, LINE, BLUE);
plot("Cross", crossOver(Blue, Red), LINE+NEW, RED); // always 0.
printf("\n%d %f %f", Bar, Red[0], Blue[0]);
}
Remove the (int) conversions in Red and Blue's definition, making the crossovers is instant, 1 bar wide, and crossOver works correctly.
See attachments.
Last edited by GPEngine; 08/13/1403:38.
Re: peaks() is baffled by flat-topped peaks
[Re: GPEngine]
#444510 08/13/1405:2108/13/1405:21
In my attachments I had the red and blue lines swapped, which could be confusing. But the basic idea holds. Crossover fails to detect report true when a line is below, then equal to, then above, another line even though it is clear from the graph that the lines have crossed.
Re: peaks() is baffled by flat-topped peaks
[Re: GPEngine]
#444519 08/13/1411:3108/13/1411:31
Yes, a flat line is not supposed to produce a signal. I'll add this to the remarks. BTW you can find all peak and crossover algorithms in the manual - no experiments necessary.
Re: peaks() is baffled by flat-topped peaks
[Re: jcl]
#444528 08/13/1415:0008/13/1415:00
Thanks. I realize that flat lines are not supposed to produce a signal. Perhaps I should not have used the word "flat" in my description. Since what I really mean is a series which rises, stays at the same level for 2 bars, then falls. A casual observer would look at the local minimum shown in peak_bug_real_GBPJPY.png and say, "that's a peak." peak() misses it.
Likewise in the chart above Red and Blue have trades places and have clearly "crossed over" yet crossOver is unaware.
Thanks for pointing out algorithms in the manual. Silly me.
Re: peaks() is baffled by flat-topped peaks
[Re: GPEngine]
#444531 08/13/1415:2408/13/1415:24
Hi jcl. I seem to recall this has come up before, and I don't remember seeing the "why"? For example, a flat peak is a kind of "broad peak" (to steal verbiage from optimize ) - why isn't that still a peak? Similarly for valley and the cross's. Is there some statistical or other reason why not?
Thanks.
Re: peaks() is baffled by flat-topped peaks
[Re: DdlV]
#444536 08/13/1416:3808/13/1416:38
The crossOver/Under bug is likely to come up when you're dealing with discrete variables. For example, a newcomer might expect the following to work:
Code:
function run() {
StartDate = 20140715;
EndDate = 20140716;
BarPeriod = 15;
asset("EUR/USD");
// This won't do what you want. Don't do this!
if (crossOver(series(hour()), 12.0)) {
printf("\n%d Hour 13 struck!", Bar);
}
}
Someone unfamiliar with this bug might expect that this strategy would print a line (or perform some action) once per day upon encountering the first bar in hour 13. But, it doesn't. The condition is never true because hour() is discrete. It spends some time (4 bars) at 12 before advancing to 13.
There are other discrete built-ins. NumRiseFall, MinMaxIndex, etc.
Last edited by GPEngine; 08/13/1416:38.
Re: peaks() is baffled by flat-topped peaks
[Re: GPEngine]
#444562 08/14/1408:4308/14/1408:43
I think the "why" is because this is simply an often needed function - triggering a signal on a peak or crossover of a particular bar. If you want to also trigger signals on the begin or end of a flat line or plateau, just use a similar function with >= instead of >.
Re: peaks() is baffled by flat-topped peaks
[Re: jcl]
#444580 08/14/1412:2208/14/1412:22
) - why isn't that still a peak? Similarly for valley and the cross's. Is there some statistical or other reason why not?