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.
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) 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!
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'.
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?
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