Very clever syswizard, but u overlooked the important points I defined, and since I posted that solution to the public domain... you are welcome to it make it as clever as you can.
He's either LOL because he's pranked us ...or worse he's a true wizard of abstraction ...and thinking he's just invented a mirror image, upside down ...? counter or whatever those things are called that can be used in both directions. Oh yeah, we need more programmers like syswizard ...so we have someone to trade against.
IMHO: false allegations.... 1) re:"overlooked important points"....and so you don't enumerate them in this thread ? What a load of B.S. that is ! 2) re: "I posted that solution to the public domain"....and so you provided no link ? What a load of B.S. that is ! 3) Finally, the "key" to this solution was the definition of the attenuation points..... and you don't even address that ? What a load of B.S. that is ! 4) Let's just continue....was your solution able to mimic the results of the original Doug Kass link ? If not... What a load of B.S. that is !
In most languages you'll need to iterate with some logic. Making it not iterate is probably more painful than it's worth. Forward algorithm pseudocode: BAR_IN_CORRECTION[0] is true if MAX(CLOSE, n)/CLOSE[0]-1 >= 10%. BAR_COMPLETED_CORRECTION is true if BAR_IN_CORRECTION[0] is false and BAR_IN_CORRECTION[1] is true. BAR_IN_ATH is true if CLOSE[0] > MAX(CLOSE, n)[1]. BAR_COMPLETED_ATH is true if BAR_IN_ATH[0] is false and BAR_IN_ATH[1] is true Increment p when BAR_IN_CORRECTION[0] is true and count since last BAR_IN_ATH if any is less than count since previous BAR_IN_CORRECTION. Increment c when BAR_IN_ATH[0] is true and count since last BAR_IN_CORRECTION if any is less than count since previous BAR_IN_ATH. DAYS_SINCE_CORRECTION[c] = count number of days since latest BAR_COMPLETED_CORRECTION for each new BAR_COMPLETED_ATH. DAYS_SINCE_PEAK[p] = count number of days since latest BAR_COMPLETED_ATH for each new BAR_COMPLETED_CORRECTION. The latest measurement will be incomplete until the opposite "direction" starts occuring. You can optimize using indexes as reference instead of using boolean values for each bar. Should be easy to implement in most imperative languages, though I prefer to stay away from SQL and PL/SQL if I can.