With crypto markets trading 24/7, I wanted to adjust the behavior of the sequential counts to "dial in" a market. Default settings replicate the original TD Sequential behavior (9s and 13s), but you can select other numbers to better fit your market and timeframe.
It took awhile for me to learn TD Sequentials and Pine, so I added a lot of comments in the script to keep myself organized. My hope is that, with a flexible tool in hand, crowd wisdom will converge on effective settings (maybe the defaults... maybe not!)
- Minor adjustment to calculation of deferred perfected Setup events (pointed out by @fernandofurtado): all bars are evaluated during a deferred window, rather than just bars counting in the same trend.
- Added a short title to the indicator: "TD Seq"
- Reduced shading between TDST support/resistance, when resistance is below support.
To make the TD number stable at the open of the candle, click:
format (gear icon) -> Input -> Price: Source -> open
About 10 minutes in, he shows you how to copy someone's script into your own library. Once copied, you can delete all the notes (comments) in the code.
As described by Perl:
The high of TD Sell Setup bars eight or nine or a subsequent high must be greater than, or equal to, the highs of TD Sell Setup bars six and seven.
TD Sell Setup perfection is deferred until THAT happens, and, as long as that situation exists, the risk is for a RETEST of the price high of bars six or seven.
In the case of the Sell Setup, the issue happens when you have a bar with a high higher than bars 6 and 7 but it closes lower than the close of 4 bars earlier (it's a bar of setupCountUp, as you define). In this case, we had a test of the 'setupSellPerfPrice' but the Setup Sell wasn't perfected. The word 'retest' seems to support the interpretation that all we need for the 'perfection' is a high >= 'setupSellPerfPrice', no matter if it is a bar of setupCountUp or setupCountDown.
That might be important for trading small timeframes. It's a little thing, but let me know what you think about it.
I captured a picture of a deferred perfected setup on a 12 min chart. (It's a private "idea", so I hope this link works...)
So you're asking if the proper interpretation of Perl's notes mean:
1) (What the picture shows...) Deferred perfected setups can happen, even if the setupCountUp stops counting... or
2) The deferred perfected setup should have been cancelled when setupCountUp stops counting, i.e. no perfection event should occur (in the picture)
See Figure 1.10 (page 41-ish) in Perl's book. It gives an example of a deferred perfected Setup Buy signal, where the setupCountDown stops counting, but a deferred perfected signal is generated... This is what I based my logic on.
Am I understanding your question correctly?
na(setupSellPerfMask) ? na :
na(setupCountUp) or na(setupCountDown) ? setupSellPerfMask :
((valuewhen(setupCountUp, high, 0) >= setupSellPerfPrice) or
(valuewhen(setupCountDown, high, 0) >= setupSellPerfPrice)) ? (Additional line)
setupIsPerfected : setupSellPerfMask
setupSellPerfMaskImp = na
setupSellPerfMaskImp := setupCountUp or setupCountDown ? setupSellPerfMask : na adds 'setupCountDown'
Does it make sense?
Aaah... I see what you're talking about.
The comment on line 208:
// - If mask is deferred, check only setupCountUp events for perfection, until cancelation.
... your understanding is:
// - If mask is deferred, check all bars (countUp or countDown) for perfection, until cancelation.
That would change lines 218-221 to be (like you mention above):
na(setupSellPerfMask) ? na :
(high >= setupSellPerfPrice) ? setupIsPerfected : setupSellPerfMask
// once the mask is turned on, look for perfection on any bar
(and the same for setupBuy...)
I found an example
Yeah, I can see how this change will help. I'll change it. Stay tuned... it'll take a day or so for me to test and upload.
Another good catch!!