Trading with Market Statistics XI. HUP

[Trader333 10]

I decided to try Jerry's approach today and with anything like this I prefer to limit my risk before I am familiar with the method so I decided to try it on the Dow Mini Future (YMM8) with 2 contracts. I have attached two screenshots of my entry and exits and I would appreciate feedback from others who have been using this. The trade was profitable with +8.5 and +23.5 points so even if I did not do things as I should have it has not cost me a loss

 

 

 

Paul

[jperl 11]

I decided to try Jerry's approach today and with anything like this I prefer to limit my risk before I am familiar with the method so I decided to try it on the Dow Mini Future (YMM8) with 2 contracts. I have attached two screenshots of my entry and exits and I would appreciate feedback from others who have been using this. The trade was profitable with +8.5 and +23.5 points so even if I did not do things as I should have it has not cost me a loss

 

 

 

Paul

 

 

Good setups and good trades Paul. You've got the basics down correctly. Notice also that if you missed the trade at the VWAP you could have entered at the retrace back to the 1st Standard Deviation.

[Trader333 10]

Good setups and good trades Paul. You've got the basics down correctly. Notice also that if you missed the trade at the VWAP you could have entered at the retrace back to the 1st Standard Deviation.

 

I did wonder about that Jerry so thanks for this.

 

 

Paul

[jperl 11]

I did wonder about that Jerry so thanks for this.

 

 

Paul

 

Also think about what you would have done if the trade at the VWAP had not gone your way. Would you have exited the trade at the PVP or done something else?

[Trader333 10]

Hi Jerry,

 

I would have exited at either the PVP line or 1st Standard Deviation away from entry whichever was nearer at the time. Is that how you would have played it ?

 

Also when you said that I could have entered at the retrace back to the 1st Standard Deviation, would you exit if the trade went against the position at the 2nd Standard Deviation ?

 

 

Paul

[jperl 11]

I would have exited at either the PVP line or 1st Standard Deviation away from entry whichever was nearer at the time. Is that how you would have played it ?

 

That is what most traders would do and in my opinion leads to a slow bleed of your capital. To avoid that you have to have a complete change of thinking about stop losses. You might want to reread the thread on [thread=2189]"Scaling in and Risk Tolerance"[/thread] to get a different perspective.

 

Also when you said that I could have entered at the retrace back to the 1st Standard Deviation, would you exit if the trade went against the position at the 2nd Standard Deviation ?

 

Not sure I understand what you are asking. If you had entered at the 1st SD and the trade went to the 2nd SD then I would have exited at the 2nd SD for a profit. If I didn't exit at the 2nd SD, I would have not allowed the trade to become a loser. I would then have exited 1 tick below my short entry.

On the other hand if I entered at the 1st SD and the trade went immediately against me, I would have scaled in another contract at the VWAP.

[Trader333 10]

Hi Jerry,

 

I have already read "Scaling in and Risk Tolerance" and will apply it when I am happy that I have the basics correct. Previously I have always used a volatility based position sizing strategy so that my risk is consistent for any trade I take. I noted your comment about only becoming consistently profitable when you started using scaling in your trading. There will be some adjustment for me on this as I am not able to use my previous approach to position sizing so a change in mindset is needed which I will work on.

 

Thanks for your replies as I am finding your comments of real use.

 

 

Paul

[maildigger 10]

Jperl, would you agree that your trading-methodology works best if we have a trend(day) ?

[Trader333 10]

Jperl, would you agree that your trading-methodology works best if we have a trend(day) ?

 

If you have read all the threads then it should be just as successful on a non trending day as any other. On the non trending days it is more likely that the VWAP price will be close to that of the PVP price and on these days you would take a trade at 2SD with the aim of closing out at 1SD or at VWAP.

 

 

Paul

[jperl 11]

Jperl, would you agree that your trading-methodology works best if we have a trend(day) ?

 

You don't need a trend day for market statistics to "work". What ever the day is, market statistics will reveal it by the the shape of the volume distribution function. How you use this information will be different for different traders.

I've just given a few examples of how you might employ it.

[Northern boy 10]

interesting, thanks Jperl.

[jgotchev 10]

Thank you for a lovely discussion, Jperl. I find a lot of validity and usefulness to your methods. I do have one question, though. Since the skew of the volume distribution is such an important part of your analysis, why not use other methods for estimating it. Rather than rely on the position of the mode so much, one could use the median or better yet, compute it in the classical way as the third moment of the volume distribution. The reason I ask is that a lot of times in the markets we have the PVP but also another price with almost as much volume. Also, sometimes there are clusters of volume that don't neccessarily include the PVP but could also act as a HUP. The point I am trying to make is that the relative position of the PVP and the VWAP is not always a reasonable estimate for the actual volume distribution skew and I was wondering if you have looked into it.

[jperl 11]

Thank you for a lovely discussion, Jperl. I find a lot of validity and usefulness to your methods. I do have one question, though. Since the skew of the volume distribution is such an important part of your analysis, why not use other methods for estimating it. Rather than rely on the position of the mode so much, one could use the median or better yet, compute it in the classical way as the third moment of the volume distribution. The reason I ask is that a lot of times in the markets we have the PVP but also another price with almost as much volume. Also, sometimes there are clusters of volume that don't neccessarily include the PVP but could also act as a HUP. The point I am trying to make is that the relative position of the PVP and the VWAP is not always a reasonable estimate for the actual volume distribution skew and I was wondering if you have looked into it.

 

You are perfectly correct, that the exact definition of the skew requires a computation of the 3rd moment. The problem with it is the computation is very cpu intensive. I therefore settled for the approximate value due to Pearson as discussed in the skew tag. The advantage of this is you can visualize the skew just by looking at the volume histogram with the vwap superimposed. The problem is as you point out, when you have two large volume peaks, you don't quite know what the skew is. Nevertheless since you can visualize the volume peaks in relation to the VWAP you can approach the market with caution when this occurs.

 

As far as HUPs go, you are correct again that peaks in the volume distribution are HUPS. Which HUPS you wish to use in your trading is of course a function of your trading style. Keep in mind that HUPS are just that, hold up prices. They are places for you to be cautious as to what to expect.

[Head2k 10]

The problem with it is the computation is very cpu intensive.

First let me thank you for these amazing threads, being a newbie I find them very useful. Second I apologize for my poor English.

Now to the computation of the third central moment. I am not educated in statistics, so I needed to read a few articles in Wikipedia. So please correct me if I am wrong:

 

CM3 = sum(PROBi * (Pi - VWAP)^3),

where

i is going through all prices in range (i.e. all rows in Volume Distribution Function)

CM3 ... the 3rd Central Moment

PROBi = Vi / V ... ith price probability (Volume per ith price / Total Volume)

Pi ... ith price in the Vol. Dist. function

 

Then the Skew would be calculated as

Skew = CM3 / SD^3

 

If this is correct, the computation doesn't seem too CPU intensive to me. I programmed such a computation in AmiBroker and I plotted a line on a chart. The line is VWAP + (Skew * SD). Watching this line together with PVP-to-VWAP relation can be very useful. Now I don't have time to elaborate, but if somebody is interested I can write more later.

 

Ondrej

[justlurkin 10]

First let me thank you for these amazing threads, being a newbie I find them very useful. Second I apologize for my poor English.

Now to the computation of the third central moment. I am not educated in statistics, so I needed to read a few articles in Wikipedia. So please correct me if I am wrong:

 

CM3 = sum(PROBi * (Pi - VWAP)^3),

where

i is going through all prices in range (i.e. all rows in Volume Distribution Function)

CM3 ... the 3rd Central Moment

PROBi = Vi / V ... ith price probability (Volume per ith price / Total Volume)

Pi ... ith price in the Vol. Dist. function

 

Then the Skew would be calculated as

Skew = CM3 / SD^3

 

If this is correct, the computation doesn't seem too CPU intensive to me. I programmed such a computation in AmiBroker and I plotted a line on a chart. The line is VWAP + (Skew * SD). Watching this line together with PVP-to-VWAP relation can be very useful. Now I don't have time to elaborate, but if somebody is interested I can write more later.

 

Ondrej

 

 

 

Can you post a screenshot...

Is this Skew different from (VWAP - PVP) / SD ? More beneficial?

 

 

thanks

[jperl 11]

First let me thank you for these amazing threads, being a newbie I find them very useful. Second I apologize for my poor English.

Now to the computation of the third central moment. I am not educated in statistics, so I needed to read a few articles in Wikipedia. So please correct me if I am wrong:

 

CM3 = sum(PROBi * (Pi - VWAP)^3),

where

i is going through all prices in range (i.e. all rows in Volume Distribution Function)

CM3 ... the 3rd Central Moment

PROBi = Vi / V ... ith price probability (Volume per ith price / Total Volume)

Pi ... ith price in the Vol. Dist. function

 

Then the Skew would be calculated as

Skew = CM3 / SD^3

 

If this is correct, the computation doesn't seem too CPU intensive to me. I programmed such a computation in AmiBroker and I plotted a line on a chart. The line is VWAP + (Skew * SD). Watching this line together with PVP-to-VWAP relation can be very useful. Now I don't have time to elaborate, but if somebody is interested I can write more later.

 

Ondrej

 

Very good Ondrej. You have the skew computation properly weighted. What makes this computation cpu intensive is in real time you have to update the value of PROBi as you add more volume data. Should be okay for a fast machine.

Perhaps you can show us some charts with your skew computation drawn in along with the VWAP and PVP.

[Head2k 10]

Ok, I uploaded screenshots. These are 2min charts for ES for the last 3 business days, counting today. VWAP is the thick yellow line, PVP thick turquoise line, Skew Line (VWAP + Skew * SD) is the thin light blue line. The dark blue area is the area between the 1st SD's, the Value Area in terminology of MP.

If the Skew Line is above VWAP the skew is positive, below VWAP negative. The distance between the Skew Line and VWAP tells you how large is the skew compared to SD. To distinguish the two different methods to determine the skew, I will use terms Skew(PVP) and Skew(3CM).

 

While Skew(PVP) flips (or jumps), the Skew(3CM) is continuous. By the time Skew(PVP) flips the Skew(3CM) Line crosses VWAP, that means Skew(3CM) crosses zero. In other words, if the skew is positive and price action is above VWAP, Skew(PVP) rises while Skew(3CM) decreases. By the time the Skew(PVP) flips, the Skew(VWAP) crosses zero.

Hence the first use of the Skew(3CM) is to warn you before the PVP flip. Another use, surprisingly, is to determine the real statistical skew. The Skew(PVP) has the greatest absolute value right before the flip. That might lead you into some bad trades. If you look at Skew(3CM) you will recognize that the real skew is very small.

As you can see from the charts, it looks like the Skew Line is a minor HUP itself. But I have been watching this only for a couple of days, so I don't want to make any conclusions yet.

[jperl 11]

Ok, I uploaded screenshots. These are 2min charts for ES for the last 3 business days, counting today. VWAP is the thick yellow line, PVP thick turquoise line, Skew Line (VWAP + Skew * SD) is the thin light blue line. The dark blue area is the area between the 1st SD's, the Value Area in terminology of MP.

If the Skew Line is above VWAP the skew is positive, below VWAP negative. The distance between the Skew Line and VWAP tells you how large is the skew compared to SD. To distinguish the two different methods to determine the skew, I will use terms Skew(PVP) and Skew(3CM).

 

While Skew(PVP) flips (or jumps), the Skew(3CM) is continuous. By the time Skew(PVP) flips the Skew(3CM) Line crosses VWAP, that means Skew(3CM) crosses zero. In other words, if the skew is positive and price action is above VWAP, Skew(PVP) rises while Skew(3CM) decreases. By the time the Skew(PVP) flips, the Skew(VWAP) crosses zero.

Hence the first use of the Skew(3CM) is to warn you before the PVP flip. Another use, surprisingly, is to determine the real statistical skew. The Skew(PVP) has the greatest absolute value right before the flip. That might lead you into some bad trades. If you look at Skew(3CM) you will recognize that the real skew is very small.

As you can see from the charts, it looks like the Skew Line is a minor HUP itself. But I have been watching this only for a couple of days, so I don't want to make any conclusions yet.

 

Nice job Ondrej. It looks as if using the exact definition of the skew can provide some useful trading information not available in the approximate Pearson evaluation.

[BlowFish 10]

Very good Ondrej. You have the skew computation properly weighted. What makes this computation cpu intensive is in real time you have to update the value of PROBi as you add more volume data. Should be okay for a fast machine.

Perhaps you can show us some charts with your skew computation drawn in along with the VWAP and PVP.

 

I am not sure but I would guess there is a non iterative way of commuting PROBi. (i.e. not so processor intensive). I'm on vacation with friends and another glass of wine beckons so probably not the time (and in no fit state) to give it thought!

[Head2k 10]

Jerry, I wonder how do you determine the exact PVP level. In fact, I started to dig in the skew stuff only because I was unable to determine an accurate PVP position. With my data feed I don't get volume per price but only volume per bar (i.e. per time unit). To approximately determine the volume per price I take the volume per bar and divide it by the number of prices the bar crosses to obtain the volume unit which I add to every price level that the bar crosses. Now that was an awful sentence but I hope you know what I mean. The problem is that this is an averaging process and every averaging process smooths peaks. To get an accurate volume per price I would need to run the computation on tick database and that would be unusable in real time. On ES I observed that the data base with sufficient accuracy would be 50 tick or less data. That was too detailed for my computer to handle in real time so I started to look for another way to determine the skew. The comptutation of the 3rd central moment is an averaging process itself so it is not so sensitive to the averaging of volume per price. Still, the PVP, as a major HUP, is a significant level and whatever the Skew(3CM) is, you don't want to take your trades across the PVP because it can block the desired price movement.

[Head2k 10]

I am not sure but I would guess there is a non iterative way of commuting PROBi. (i.e. not so processor intensive). I'm on vacation with friends and another glass of wine beckons so probably not the time (and in no fit state) to give it thought!

Being drunk myself I guess I can reply to your idea. I guess that there is no non-iterative way to determine PROBi. But there are two advices I can give you. I am not a programmer, but programming the Jerry's indicator I realized I don't need the re-computation of everything every second. The only thing you need to update continuously is the volume at price. Then, if you know what the V-A-P is, you can recalculate the VWAP, SD's and the Skew say only once per one or two minutes. If you don't want to caculate at all you can use the range middle to determine the skew. I think the range middle to VWAP relation is more appropriate than the PVP to VWAP relation. One can ask himself a question: Where would be the VWAP if there was a symetric distribution? One answer would be: At the PVP, yet another answer could be: In the range middle. Think of the interpretation of the terms or phenomena to make your own conclusion. Combining both approaches would be the best way to approach the real skew without computation.

[jperl 11]

Jerry, I wonder how do you determine the exact PVP level. In fact, I started to dig in the skew stuff only because I was unable to determine an accurate PVP position. With my data feed I don't get volume per price but only volume per bar (i.e. per time unit). To approximately determine the volume per price I take the volume per bar and divide it by the number of prices the bar crosses to obtain the volume unit which I add to every price level that the bar crosses. Now that was an awful sentence but I hope you know what I mean. The problem is that this is an averaging process and every averaging process smooths peaks. To get an accurate volume per price I would need to run the computation on tick database and that would be unusable in real time. On ES I observed that the data base with sufficient accuracy would be 50 tick or less data. That was too detailed for my computer to handle in real time so I started to look for another way to determine the skew. The comptutation of the 3rd central moment is an averaging process itself so it is not so sensitive to the averaging of volume per price. Still, the PVP, as a major HUP, is a significant level and whatever the Skew(3CM) is, you don't want to take your trades across the PVP because it can block the desired price movement.

 

I use ensign software for my charts. The volume histogram with the PVP is one of the studies provided. As you point out, for an exact value of the PVP you would need to compute the volume distribution for every tick. Ensign doesn't do this but uses the volume for each bar distributed equally among the tick increments for the range of the bar. This of course is an approximation.

[Head2k 10]

I use ensign software for my charts. The volume histogram with the PVP is one of the studies provided. As you point out, for an exact value of the PVP you would need to compute the volume distribution for every tick. Ensign doesn't do this but uses the volume for each bar distributed equally among the tick increments for the range of the bar. This of course is an approximation.

So the Ensign computes the volume distribution the same way as I do. on 7/15 I compared the PVP, VWAP and 1st SD's computations on ES from differnt time frames (i.e. bar intervals). Here is the result (All for RTH 9:30 - 16:15, 1st SD's are named VAH and VAL):

 

5 min graph: VAH 1227.03, VAL 1210.78, VWAP 1218.91, PVP 1225.00

1 min graph: VAH 1227.07, VAL 1210.65, VWAP 1218.86, PVP 1218.75

100 tick graph: VAH 1227.06, VAL 1210.62, VWAP 1218.84, PVP 1223.25

50 tick graph: VAH 1227.06, VAL 1210.63, VWAP 1218.84, PVP 1223.0

20 tick and 10 tick graphs computations resulted in the same values as the 50 tick graph. 1 tick graph was too much for my computer to handle.

 

You can see that while VWAP and SD's being averaged values are not much sensitive to the calculation base interval. Yet PVP being a peak level is very sensitive to any kind of averaging. For ES 50 tick data provide the base detailed enough for an accurate calculation.

I realized I am unable to determine dailly PVP from 1 minute database and that brought me to alternative ways of calculation.

[jperl 11]

So the Ensign computes the volume distribution the same way as I do. on 7/15 I compared the PVP, VWAP and 1st SD's computations on ES from differnt time frames (i.e. bar intervals). Here is the result (All for RTH 9:30 - 16:15, 1st SD's are named VAH and VAL):

 

5 min graph: VAH 1227.03, VAL 1210.78, VWAP 1218.91, PVP 1225.00

1 min graph: VAH 1227.07, VAL 1210.65, VWAP 1218.86, PVP 1218.75

100 tick graph: VAH 1227.06, VAL 1210.62, VWAP 1218.84, PVP 1223.25

50 tick graph: VAH 1227.06, VAL 1210.63, VWAP 1218.84, PVP 1223.0

20 tick and 10 tick graphs computations resulted in the same values as the 50 tick graph. 1 tick graph was too much for my computer to handle.

 

You can see that while VWAP and SD's being averaged values are not much sensitive to the calculation base interval. Yet PVP being a peak level is very sensitive to any kind of averaging. For ES 50 tick data provide the base detailed enough for an accurate calculation.

I realized I am unable to determine dailly PVP from 1 minute database and that brought me to alternative ways of calculation.

 

The difference you are seeing in the PVP is most likely due to two peaks with almost the same volume. This will cause the PVP values to jump around from one time frame to another. This is an example where a visual of the total histogram would help you out.

[BlowFish 10]

I have been looking at precise vs averaged for a while now. On the whole the smoothed (average) seems to offer better trading opportunities. Hard to tell really, I certainly don't have enough data. I guess at some stage I will need to ditch one as it does introduce ambiguity. Of course an alternative would be to only trade when they are in agreement.

 

Heres an interesting thing. Normally its the tick precise chart that jumps around but today it was the 2 minute (I guess just how the cookie crumbled).