NexusFi: Find Your Edge


Home Menu

 





VSA for ThinkorSwim


Discussion in ThinkOrSwim

Updated
      Top Posters
    1. looks_one snowcloud with 93 posts (25 thanks)
    2. looks_two StockJock with 91 posts (27 thanks)
    3. looks_3 cbritton with 37 posts (71 thanks)
    4. looks_4 swimtrader with 22 posts (19 thanks)
      Best Posters
    1. looks_one Hornblower with 2.3 thanks per post
    2. looks_two cbritton with 1.9 thanks per post
    3. looks_3 StockJock with 0.3 thanks per post
    4. looks_4 snowcloud with 0.3 thanks per post
    1. trending_up 304,671 views
    2. thumb_up 223 thanks given
    3. group 86 followers
    1. forum 434 posts
    2. attach_file 131 attachments




 
Search this Thread

VSA for ThinkorSwim

  #41 (permalink)
 
cbritton's Avatar
 cbritton 
Atlanta, Georgia
 
Experience: Intermediate
Platform: NT
Broker: DDT
Trading: ZN, ZB
Posts: 230 since Mar 2010
Thanks Given: 152
Thanks Received: 256


snowcloud View Post

On another topic I found a possible bug in the code for noSupplyBar. The code for noDemandBar fits pretty well with the description of No Demand and of a No Demand Up-Bar in the glossary of Williams' first book Master the Markets. The study defines it as an Up bar with narrow spread closing down on volume that has been decreasing over a 2 bar period. Williams' book doesn't define it quite as explicitly but the study's code seems to be a good fit.

def noDemandBar = (isUpBar[0] && isNarrowSpreadBar[0] && isTwoDaysLowVol && isDownCloseBar);

However, in the code for noSupplyBar I think that the last term should be isUpCloseBar not isDownCloseBar. No Supply implies lack of selling pressure which would be more evident if the bar closes up not down.

def noSupplyBar = (isDownBar[0] && isNarrowSpreadBar[0] && isTwoDaysLowVol && isDownCloseBar);

****
I am going through the study's code line-by-line and comparing it with Williams' definitions and descriptions. I'll report issues as I find them.

I checked the VPA code in the NT download section on futures.io (formerly BMT). This is how the noDemandBar and noSupplyBar are defined:

 
Code
                            
            // ndbar, nsbar
            
noDemandBar = (isUpBar[0] && isNarrowSpreadBar[0] && isTwoDaysLowVol && isDownCloseBar); 
            
noSupplyBar = (isDownBar[0] && isNarrowSpreadBar[0] && isTwoDaysLowVol && isDownCloseBar); 
Which matches what I originally ported to ToS. Keep in mind that I'm pointing this out because if snowcloud is correct in the interpretation of noSupplyBar, then users of the NT version are also affected and should be aware of this issue.

Regards,
-C

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” - Sun Tzu
Started this thread Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Better Renko Gaps
The Elite Circle
Deepmoney LLM
Elite Quantitative GenAI/LLM
Ninja Mobile Trader VPS (ninjamobiletrader.com)
Trading Reviews and Vendors
Online prop firm The Funded Trader (TFT) going under?
Traders Hideout
Build trailing stop for micro index(s)
Psychology and Money Management
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Get funded firms 2023/2024 - Any recommendations or word …
60 thanks
Funded Trader platforms
43 thanks
NexusFi site changelog and issues/problem reporting
24 thanks
GFIs1 1 DAX trade per day journal
22 thanks
The Program
19 thanks
  #42 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25

Thanks for making the LRS more clear!

Reply With Quote
  #43 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25


I made c's suggested change to the CloseBar assignments and it definitely fixes the bug in which a bar initially reports that it's a VeryHighCloseBar. Now it reports correctly that it's a MidCloseBar. The Pink Square Tests for Supply seem to be reporting more accurately now as well. There are no more erroneous Pink Squares reported when the close is at the bottom of the bar.

def x1 = if (high == low) then 2.0 else if (close == low) then 2.3 else (spread / (close - low));

However, there's still a problem with differentiating between a DownCloseBar and a VeryLowCloseBar. In fact, the code below ensures that "Very Low" is never reported. Because the else statement for isDownCloseBar executes for all cases in which x1 > 2, anything above that is never reported as Very Low, even if it is. Not only that, everything in between 1.8 and 2 is not reported accurately either because isUpCloseBar executes for all values of x1 < 2. So isMidCloseBar's with values of x1 <2 are not reported as MidClose but instead as UpClose.


AddChartLabel(trendText, concat("Close: ", if (isVeryHighCloseBar) then "VH"
else if (isUpCloseBar) then "H"
else if (isMidCloseBar) then "M"
else if (isDownCloseBar) then "D"
else "Very Low"), Color.white);

It appears to me that in the line below the (close==low) test is there to filter out the possibility of a divide-by-zero in the (spread / (close-low) code. As a result of this special case filter, there are some undesirable artifacts that play out further into the study. In addition, there is no isVeryLowCloseBar assignment at all.

def x1 = if (high == low) then 2.0 else if (close == low) then 2.3 else (spread / (close - low));

I am experimenting with creating a new isVeryLowCloseBar variable and with various ways of accounting for the full range of CloseBars - Very Low, Low, Mid, High, and Very High. Also worth considering is whether two additional categories for UltraLow and UltraHigh should be added. I'll also experiment with different values for the Mid-range and for what qualifies as Very High ( x1<1.35) and Very Low (currently 2.3).

Reply With Quote
  #44 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25


snowcloud View Post


2. 2 bars at 5:28 AM PT on GDP news. Red Triangle BEFORE Red Square - Red Tri 3030, 3069, 3029, 3041, vol = 3,052 [huge]; Red Square 3041,3043, 3024, 3027, vol = 2,359 [Big]. I don't understand why the Triangle confirmation appeared in the bar BEFORE the initial upThrust Red Square.

I now understand how under certain conditions a confirmed upThrust Red Triangle can appear BEFORE an upThrust Red Square as in the example above. isConfirmedUpThrust can be set to true by any of three different upThrust conditions - one of which is that the volume of the bar currently displaying a Red Square is 2 times the average volume. If the volume increases to that level before the bar closes, the Red Square will turn into a Red Triangle. The next bar could be a Red Square if it satisfies the the conditions for isUpThrustBar which is entirely possible.

All of this begs the question, however, of why certain bars are defined as upThrusts even though they don't exhibit the Gravestone Doji appearance caused by a spike up followed by a return to the lows of the bar before it closes. Here is Tom Williams' definition: "Upthrusts can be recognized as a wide spread up during the day (or during any timeframe), accompanied by high volume, to then close on the low." He adds "Note the day must close on or very near the lows; the volume can be either low (no demand) or high (supply overcoming the demand)." There is nothing in the code below that requires there to be a substantial move up before the move back to the lows. Frequently I see bars with Red Squares or Triangles that are medium-to-big down bars with very little wick on either side. I don't think that these really qualify as upThrusts. Perhaps something like && ((high - close) > (close-low)) or ((high - close) > 1.5*(close-low)) should be added after isDownCloseBar.

# utbar
rec isUpThrustBar = isWideSpreadBar && isDownCloseBar && ShortTermTrendSlope > 0;

Reply With Quote
  #45 (permalink)
 
cbritton's Avatar
 cbritton 
Atlanta, Georgia
 
Experience: Intermediate
Platform: NT
Broker: DDT
Trading: ZN, ZB
Posts: 230 since Mar 2010
Thanks Given: 152
Thanks Received: 256


snowcloud View Post
I now understand how under certain conditions a confirmed upThrust Red Triangle can appear BEFORE an upThrust Red Square as in the example above. isConfirmedUpThrust can be set to true by any of three different upThrust conditions - one of which is that the volume of the bar currently displaying a Red Square is 2 times the average volume. If the volume increases to that level before the bar closes, the Red Square will turn into a Red Triangle. The next bar could be a Red Square if it satisfies the the conditions for isUpThrustBar which is entirely possible.

All of this begs the question, however, of why certain bars are defined as upThrusts even though they don't exhibit the Gravestone Doji appearance caused by a spike up followed by a return to the lows of the bar before it closes. Here is Tom Williams' definition: "Upthrusts can be recognized as a wide spread up during the day (or during any timeframe), accompanied by high volume, to then close on the low." He adds "Note the day must close on or very near the lows; the volume can be either low (no demand) or high (supply overcoming the demand)." There is nothing in the code below that requires there to be a substantial move up before the move back to the lows. Frequently I see bars with Red Squares or Triangles that are medium-to-big down bars with very little wick on either side. I don't think that these really qualify as upThrusts. Perhaps something like "&& ((high - close) > (close-low)) or ((high - close) > 1.5*(close-low)) should be added after isDownCloseBar.

# utbar
rec isUpThrustBar = isWideSpreadBar && isDownCloseBar && ShortTermTrendSlope > 0;

I think isWideSpreadBar is supposed to indicate a larger than normal spread of the bar, but you are right, there's nothing to indicate that there was a substantial up move to begin with. The problem as I see it is that there could be a case where the open is close to the high and the bar just drops. isWideSpreadBar would be true if it met this condition:

rec isWideSpreadBar = (spread > (wideSpreadFactor * avgSpread))

Considering the second part of what you added: "Note the day must close on or very near the lows; the volume can be either low (no demand) or high (supply overcoming the demand)." There is no use of volume in the above definition of isUpThrustBar. Perhaps adding these conditions may make it conform to Williams' definition:

 
Code
                            
# utbar
rec isUpThrustBar isWideSpreadBar && isDownCloseBar && ShortTermTrendSlope && open<(high+low)/&& (noDemandBar or noSupplyBar); 
  • open< (high+low)/2
    This makes the distinction that the open is lower than the midpoint of the bar. The thrust up would have to have happened during the timeframe of the bar before it closes at or near the low. This condition is somewhat arbitrary since there could be more refined setups. I.e. the open is at or near the low.
  • noDemandBar or noSupplyBar
    This addresses the second condition of high or low volume bar
Does this make sense?

Regards,
-C

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” - Sun Tzu
Started this thread Reply With Quote
  #46 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25


cbritton View Post
I think isWideSpreadBar is supposed to indicate a larger than normal spread of the bar, but you are right, there's nothing to indicate that there was a substantial up move to begin with. The problem as I see it is that there could be a case where the open is close to the high and the bar just drops. isWideSpreadBar would be true if it met this condition:

rec isWideSpreadBar = (spread > (wideSpreadFactor * avgSpread))

Considering the second part of what you added: "Note the day must close on or very near the lows; the volume can be either low (no demand) or high (supply overcoming the demand)." There is no use of volume in the above definition of isUpThrustBar. Perhaps adding these conditions may make it conform to Williams' definition:

 
Code
                            
# utbar
rec isUpThrustBar isWideSpreadBar && isDownCloseBar && ShortTermTrendSlope && open<(high+low)/&& (noDemandBar or noSupplyBar); 
  • open< (high+low)/2
    This makes the distinction that the open is lower than the midpoint of the bar. The thrust up would have to have happened during the timeframe of the bar before it closes at or near the low. This condition is somewhat arbitrary since there could be more refined setups. I.e. the open is at or near the low.
  • noDemandBar or noSupplyBar
    This addresses the second condition of high or low volume bar
Does this make sense?

Regards,
-C

Coincidentally, as I am reading your message I am looking at two Red Square upThrusts on my screen right now. Both of them have small wicks at the top which are higher than the high of the previous bar indicating that the price did indeed spike up at least a little before falling. Neither of them is a Gravestone Doji but both of them did in fact forecast a fall to lower prices ahead which is what upThrusts are supposed to do. So I'm starting to think that requiring them to have larger wicks on top is getting too picky. As a compromise how about adding

&& (high != open)

so that at least some wick is required? (I'm not sure about the "!=" notation for the language TOS uses - I'll have to look at it later to confirm). Part of my reasoning here is based on the fact that what I am seeing is based on 2-minute candles. If I had been looking at a 5-min candle in the two examples above Gravestone Dojis would have been displayed. As I type this I realize that even if the candles in question had high=open both of them would have been Gravestone Dojis on a larger timeframe. So, my conclusion as of this moment is that we should leave the code alone and I'll keep observing Red Squares on 2min candles and mentally combine them with preceding candles to see if Gravestones would have ensued. Whew!

I don't think we have to be concerned about volume here as Williams doesn't seem to be and presumably Wyckoff either.

Bottom line - for now I'm going to leave the upThrust code as it is and keep observing.

Reply With Quote
  #47 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25

I just noticed a Gravestone Doji followed by a downbar which led to a decline in price which was not reported as an upThrust. The reason? 20 - 24 bars ago there were 4 huge bars which greatly increased the avgSpread. Because the study's test for upThrust requires an upThrust to be a WideSpreadBar this particular candle did not qualify. Its spread was reported as Narrow because of the bias introduced by the 4 huge bars. Just an observation; I'll keep watching.

Reply With Quote
  #48 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25

I just noticed that there is an inconsistency in the way "Lime" and "Green" are commented in the code. Up until now I hand't noticed that even though both Lime and Green are referenced in the "set the shapes for graph" comments only Green is used in the actual code for symbol color. I have been trying in vain to see the difference between Lime and Green squares, circles, and triangles on the screen. Now I know why my efforts have been unsuccessful! There are only Green versions of each.

That being ssid, green and lime are used for the bar colors and the difference is subtle, but observable.

Reply With Quote
  #49 (permalink)
snowcloud
LA, CA
 
Posts: 93 since Jul 2010
Thanks Given: 2
Thanks Received: 25

For some reason the system is blocking me from editing my own messages. Thus, I was unable to change "ssid" to "said" in the last message.

Reply With Quote
  #50 (permalink)
MAXX
Madera
 
Posts: 2 since Aug 2010
Thanks Given: 0
Thanks Received: 0


IS THERE CODING FOR TOS TO COUNT BARS. LIKE TS HAS. EACH BAR WILL HAVE ITS NUMBER ON THE BOTTOM OF CHART?
THANKS

Moderator Notice
Moderator Notice


Reply With Quote




Last Updated on May 21, 2023


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts