Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I checked the VPA code in the NT download section on futures.io (formerly BMT). This is how the noDemandBar and noSupplyBar are defined:
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
Can you help answer these questions from other members on NexusFi?
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).
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.
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:
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:
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
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.
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.
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.