phall

most exchanges require all "off floor" trades be reported in a timely manner. the trouble is that this can be be out of phase with the current action. so if a large block trade is negotiated "upstairs" it will only affect the marked when it gets reported. this is part of the trouble with watching big trades only; they are not necessarily in response to other large block trades. also, the big trade has to respect all orders between the reported price and current so it will have the effect of firing off orders in the order book between the reported price and current. the large trading desks spend alot of time making sure it's not too expensive for them for a detailed description, i would recommend Larry Harris's book: "Trading and Exchanges"

amen, brother just to remind everyone using the VS_MACD4, the MACD method compares two trendlines to look for a divergence in the separation to indicate strengthening or weakening. to look at just the "absolute" trend behavior, you can modify the last calculation in the code from value1=xaverage(MACD(avg,length1,length2),MACD_Length); to value1=xaverage(avg, MACD_Length); the MACD_length input will now be an EMA length (rename it an remove the other two inputs if you want it clean) and will now plot an EMA of the net change bar to bar. this will tell you the past direction of the big traders and can be used to look for divergences off this central tendency

i had this problem too. if you upgraded from the last version you will have problems. i found that if you remove all prior versions of TS from your machine and then download 8.5 it works really well. not sure why. make sure you save workspaces from all versions because TS loves to mix up MyWork folders between versions, if one is not attentive. phall

does tradesignal provide the ask/bids synchronized with the ticks? if they are not, as in tradestation, this will run wild... they only provide a "snapshot" quote field, which is why the blowfish4 doesn't work properly in TS interested in which datafeeds do support synchronized bids/asks if anyone can provide guidance phall

sorry, saw that you already responded to my last question. would love to confirm that you were using the 6,10,3,99,9999 settings the results are interesting; it makes sense to me that version 3 stinks the lack of large difference in versions 2 and 4 is interesting. Remembering that V2 only compares the big trader closes, it suggests that you can treat them as a separate group. seems odd, but maybe if they are trading actively enough it works. i think what would be interesting is to compare the v2 to v4 in low volume situations, to see the behaviour in the case that RT mentioned earlier about price being pushed around during long times between large trades. phall

thank you what were the settings? i am assuming the are in order top to bottom? 2 the highest, 4 the bottom? p

ok, that case the existing doesn't handle (by design); but let's go with the assumption that the 800 in your example is a buy.... i put the pseudocode into the latest and greatest, version 4: VS_MACD4 so in summary: VS_MACD2: only counts blocks on big trade close changes VS_MACD3: counts blocks on all close changes VS_MACD4: remembers last tick change and adds/subtracts subsequent blocks (RT can you skim that i coded it right; it's been a long day...also thank you for your ideas and involvement) Anybody want to test? phall VS_MACD4.ELD

the attached has the VS_MACD with the closes considered every tick, as RT suggests. i have moved the "LastClose=Close;" statement outside the block comparison loop so it will compare the close of every tick. name: VS_MACD3 please give it a try! phall VS_MACD3.ELD

RT: interesting point on the close update every tick; the funny thing is that there are so many variants of the compare algorithm that everyone can make something different.... that's where the real action is in my opinion. i also use a methodology that is much more complex than the simple posted in this thread; my intention is (and has been, see prior posts) to help folks get started using the basic concepts and let them build from there.... phall

yes; but how do you know the direction of the subsequent trades at the same price? are they biased up (buys), biased down(sells)? this is the age old problem with these methods; even when using bid/ask you don't truly know whether to bookkeep the trades as buys or sells.... after we realized that the bid/ask was asynchronous, i went back to closes and made the assumption that what we needed was something that looked like Pressure up/Pressure down. i concluded that the most probable(but certainly not guaranteed) of all the options in bookkeeping a trade as a buy or sell was to assume that if the price moves up on a big trade, that's a buy (and vice versa). I ignored the rest as it's hard to assume that they are anything more than randomly distributed buys and sells.... this basic "engine" generates a OHLC information for the period of this "close pressure". the idea is/was to apply this delta "pressure" to whatever technique the user thinks is appropriate. As i'm sure you appreciate, beauty is in the eye of the beholder; everyone will like to modify it to what they think it describes... this was just my take. phall

RT: yes you are reading correctly; the same blocks are ignored in this original version because we were interested in the delta's like Blowfish4. if you want the absolute totals, absolutely it must written as you say. BTW, this is why the "Simple MACD" works best on share bars, as it forces the delta onto a fixed block of shares every bar for averaging in the MACD. on time charts with highly variant volume, things don't work as well... phall

Hi AK: Thanks for the feedback; it's nice to hear other points of view... Please don't take this negatively; but if you could elaborate a little on what you specifically think we're missing in the VS approach that would be alot more helpful than generalized observations. phall

Tasuki thank you for the testing, your points about tick/vol charts, and for the kind words about the indicator approach. couple comments: 1) The difference in Versions 1 and 2 look minor on the oscillator, but I can tell by the slope that the second VS_MACD that this is counting more accurately. definitely use this instead of version 1. it will be more important as you move up in time fractal 2) the upthrust behaviour is the big traders running stops. they generate a temporary volume spike and get folks to panic. you can watch this using the relative volume of the larger traders. it may or may not cause a divergence to form in the MACD ; depending on the setting of the MACD averaging lengths relative to the timing of the behaviors 3) the divergences you are seeing are the ones that are within the MACD timeframes; that is why some of the turn divergences appear so clearly. This is the big issue with all averaging approaches; since the MACD is just the difference of two average lines the same care must be taken. to Pimind's point; there are a million ways to display the basic information generated by the "block engine"; let's think up something novel phall

hi wlbw: No. this, like the VS_MACD just compares the closes relative to each other at each tick for the block range of interest. Order information is not included. What you are describing would need to be based on Level 2 information, and involves following the order book

Tasuki: if you watch the volume, you should be able to decipher/explain the difference in VS_MACD performance between the 1min and ticks charts you saw in the charts from this post. if you could shed some light on the performance of tick charts vs. time charts for the indicator that would be awesome phall

Hi all Thanks for all the discussion on this; definitely the trade volume for the group of interest is critical. i have found that volume is critical for using the splitter and that both Taskui's and kh_model's thoughts are correct, because the average of the longer term relative volumes are pretty consistent but there are short term deviations from this that are very interesting. Attached is a volume histogram indicator that counts the total volume in the contract range of interest. I like to put it under the normal (total) volume indicator and by comparing the two you can see quickly the relative volume of the "split" blocks. there is also an average line plotted over it. Name: VS_Volume Note: make sure the volume is set as you want: trade volume vs. ticks will give different answers as far as the VS_MACD v1 vs. v2; the v1 definitely has a bug (though minor); i would be VERY surprised if it gave better results, but let's definitely check it out. I am also wondering whether anyone has played around with a better oscillator method than MACD and what they may have found. Please post if you've tried anything! Haven't had much time to work on this, so interested... phall VS_VOLUME.ELD

hi all found a minor bug today in VS_MACD. attached is the fixed ELD. Name: VS_MACD2 not major, but it should improve the performance; the resetting of the block sizes was slightly off posting some test results would be greatly appreciated phall VS_MACD2.ELD

Tasuki, that looks like it to me. it looks like the basic "close compare" engine is doing its job. The difference in behaviour is probably due to refinements in post processing, including potentially a more sensitive "close compare" methodology, sensitivity to changes in volume traded, and the computation of the end line. i don't want to start speculating too much, but i think comparing trendlines like MACD is on the right track and building a composite of trendlines, with corrections scaled to volume, will speed it up/slow it down at the correct times phall

With respect to the splitter divergences: i agree wholeheartedly that the user must understand the context of what the large trader group is trying to do; this can't be accomplished without using other indicators and techniques to sort out the behaviours. Just relying on this one is not a strategy; you will get killed. i think it's Jon Carter who always emphasizes that if you don't understand what the other players are doing in detail; you will be a-hole in the room. This is one adds one piece of the puzzle i guess, but the puzzle has many pieces. Reiterating what Blowfish said many posts ago, i would encourage everyone to take the basic "engine" and build it into their favorite indicator types. The MACD version is one VERY simple implementation, comparing the relative strength of two trend lines of differing periods; but there are many others of course and can be modified by averaging, momentum techniques, ROC etc... in short, anything that operates on the OHLC of the price, could be implemented on the OHLC of the splitter phall

Tasuki at the top of the code there is a line that says: [LegacyColorValue=true] (or something similar.) just delete this line and reverify. Phall

attached is a MACD .ELD for the close based volume splitter name: VS_MACD this is not intended to be "the solution"; but to investigate whether the methodology is on the right track and could eventually be fine tuned. if someone could test out today would be great VS_MACD.ELD

exactly! they are unsynchronized, but synchronized "enough" when the market is calm this is ome reason why it gets worse when the market moves because the Bid/Ask pushes in one direction relative to the closes and tricks the indicator. the second is that the link and code might have trouble keeping up. during quiet times, it does ok. in one of Tasuki's posts, it shows the bottoms overshooting the price, this is most likely due to this "increased activity effect." the only way to solve it properly is to received synchronized data. comparing the closes to each other works relatively well; but one needs to make assumptions/avg through the up/down pressure (ie order book) based on relative closes and closes that don't move. That's where i magic will be, in my humble opinion phall

Tasuki, thank you for the data. on the consistency front, my trading partner 2 states away and I ran the "271" (as you named it) today on the 3min @ES and got identical results. This was not the case with the bid/ask version. What i noticed with the Blowfish 4 running next to the 271 is that when the market moves fast it gets tricked, probably because the Bid Ask is moving so rapidly with respect to the closes. my first day with the 271 showed that the 100+ group and the price tracked very well. tradeable, transient divergences appeared quite often intra-candle. as i mentioned before, to turn this into something predictive, the close to close analysis could be made more sophisticated and a MACD or similar type of oscillator (operating on the OHLC of the vol split) could show the leading divergences, similar to the EOT. as Blowfish and RT mentioned, this is the backend that everyone should probably develop to their own needs... phall

was thinking about the multi-threading, time sync problem one way around this would be to compare the close relative to the last close and forget about the bid/ask. the add/subtract would be based on the close changes on that block of shares it would basically be an OBV calculation and will be synced since EOT doesn't suffer from sync issues, they might have something similar; maybe a more sophisticated methodology than OBV to measure the price force of the block of interest using closes. just some thoughts.... phall added ELD Code with changes to use closes instead of bid/ask Indicator name: vol_split_OHLC_C BLOWFISHUSINGCLOSES.ELD

does anyone know the TRUE accuracy of the reserved words: AskTimeEX BidTimeEX in tradestation?