Head2k

In this post of mine http://www.traderslaboratory.com/forums/6/trading-with-market-statistics-xi-hup-2735-7.html#post43133 there is the Skew Line displayed for ES 9:30 - 16:15 in the first two of the three attachments. Filenames show dates. If you need more, just give me a symbol, date and times (from to) and I will make a screenshot. The date should be within the last two months. However, I observed the Skew Line a bit more and I recognize that sometimes PVP to VWAP relationship is better for description of the price action. Sure the Skew(3CM) is the real statistical skew, yet one has to think about what the skew is and what it means. Skew is "missing expected data" compared to normal distribution. For the skew(3CM) the base of the distribution is formed with whole price range for the examined period (e.g. daily range). In this range we expect normal distribution and skew tells us the deviation from normal. Yet one has to ask if the chosen examination interval is relevant. I attached a chart for ES from the last Friday (08/01). Apparently the opening price at 9:30 was quickly rejected and the market never returned to that area again. This action created missing volme in the top of the daily range and thus a skewed distribution. Notice the thin light blue line (the Skew Line = VWAP + Skew(3CM) * SD) wrapped around the 1st SD for the whole day. Looking back one can recognize that setting the start of the examined interval after the opening price rejection would provide a better insight. On the other hand you can notice that the PVP to VWAP relationship described the real situation much better. Thats because skew(PVP) is not so dependent on the daily range, it smooths low volume excesses. It is only as sensitive to daily range as VWAP is. So each Skew tells you a bit different kind of information. EDIT: Also notice the thick violet line showing the daily range middle. Range middle is mostly a good approximation of the skew line.

Today I improved my code so when it updates VUcount (volume per price) the j-loop doesnt go through all prices seeking where is the actual bar, but first I find the bar borders and then the loop goes only within the bar. With this improvement I can compute the indicator on sevreal days of data without any noticable slowdown, so now it is fully usable for real time even for longer periods of high detailed data.I dont know if AFL is slow or fast compared to other softwares, because I am a beginner and AmiBroker is the first charting software I use But I find it very flexible, so far I could program everything I wanted there.

Yes I do sqrt(Variance) to calculate SD and I do CentMom3 / SD^3 to calculate Skew(3CM). But these operations I do not do within the iteration loop, because AmiBroker AFL is primarily an array processing language. So I do these computations on arrays outside of the iterative loop I posted.

I heaven't read anything from that author but I guess he doesn't say that after a month you should be a master of markets. He says that after a month you should experience the state "there is only the screen and me" or something like that.

I am afraid you cannot get it there. Or you can, but you cannot base a computation on it. The term Volume Weighted Price I used only to show the relation to Volume Weighted Average Price. The VWP is the Volume Distribution Function, as Jerry calls it. Somebody calls it Volume At Price chart or Volume Profile. I believe Sierra has such a chart but I doubt you can somehow "read" the length of the line representing the volume at each price. That's why you probably cannot base a computation on it. I am afraid you will have to code it. But again, I don't know Sierra at all.

The way I read this is that if you know the skew of a variable X (variable meant as a function), you can somehow calculate the skew of a varaible Y (again meant as a function). But I don't understand why. Reading Wiki I was also a bit confused, then I realized that in statistics they often use whole functions as variables. I noticed that if a variable is a function it is usually marked with a capital letter, such as X or Y. If a variable is a number (a value of the function at some point) it is usually marked with a small letter, such as x or y.Thanks for the link, but my indicator for AmiBroker works fast enough to be used in real time on 15sec database for 1 day. I am a newbie and I need to learn a lot so my priorities lie elsewhere. By the way, that condition in the code "if ( frac( i / CalcInt == 0) ... ) sets an interval of calculation (frac is fractional part). When I recalculate VWAP and everything only once per four 15sec intervals, the speed of the indicator almost doubles.

The problem is that in fact you don't want to calculate SD of the VWAP itself. You want to calculate SD of VWP (Volume Wiighted Price, i.e. a price distribution where probability of each price is defined by volume traded at that price). VWAP (Volume Wieghted Average Price) is the mean of such a distribution. I don't use Sierra so I am unable to help you. But search Wikipedia for Standard Deviation, Variance and Mean.

I am not sure how familiar you are with AmiBroker Formula Language, but anyway, this is the iterative part of my code. Some parts within the iteration are ommited. i cycle goes through bars, j cycles through price levels. This iteration computes Volume per price (VUcount), PVP, VWAP, Variance and the 3rd central moment (CentMom3). BoxesInRange is the number of price levels in the Volume Distribution function. for(i = iStart; i < BarCount; i++) { SumPjVj = 0; TotalVolume = TotalVolume + Volume; if((BoxesInRange < BarCount)) for(j = 0; j < BoxesInRange; j++) { BoxPrice = Bot + j * TickSize; if((Low <= (BoxPrice + TickSize/2)) AND (High >= (BoxPrice - TickSize/2))) { VUcount[j] = VUcount[j] + VolUnit; MaxVUcount = Max(MaxVUcount, VUcount[j]); } SumPjVj = SumPjVj + (BoxPrice * VUcount[j]); } if((frac(i / CalcInt) == 0) OR (i == BarCount - 1)) { VWAP = SumPjVj / TotalVolume; for(j = 0; j < BoxesInRange; j++) { BoxPrice = Bot + j * TickSize; Prob = VUcount[j] / TotalVolume; if(MaxVUcount == VUcount[j]) PVP = BoxPrice; Variance = Variance + (Prob * (BoxPrice - VWAP) * (BoxPrice - VWAP)); CentMom3 = CentMom3 + (Prob * ((BoxPrice - VWAP) * (BoxPrice - VWAP) * (BoxPrice - VWAP))); } } } }

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.

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.

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.

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.

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.

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