Value Areas - dValueArea

[cclsys]

1. The "Diff" line (green)?
This is the difference between the POC and the VWAP?

Answer: there is an option (first input). Either its the difference
between the last closing price and the vwap, or the closing price and
the PVP. So the line shows you how far away you are from the PVP. (I
usually choose PVP). That PVP is the zero line so the bands are drawn
above and below that zero line, the theory being that this is the last
generally agreed upon fair market price.

2. YOur dskew script is "within" dvalue script, and I can see the sam
options ie: Evloving VAt, VAb, POC etc..but I'm not understanding. The
dvalue options do not appear on the chart?
This is correct is it?

Answer: Yes. You don't have to load Dvalue in the main chart, but of
course I usually do. This indy is designed to go in the lower panel.

If so, then I pressume you just needed to have the dvalue script to
make your dskew,? which is all ok I just wanted to understand.?

Answer: I am not sure if you need it. I think the indicator works on
its own since I just added stuff inside the Dvalue, but at the same
time I took away certain things like plotting the histograms etc.
You'll have to look at the code. The simplest thing is to have both
(like I do), but in answer to your question I am pretty sure the skew
indy will run on its own.

As it happens, I have been making good use of those very same "dvalue"
Evolving VAt, VAb and POC lines on a range chart, but have to have
that dvalue indi loaded in addition to your dskew, to see them on the
chart. (sorry to ramble)

3. Forgive my ignorance here, but can you expalin the "blue" and
"gold" "skew up " skew down" histogram a little.?
How does this differ from the "Diff" line?

Answer: the blue (bear color) and gold (bull color) represent the skew
of the difference between the vwap and the PVP. If the vwap > PVP,
then this is a positive skew; if vwap < PVP this is a negative skew.
The plots show how far away the vwap is from the PVP, getting larger
the bigger that difference is.

Meanwhile, going back to Question 1, you also have the difference
between the current price and the PVP (or vwap depending on which
option you choose).

I am not yet sure if this indicator is helpful, but it sure is
different. I find it is VERY good at signalling the end of a move.
Let's say we are in an upmove. Price goes through a PVP from lower
down and makes a nice move up. Then there is backing and filling as
the move gets to the end, corrects back down a little, tries to go
higher again, and at this point the PVP 'flips' to somewhere up near
the new high. And so now the PVP is way above the Vwap which is slowly
rising like vwaps always do. At this point, the vwap-PVP relationship
has changed. Before, the vwap was a little above the old PVP as the
market was rising, and now the vwap is below the new PVP. The skew has
flipped to negative. Now that doesn't mean the bull market is over.
But it often can be the case that it will pause for a long time or
maybe even correct back down to the previous PVP (often happens except
in very strongly trending markets). So it's a good place to look for
exits if you are long, or tighten stops as soon as market tries to
make a new high and fails etc. That PVP flip can often (but of course
not always happen) long before many other types of momentum-type
indies will have turned so in some sense its a leading indicator. And
no periods to adjust, works on all charts.

The ONLY problem now is the way Dvalue calculates the price-volume
histograms: since it averages out the distribution over the range of
the bar, when you use 30 min bars, you are getting very rough
guidelines. If you load Gomi's Volume Histogram which builds them tick
by tick based on bid-ask sales, you can see that although most of the
time DValue is good, sometimes it is not, and this is especially true
with longer-length bars. That said, sometimes DValue is better than
the real price because it is like an average of the market action,
i.e. it is smoothing out particular bars/prices where action happened
at one time so giving a more general, average picture and sometimes
this is more helpful than the far more precise, but sometimes less
clear 'actual' picture from a live-updating equivalent like Gomi's.

Hope this helps. If you have any other questions, fire away!

[kumar]

DvalueSkew

Hello cclsys,

Just got the indicator loaded - lot of work!
I looked through the code but in the dark as to how to interpret (use) this, any pointers?
Thanks,
Kumar

[cclsys]

Found a way to synchronise hvwap within a DValueAreaSkew Indicator by changing hvwap's start/end times in the Properties Menu from Settings to Paramaters. Now the Skew Indy and vwap start at same times.

Note: if you download this code it will change your hvwap Properties Menu so back up the hvwap first if you want to be sure to preserve it.

The lines changed are:
"[Description("hVWAP Start Time. hh:mm:ss (24 hr clock). If Start Time >= End Time then indicator ends on following day. Does not span more than 24 hours.")]
[Category("Parameters")]
[Gui.Design.DisplayName("\t\t\t\t\t\tStart Time")]
public string StartTimeString

.....

and the same for the End Time section where I changed 'Settings' in original code to "Parameters" in section above. That was it. Getting the Skew indy to read the start-end times was a little tricky, but luckily am getting a little better and Ninja script now and it didn't take long to figure out.

Whether this indy is helpful or not is too early to say, although it does show promise and is original. At least now it is easy to set up with indy values reflecting same calcs as those on main chart, which wasn't the case before.

[DeanV]

If you want to try to update to NT7 - at least 2 things I know of so far...

IntSeries - NT7 defaults these to 256. This program needs ALL so the call needs changed as per post 59 in this thread.

I also used a few calls to ChartControl.GetXByBarIdx on the last version. The params on this are different in NT7 also so would need changing.

There may be others, but I don't have NT7 yet, so cant tell you more.

[aviat72]

I am curious on what needs to be done to port this indicator to NT7.
I presume it has to do with session support and the legacy drawing functions.
Does NT7 not have similar drawing functions?

[cclsys]

cclsys, my coded does it's own thing in regards to session id's. Though not perfect in all casses, it does allow sessions through the overnight. To match other indicators to that, I would use that.

If you want to try and modify a version of the code, it's really not that hard. In the OnBarUpdate, look at how the added "if(showRtPOC)" works, and do something like that except instead of calling StuffHits_BarRange, call your new code to calc what you want. Add or reuse plot lines you want to plot the new stuff, and you have the basics. I'd default PresentMethod to zero, or just delete the Plot call, since you wouldn't need any of that.

Hope that helps.

DeanV: thanks for that. I missed it earlier for some reason. Don't understand it, but will go back to school and maybe all will become clear!

On separate thread posted a dynPVP error pic.

http://www.ninjatrader-support2.com/vb/showpost.php?p=143192&postcount=113

[T2020]

OK , thanks for posting back Dean . Perhaps finalg is following a different
set of rules . Thought I'd ask anyway . Thanks again .

[DeanV]

T2020, I have no idea why it's not matching for you. I don't have the finalg app to compare with. I imagin it could be any of 100 different little things. On my app, the number of slots may combine price points, if the tick range for that day is larger than the total slots selected (program has 500 as a max, but you could change code to allow more, down in the properties area).

This app uses the data from the chart selected (calc's per 5 min. bar on a 5 min. chart), where some other's may use a different underlying data stream (calc's off of per tick data, regardless of chart size). Could get differences with that.

I am doing the calcs. as you mentioned, so that's not it (unless it's not doing it correctly).

Dean.

[T2020]

DeanV .
I notice that the Real time Poc doesn't always match what is seen on the
profile chart . I think because the rules are like this : ( found this on the web).

• The POC is the price at which the most TPO's have printed.
• If there is more than 1 price with the same 'most' TPO's then the price closest to the mid-point of the range (high - low) is used.
• If the 2 'most' TPO prices are equi-distance from the mid-point then the price on the side of the mid-point with the most TPO's is used.
• If there are equal number of TPO's on each side then the lower price is used.]]]

I couldn't tell from the code if these were considered or even right ,but it'd
be nice to have things match up . Just a thought . thx .

[DeanV]

cclsys, my coded does it's own thing in regards to session id's. Though not perfect in all casses, it does allow sessions through the overnight. To match other indicators to that, I would use that.

If you want to try and modify a version of the code, it's really not that hard. In the OnBarUpdate, look at how the added "if(showRtPOC)" works, and do something like that except instead of calling StuffHits_BarRange, call your new code to calc what you want. Add or reuse plot lines you want to plot the new stuff, and you have the basics. I'd default PresentMethod to zero, or just delete the Plot call, since you wouldn't need any of that.

Hope that helps.

[cclsys]

DeanV,

pardon my obtuseness, but what changes did you make. Don't see anything in the comments and the menu panel seems the same too.

[cclsys]

Thanks for the upgrade DeanV. Am finding the dynamic PVP extremely helpful; indeed, it has become the main SR value I follow and compare everything in relation to it: current price, direction, previous PVP's or other key SR prices etc.

My only frustration now is not with DValue but simply that I wish it were possible to set up a chart easily with vwap and Dvalue starting at same time. No, that I can do. I wish I could have the vwap start-time 'callable' in another indicator - such as yours - so I could experiment with different skew indicators.

Here's a pic to give you an idea of what I did, but when calling the vwap in another indicator, it always starts at midnight and I really prefer to start things in the am shortly before the offficial openings.

If I posted this earlier forgive me.

( The idea behind the indicator, in case you or anyone else is interested, is that the colors of the main skew value plot change depending on whether it's positive or negative skew; then there are ATR bands, the inner bands being 1 or 2 * current ATR (21) from the dynamic PVP, and the outer being 9* that value. But when price is within the inner bands it indicates that it might be in congestion area since price is hovering around near the PVP. Just a thought, but would really prefer to get the vwap and dvalue being able to start at different times together somehow. No idea how to do it.

These congestion zones are indicated by the shaded back color. As you can see, it is quite accurate and pretty fast, possibly one of the best 'chop' indicators I have seen. And no need to play around with too many variable periods etc. as with most such approaches. Set it and forget it. Probably could be helpful in automated systems etc. which I don't play with since never able to code even the simplest, most basic strategy in Ninja Script and have decided not to even try. Also hate the strategy development interface and optimization parameter display. By far the worst I have ever worked with including early offerings back in the days of Windows 3.1. Still, suspect this skew (congestion) indicator might be helpful for those who do work on such things! )

[T2020]

t2020,
on finalg use vol not tpo. you will get very close.

Ok thanks . I see it expanses the value area a bit ,but maybe that's a
more accurate target .....?

[meyer99]

t2020,
on finalg use vol not tpo. you will get very close.

[T2020]

I'm doing a demo of the Final financial algorithms Marker Profile TPOchart
indicator . I've double checked all the settings , but there value area and
poc are quite different then yours . I don't know what's different ,but it
always seems hard to get different indicators displaying the same thing to
match up . frustrating ......