Trading with Market Statistics XI. HUP

[Head2k]

	Quote:	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]

	Quote:	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.

[Head2k]

	Quote:	jperl
	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]

	Quote:	Head2k
	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]

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

[BlowFish]

I wonder if the fact that "The skewness of a random variable X is sometimes denoted Skew[X]. If Y is the sum of n independent random variables, all with the same distribution as X, then it can be shown that Skew[Y] = Skew[X] / √n." can be exploited to come up with a non iterative approach?

I am having trouble understanding this. Doesnt it mean that you can simply calculate the skew for the first element (which will be zero right?) and then extrapolate from that. I don't understand how that formula can be correct.



Its from http://en.wikipedia.org/wiki/Skewness

[Head2k]

	Quote:	BlowFish
	I wonder if the fact that "The skewness of a random variable X is sometimes denoted Skew[X]. If Y is the sum of n independent random variables, all with the same distribution as X, then it can be shown that Skew[Y] = Skew[X] / √n." can be exploited to come up with a non iterative approach? I am having trouble understanding this. Doesnt it mean that you can simply calculate the skew for the first element (which will be zero right?) and then extrapolate from that. I don't understand how that formula can be correct. Its from http://en.wikipedia.org/wiki/Skewness

I don't think this shows some non-iterative approach. As I said I am not educated in statistics so I am merely guessing, but I think this random variable X is not a single number but actually a discretionary data set or a continous distribution function. So if you want to determine Skew[X] you need to iterate or integrate, anyway.