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

Notas de Lançamento: Fixed bug in Setup Buy signal, pointed out by @fernandofurtado
Notas de Lançamento: - 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"
Notas de Lançamento: - Added TD Risk Level for setups, countdowns, and recycled events. Disabled by default.
- Reduced shading between TDST support/resistance, when resistance is below support.
Notas de Lançamento: Release Notes: Added alert conditions for setups, countdowns and recycled countdowns. See code comments (near the top) for a full description.
Script de código aberto

No verdadeiro espírito TradingView, o autor deste script o publicou com código aberto, para que os traders possam compreendê-lo e verificá-lo. Um brinde ao autor! Você pode usá-lo gratuitamente, mas a reutilização deste código em uma publicação é regida pelas Regras da Casa. Você pode favoritá-lo para utilizá-lo em um gráfico.

Quer usar esse script no gráfico?


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.
+3 Resposta
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
+1 Resposta
fernandofurtado fernandofurtado
Sorry, we cant upload images.
fernandofurtado fernandofurtado
@brobear, the comments about the countdown should be ignored. They should work as you code them. I'm confusing myself already. Sorry!
@brobear, the problem just recently showed up again, so I went to check it one more time. Look at line 251. You may have forgotten of replacing "setupSellPerfPrice" by "setupBuyPerfPrice".
+1 Resposta