Attached you will find a small table I have built regarding pace settings. As usual I will go through my thought processes. In PV, once I jump on the right side of the market, I am then specifically looking for volume to carry the current B/A pair away from my entry pair. It is my strong belief that alot of people get screwed right off the bat because they do not give any consideration to volume whatsoever. Just as with STR.SQU, some of you may be seeing volume as a leading indicator for the first time. The PRV tool a few pages back is showing you the projected 5M volume that we are expecting by the end of the 5M bar. For me, this pace setting is fairly critical for a number of reasons. I regard it as a profit projection. ! So how is it that so many can get screwed? If you take a look at the attached chart, you will see a table of data generated from 5M volume bars that occur between 9:45 AM EST and 3:45 PM EST. I plot each bars VOLATILITY (H-L) against it's VOLUME. The reason this works is because of the correlation between Price and Volume. As a result of this correlated relations, we can run projections of Volume that can be mapped to an expected Volatility. It is not necessary to get into specifics here, it is just enough to know that because of PV and specifically the correlation between P and V, we can PRV and sneak a peak into the segments anticipated volatility and the amount of skill that is required to realize the bar's potential. After plotting each bar's volatility against it's volume, I arrived at the following table which I believe pretty much sums up why alot of people can get screwed when they get into a trade. As usual, not knowing where you are or what's happening can be very problematic for us as traders. The following chart is divided into VOLUME DECILE vs VOLATILITY. When you look at the bottom VOLUME DECILE (bottom 10% of volume bars), you find 161 bars who's volume ranged between 369 contracts and 2401 contracts. LOLLLLLLLL. That 2401 number look familiar, it is nearly dead on with the 2500 number Grob posts for the random drift arena. Of course, we all know this to be the VDU zone. It is a killer zone to trade in because as you can see, 73 of the 161 bars are in the loss arena; in other words there are no pairs of entries and exits that will yield a profit within the 5M that the bar ensues. At the other EXTREME ( ), we find 161 bars with volume in the 18K+ zone. Most of the FOMC bars are in that zone. Every FOMC day, I read countless posts saying stay out of the market on these days. You can circle every single FOMC day and just pick them apples with little to no risk. An IF1 and IF2 easily get the job done on these type of bars. You see that the volatility distribution of these bars ranges from about 1 to 6 pts. The total sum of just these bars alone are roughly 300pts. The data is from the last month or so of trading... I designate the extreme zone as easy money since directionality does not fluctuate as much. I understand that Grob used indicators as a starting point to get oriented with most ETer's. I view this PV chart as an additional way to get folks to understand the relation between Price and Volume. The attachment is a sort of pure PV layout. As you move down the PACE spectrum from EXTREME to VDU, the amount of skill required increases. So at the top, it takes very little skill to pull out what is available. As you move down the PACE spectrum, it takes more and more skill and sharper pictures to be able to handle the reduction in volume and conversely, the increase in risk (ie. frequent adjustments to keep on the right side of the market). Eventually, you wind up in the VDU zone where it is nearly 50/50 that you are in a losing opportunity from the get go... As far as a big picture, you can view the attachment kind of like an apple tree. The EXTREME apples are the easiest to collect. Working your way up the tree so to speak requires additional tools (ie. a ladder, balance, etc...). By just picking the EXTREME apples, you stay in great shape bounty wise. All the other levels are just icing on the cake... Kind Regards, MAK
Irl... Your logging appears to do a couple of things which I deam to be reversed. First it identifies the state (ie. STR/NEUT/SQU) THEN it looks for critical values. On the log you posted in question, there was a SQU which was a -11 (ie. an extreme value even amonst your set of extreme values). This value appears to reset the neutral offset value. However, I could not evaluate whether there was a true center simply because stickiness is not evident in your log. Logging stickiness is even more difficult if you are trying to do it programmatically. It took me quite some time to figure out how to fix your log. The only improvements I could recommend was to monitor both critical values (ie. MIN and MAX) of all zones (ie. STR/NEUT/SQU). Your program only logs the extreme min values in the SQU and extreme max values in the STR. If you are trying to get your code to recognize the recentering, you will also need to recognize the extremes in the NEUT. It is not clear what your extreme mins and maxes of your NEUTral are informing you of. The zone is clipped to +/- 2 so extremes in this zone are not meaningful from what I understand. Some pages back, I dumped out pseudo-code to trigger an automated recentering. They require that your program recognize a FAILURE TO SQUEESE and a FAILURE TO STRETCH. Somewhere a few pages back, I mentioned the states that would be required for a program to be able to self center. It required 2 things, the recognition of a combo where there was a begining to a LONG TRANSLATION (ie specifically a LONG SPIKE) that was not preceded by a STRETCH (ie. a combo that I call a FAILURE TO STRETCH) and the opposite scenario where there is the beginning of a SHORT TRANSLATION (ie. specifically a SHORT SPIKE) that was not preceded by a SQUEESE (ie. a combo that I call a FAILURE TO SQUEESE). These two failure combos are problematic for me because they are contrary to what I know is true (ie. YM leading). Because of the enduring belief that YM leads, finding FTS is notification that tool has fallen out of calibration and thus I retune it to be in line with YM leading. Picking off these two states is what will trigger your automatic recentering. I took a look at the code behind the sheet and did not see any of the above logic embedded in your conditionals. I stress the pairing of the DOM chart because my own debriefing many months back recognized that the duo confirm the movements of one another. Of course, there is a simpler way to just auto pull the trigger but not understanding STR.SQU is going to poise some problems as how to take the next step... In a nutshell, my recommendation is to conditionally (if statements) capture the {SQU/NEUT/NO STR}=>{LONG SPIKE} and the {STR/NEUT/NO SQU}=>{SHORT SPIKE} state. These two conditions trigger your recenter. Determining the new recentered value should then be straightforward. In your log, you have NEUT/SQU cycling while your DOM CHART plots a LONG TRANSLATIONS. All translations begin with a spike. Before a spike you have your 2 pairs. Your 2 pairs directly coincide with NEUT. A fallacy of this chain is the trigger to auto-recenter. Regards, MAK
LOL... I didn't even know this attachment existed... RRRRRRRR.... Grob, once again, I find myself many moons behind you on the same path... Kind of curious why no one has referenced this attachment which had been posted long before I arrived in ET. Swap the STR and SQU since we are in LONG MARKET OFFSET. IRL. Look very closely at this picture. Notice how precisely this picture lines up with my previous post. http://www.elitetrader.com/vb/attachment.php?s=&postid=488978 Regards, MAK
the mother reference site for this and a lot of collateral and corroborative stuff is: stochastics.com.
This is a very reliable sketch of what is at hand. As we get organized better in Tucson, we will have some of our VI Team on this to get stull attached pronto.
Thanks MAK for another promising looking tool. I trade the YM and know both of your tools will be very valuable once my homework is done....A+++ on the presentation also!!! You guys are awesome.
Easy I just tested this and seems to work. Similar to changes we made for Mak's str/squ xls on page 356. Changes are as follows 1. On worksheet 1 (PRV) change cell B19 to this =yourIBidhere|tik!id501?req?ES_FUT_200606_GLOBEX_USD 2. Change B18 to this =yourIBidhere|tik!id501?volume 3. Change B17 to this =NOW() this is because I am unaware of a time value being sent by an IB feed - I will continue to believe this until corrected by someone in the know. In essence you are using excel's own time stamp so make sure PC time is in good shape. http://www.worldtimeserver.com/atomic-clock/ 4. On worksheet 2 (DATA) change cell G1 to this =PRV!B18 or =yourIBidhere|tik!id501?volume one is a direct reference to the DDE one is a second hand one that refers to the feed on the other worksheet. attaching graphic to show same - IB had one extra cell over IQLink as it requires a hook somewhere in the xls from which to refer. Mak please advise if any obvious mistake is apparent - if not tomorrow should be very interesting for us all. IRL
YM... My observations are a bit different than the stats but then again, these are on the 5M and not the 2M from which we gather our data... Hopefully, you all are getting the jist of how these tools can be used and calibrated for any instrument... They take roughly 3 minutes to put together. You can also do a quick and dirty yellow brick road across the paces to get a sense of whats on the table. To be conservative, you can use O-L instead of H-L volatility. I know most people won't bother for now, but I am hoping some of this will sink in later down the line, however long that may be, as with most of Grob's knowledge base... I've got a slight mod on the PRV sheet. It is likely to be the only mod that I am going to entertain. Some were interested in seeing the current bar's accumulating volume against the PRV. For me, it is unnecessary simply because I know the two (PRV and the accumulating volume absolutely converge by the bar's end). Additionally, tommorrow some of you will comment as to the slight discrepency between your charting programs volume and the PRV sheet's recording volume. I am stating this heads up because it is slight and negligible. I say it is negligible because in almost all cases, the discrepency does not change the pace that is associated. In any event, the PRV sheet change is very straightforward and so I will watch it tomm to ensure that there is nothing quirky code-wise.... Regards, MAK