TD Sequential

A flexible rendition of TD Sequentials. Many parameters can be adjusted via user input.

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!)

Release Notes: Fixed bug in Setup Buy signal, pointed out by @fernandofurtado
Release Notes: - Added Aggressive Countdown feature. Countdowns can be switched between normal and aggressive via user input "Countdown: Aggressive"
- 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"
Release Notes: - Added TD Risk Level for setups, countdowns, and recycled events. Disabled by default.
- Reduced shading between TDST support/resistance, when resistance is below support.
Release Notes: Release Notes: Added alert conditions for setups, countdowns and recycled countdowns. See code comments (near the top) for a full description.
Ta bort från favoritskript Lägg till som favoritskript


tracked this on history aaand.. it looks good!))

Are alerts showing realtime or it has some time delay?
+1 Svara
brobear mrgr888n
@mrgr888n, Alerts are realtime, based on the "Price: Source" parameter (default is close). Close is the current price during a bar, so when the price triggers a Setup, Countdown, etc an alert is issued, if you've set them up.

mrgr888n brobear
@brobear, ty for the answer!
I loved this code, man. Seriously, it's excellent. All the things that you added as 'editable' are fantastic. I'm sure that people will come up with some parameters other than traditional TD for 24/7 markets. The deferred stuff that you added in a pretty creative way; I haven't seen anything similar implemented in any other code out there.

Two things that I particularly like in Perl's book are the TD Risk Level and the TD Aggressive Sequential. The first one gives you a pretty nice idea where to place stop losses. And the second one has shown itself quite useful in my trading with crypto. Do you have plans to add these things?

One thing that I like but couldn't reverse it myself was the numbers in the countdown. It kept showing a message of syntactic error in line 463. Do you have any idea what I may be doing wrong?

I also noticed a weird bug that I want to report: the setup numbers from the 144 bar earlier (more or less) and backwards does not show even numbers.

Thank again for your work.
+1 Svara
brobear fernandofurtado
@fernandofurtado, Glad you're finding this script helpful! Thanks for the input...

1) Missing setup (even) numbers less than 144 bars back: correct. This was a design decision I made to keep the chart cleaner, at least for me :)
If you want to display all numbers, all the time, set scpShowLast (line 112) to a large number (1000ish)... or search and remove that variable all together. It limits how many bars back a shape is plotted.

2) Syntactic error at line 463... Hmm. I tried to replicate the problem, but was unsuccessful. So I'm not sure what to say.
I took a clean copy of the script, uncommented lines 466-478 and commented out lines 481-488, which enables plotting Countdown numbers (>7). This complied without error. I wonder if the type of TradingView subscription is involved somehow... ?

FYI, I like having Countdown numbers appear. But, after much deliberation, I opted for generic circles and no numbers because the goal of the script is to try new Countdown limits (e.g. is Countdown 21 more reliable than 13?). Pine limits the number of plot functions in one script (in @version=3 it's 64 plots), and every Setup/Countdown number has to have it's own plot function. And if there is combination logic in a plot function, Pine counts it more than once... somehow (completely undocumented). Anyway... (before I really start ranting about Pine!) there are script limitation tradeoffs to consider.

3) New features, Risk Level and Aggressive Seq.... thanks for pointing this out. I'm relatively new to trading, so I haven't used these yet. I'll start paying attention to them and see how they might be added to the script. But, I'm not sure when that might happen. (At the moment, I'm working on another script that "evolves" DeMark's counting ideas...) If someone beats me to adding these features, chime in!
1) That's ok. I see your point. The problem is we may want to look back at a time to see what happened in given situation and without the numbers it may not be so easy. I'll do it myself following your instructions. Thank you!

2) I'm gonna play with it to make it work later. That's more likely to be my fault.
I was aware of the pine plot limitations, and it sucks. I'm facing the same problem here. I completely understand your point.

3) I'm looking forward to seeing the features I mentioned added, and I'm also curious about your new script.

Thank you for your work!
@brobear, hello, I'm slowly looking at your code, and I've recently noticed one small thing regarding deferred setup perfection. I think it is implementing a requirement weaker than the traditional DeMark's.

The qualification for perfection should compare low/high of bars 6 and 7 with 8 and 9 and so on.
It requires high/low of the bar which reaches perfection to be higher/lower than low/high of the bar 6 AND the bar 7. I think you are using closes instead of high/low and also implementing the logic 'OR' instead of 'AND'.
The funny thing is that in your notes the traditional definition of perfection is precisely correct. What makes me think that it might be a design decision.

I would bet that the 'problem' is somehow related to 'Price Source'.
brobear fernandofurtado
@fernandofurtado, I appreciate your scrutiny... thanks!

I've gone through the code again, and I think I got it right. Here's my logic (focusing on Sell Setups):

Lines 190-195, setupSellPerfPrice grabs the high of bars 6 OR 7, i.e. max high of bar 6 OR bar 7, for comparison later (lines 214-215). The AND logic is implied when bar 8 OR bar 9 (high) must be > setupSellPerfPrice. If ((bar 8 > bar 6) AND (bar 8 > bar 7)) (DeMark's definition), then I figured, why check both when the higher of the two is sufficient? ... Double check me on this!

The function valuewhen() is grabbing the highs for bars 6,7,8,9, etc... so think I'm using high, instead of close. Correct?

@brobear, Your description seems perfect to me. But for some reason, the code is not giving us what we want. And I just realised that a similar problem is also happening with the countdown. I think it is comparing the high of the of the countdown with the close of the candle Q. Something like countdown bar (high) > Q (close). And it should be countdown bar (close) > Q (high). If you take a look at BTCUSD 1h Bitstamp, you'll see how important these small change can make in a trade.

Take a look at the chart; the green arrows are indicating the bars I think should be the 'correct ones'.

/Users/fernandofurtado/Desktop/Screen Shot 2018-03-03 at 01.56.04.png
fernandofurtado fernandofurtado
Sorry, we cant upload images.
Hem Aktie-screener Forex-screener Krypto-screener Ekonomisk kalender Hur det fungerar Diagramfunktioner Priser Tipsa en vän Ordningsregler Hjälpcenter Webbsidor och mäklarlösningar Widgets Diagramlösningar Lightweight Charting Library Blogg och nyheter Twitter
Profil Profilinställningar Konto och fakturering Referred friends Coins Mina kölappar Hjälpcenter Publicerade idéer Följare Följer Privata meddelanden Chatt Logga ut