[justlurkin]

Originally Posted by Head2k »

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]

Originally Posted by Head2k »

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]

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]

Originally Posted by Head2k »

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]

Originally Posted by jperl »

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]

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]

Originally Posted by BlowFish »

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]

Originally Posted by Head2k »

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.