Value Areas - dValueArea

[pavve]

In the "Initialize()" section add the second Param to IntSeries:
SesNum = new IntSeries(this, MaximumBarsLookBack.Infinite);

At the first glance:
It compiles fine and i don't get any errors in the Trace file after the changes.
regards,

[DeanV]

2.4 update

Posted a 2.4 update in the file area. Adds some display choices for the slots (histogram) and evolving text. No calculations were changed. It does add more incompatability with NT7, so not recomended for that.

[paulg]

Thank you for your new updated contribution, Dean!

[betaride]

Hi DeanV,

Thanks for your great work on this, it's invaluable. The price-volume histogram has been one of the most important tools in my trading.

I have a suggestion/comment though on the combined 24-hr session logic.

Currently, the 24-hr session (PresentMethod = 2 in dValueArea properties) is treated as a combination of the old main session and the old pre-session. This way, the volume histogram, POC, VAH, VAL values for the new main session are calculated using combined data from the old main session and the old pre-session, and I am not convinced that’s the right approach.

I can hardly see any significance of the old pre-session’s data to the new main session. I believe a much better approach is to use the current pre-session data combined with previous (old) main session data to arrive at the 24-hr POC, VAH, VAL values for the new main session.

Would you kindly consider adding the above to your code as an alternative selection/option? I think it would please many traders on this forum...

[DeanV]

betaride, Thanks for the feedback.

I'm not sure what your asking for, so here's some comments...

The POC and VA's are only calculated from the session data as defined by the open time of day + session length within the program (the green slot/histogram area). It never includes the pink area. If you want a 24 hr. result on the POC lines, you should not see an pink, as the program wouldn't identify any presession.

To run a 24 hr session that would include start of 1 session till start of next, just set length of session to 24. (i.e. set start to 8 am, and length to 24), and you would see results for that 24 hr. period. You can set the start time to any time you want.

Hope that helps.

p.s. when setting a 24 hr. session, you sometimes have to add 1 min. to the start time to get it to work right (8:01 in above example), usually on larger timeframed charts.

[paulg]

[...]
p.s. when setting a 24 hr. session, you sometimes have to add 1 min. to the start time to get it to work right (8:01 in above example), usually on larger timeframed charts.

According to European hours,the CME Globex sessions for some instruments (such as fixed in come or fx) are 23 hours long within the same day. For example from 00:00 to 23:00 CET.

Should be a use a 23 hour session (with Starting time at 00:00 an 00 minute and Ending time at 23:00) or a 24 hours session but with your "01" as minute 'tag' according to your suggestion?

[betaride]

DeanV:

Thanks for clarification, it's clear now and it works.

I've wrongly assumed that the 24-hr session is turned on by selecting PresentMethod = 2 (mapping for both pre-session and main session) and that the "sessionlength" property (set to 6.75) just carves the main session length out of the 24-hr window. With these settings, the common value area of the main session extends backwards to the old pre-session (and not forward to the current afternoon session) and that caused the confusion.

That being said, there is one issue remaining with the "sessionlength = 24" setting. The Sunday afternoon pre-session is now treated as a main session and thus the value area for the following Monday session is calculated incorrectly. The way around it is to set "sessionlength = 6.75" just for Monday and switch it back to "24" afterwards, but it would for sure be nice to get this exception resolved.

Neverthless, thank you again for the excellent work you did on this tool!

[DeanV]

betaride, try the "InclWeekendVol" setting both ways. I tried to take that out at one point, but found it helps for week-ends and holiday senerios sometimes. Still may not always catch all of them, and might have to adjust as you mentioned.

paulg, I like the full 24 hrs. better, but find the one that works for you and use that. Depending on what your doing with it, it may not mater too much.

Dean.

[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 ......

[meyer99]

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

[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 .....?

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

[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.

[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.

[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 .