Volume Splitter

[phall 10]

here is the ELD using Blowfish Code

there are two indicators in the file; one plots bars, the second, candles. (it doesn't have the startup improvements, but these only matter if you're interested in absolutes)

 

Vol_Split_OHLC

Vol_Split_Candles

 

just import into TS and look for the above names

I personally like to plot the candles under the price candles and watch for divergences....

 

 

For those that want a trendline on it, calculate the average price of the candle (DeltaH+DeltaL+DeltaCu)/3, average it and add a 5th plot

 

For MACD (which is what i think the EOT indicator is), calculate 2 trendlines, take the difference between them, and average a little. (standard MACD)

 

 

phall

VOLSPLITBLOWFISH.ELD

[Tasuki 10]

But guys/gals,

If this "intrabarpersist" business is bogus, doesn't that mean that the Blowfish indicator is unreliable? It's got that reserved word 9 times in its code.

I've been noticing some strange differences in my charts when I put the Blowfish #4 indicator on different timeframes, and wondered what was going on. If this caveat that thrunner and the folks on the TS forum are talking about is true, then we may be barking up the wrong tree.

Tasuki

[BlowFish 10]

Tasuki. I have noticed odd discrepancies on different time frame charts. Might be a bug might be implementation. Did they distribute .DLL's when you signed up for the trial? Chances are that suffers the same too.

 

Personally I don't think its that big a deal because a trade@bid or ask dosen't definitively tell you a thing about the participants whether they are opening or closing, whether they are buyers or sellers whether they are informed or not. One of the dis-services done by the vendors is they imply that they are.

 

Still I have noticed discrepancies that may be due to how data is sent. I might have a go in Ninjatrader but probably not for a while.

[RichardTodd 10]

If this "intrabarpersist" business is bogus, doesn't that mean that the Blowfish indicator is unreliable? It's got that reserved word 9 times in its code.

 

I can assure you that the 'intrabarpersist' keyword works just as advertised. It's the combination of that with grabbing the order book info that can lead to what are called 'race conditions' in concurrent programming circles. It's been discussed at length in ninjatrader forums as well, and something I got a lot of practice dealing with when I used to have a day job. So, thankfully, our indicator never had those issues.

 

Certainly worth looking into if you want to improve your clone attempts.

[BlowFish 10]

I can assure you that the 'intrabarpersist' keyword works just as advertised. It's the combination of that with grabbing the order book info that can lead to what are called 'race conditions' in concurrent programming circles. It's been discussed at length in ninjatrader forums as well, and something I got a lot of practice dealing with when I used to have a day job. So, thankfully, our indicator never had those issues.

 

Certainly worth looking into if you want to improve your clone attempts.

 

Thanks for your input As I have said on several occasions I have no interest whatsoever in cloning your work, I'm just here to demonstrate principles that it is based upon so people can do the work for themselves.

 

IF and when NT 7.0 has proper storage of all these events I might have a serious go at some studies.

 

One advantage NT has is that it generates events with proper time stamps for trades and order book changes. TS order book best bid and best ask is something that you 'peak' at from a trade event unless I am mistaken.

 

It's good to know that intrabar persist works as advertised. I had heard that there is a pretty serious issue with the granularity of time stamping ticks? It's academic to me as a Multicharts user. I do have a 'feeling in my gut' that there might be something a bit wierd with their implementation.

 

Incidentally for serious research on this Neoticker might fit the bill. I believe it can be tricked into saving full order book information and it's tick precise technology will play this back into a chart tick by tick correctly synchronised with the trade data. If NT 7.0 doesn't deliver maybe time to dust off Neo. It's a superb product in many many ways but a bitch to learn to program. I guess I'd need to re-learn being as its been so long.

 

Anyway thanks again Richard.

[AgeKay 10]

One advantage NT has is that it generates events with proper time stamps for trades and order book changes.

 

Ninja Trader 6 returns time stamps leave out the milliseconds. It's current implementation is accurate down to seconds even though they return it as a DateTime object which supports milliseconds, so it would be possible for them to add milliseconds in a future version without breaking anything.

[BlowFish 10]

Ninja Trader 6 returns time stamps leave out the milliseconds. It's current implementation is accurate down to seconds even though they return it as a DateTime object which supports milliseconds, so it would be possible for them to add milliseconds in a future version without breaking anything.

 

Yes, and you can grab the time with more orders of accuracy than current technology provides in your event handler (using "DateTime.Now.Ticks")

[Tasuki 10]

Just this morning I looked at Blowfish #4 on two one minute charts of the ES on two different workspaces--the indicator patterns looked very different. So, if "intrabarpersist" works as advertised, then it must be advertised to give random results!

 

For completeness sake, those two charts have been on my workspaces several days, so they started up at exactly the same time this morning, when I turned on my computer and logged into Tradestation. So the differences between them were not due to different start times. I understand how that could be a potential problem, but was not the case here.

[AgeKay 10]

Yes, and you can grab the time with more orders of accuracy than current technology provides in your event handler (using "DateTime.Now.Ticks")

 

Right, but this would not work for historical data. Btw, you would not access access the Ticks property to get milliseconds, use DateTime.Now.Millisecond instead. DateTime.Now is of type DateTime which contains all information.

[RichardTodd 10]

Thanks for your input As I have said on several occasions I have no interest whatsoever in cloning your work, I'm just here to demonstrate principles that it is based upon so people can do the work for themselves.

 

I knew you'd say that! Don't worry, I wouldn't lump you in with the cloners. FWIW I think you are right to say that, after a point, it's all window dressing. A skilled trader can smooth/normalize/recombine/predict/colorize the data any way that suits the trading concept they are trying to bring out. Attempting to match our one implementation bar-for-bar doesn't seem like a good use of time, to me.

 

(although obviously I think our implementation is a rather nice one)

 

 

It's good to know that intrabar persist works as advertised. I had heard that there is a pretty serious issue with the granularity of time stamping ticks?

 

Yeah, all of the TS timestamping stuff is ridiculous--even forgiving the ticks, last time I used TS you couldn't even tell when a bar was. Long live multicharts and the _s functions, which are at least a little better.

 

 

Incidentally for serious research on this Neoticker might fit the bill.

 

I tried to find example code for neoticker once or twice, to get a sense of what it looked like, but never came across much via google. Didn't run across an easy-to-spot programming guide on their website. I thought that was strange. So I have yet to try it.

[Tams 20]

Here's a thought:

 

 

TradeStation and MultiCharts are Event-Driven programs. (so as many others on the market)

 

Basically an event-driven program does not do anything...

it just sitting there, not doing any calculations or re-calculations,

not doing any updates...

 

... UNTIL a tick comes in. *

 

when a tick comes in (i.e. a trade), the program will kick into action.

It will update all the indicators,

it will re-draw the trendlines,

it will re-plot the price bars, etc...

 

 

Bid and Ask are real time events, but they are disconnected with Trade (i.e. tick).

 

in another word, many changes in bid and ask can happened within a period of time,

however if a trade has not happened,

the changes in bid and ask will not be visible to the indicator.

 

 

 

 

*(or when a barinterval has passed)

[AgeKay 10]

So, if "intrabarpersist" works as advertised, then it must be advertised to give random results!

 

As Richard explained, this bug is due to multi-threading. You need to take care of that yourself by synchronizing the access to the data.

[RichardTodd 10]

Just this morning I looked at Blowfish #4 on two one minute charts of the ES on two different workspaces--the indicator patterns looked very different. So, if "intrabarpersist" works as advertised, then it must be advertised to give random results!

 

Again, I would suggest you not blame intrabarpersist. It persists the values from tick to tick, just like it's supposed to. I have tons of code that would not work at all if it weren't for intrabarpersist working properly.

 

But, when you are combining independent streams of data (ticks vs. order book), it takes care to avoid race conditions. It's like a gun that you can easily point at your foot. Don't blame the gun if you're the one pulling the trigger, you know?

 

I remember the first prototype ninja splitter I made had this issue... it would look ok, then all of a sudden start going in the exact wrong direction. The sad thing was that the errant code was in one of ninja's built-in indicators, so I had to re-write that part from scratch. It's an easy trap to fall into if you aren't used to concurrency issues.

[phall 10]

does anyone know the TRUE accuracy of the reserved words:

AskTimeEX

BidTimeEX

in tradestation?

[Tasuki 10]

Again, I would suggest you not blame intrabarpersist.

 

Richard, thanks for your explanations. Whether it's the "intrabarpersist" or something else, the bottom line for the trader is that the indicator gives different results on different charts which are set to the same parameters. As a trader, this is untenable because it is unreliable. If I'm basing my trading, even in part, on signals that are unreliable, what's going to happen to my bottom line?

 

The question is, what could one do to remedy this problem? As an EasyLanguage newbie, I wouldn't have a clue, and from what little I can gather from the discussion of Tradestation data vs. Ninjatrader vs. Neoticker, the problem is unfixable on Tradestation. Of course, I could be wrong.

[RichardTodd 10]

If I'm basing my trading, even in part, on signals that are unreliable, what's going to happen to my bottom line?

 

I didn't suggest you should use an indicator with race condition issues... I just said it's not right to blame the intrabarpersist reserved word.

 

 

The question is, what could one do to remedy this problem?

 

With work you can make TS produce deterministic output. In fact, I hear there's a commercial splitter out there that is consistent on tradestation (can't remember the vendor's name, though).

 

What I have learned from porting indicators across TS, MC, Ninja, eSignal, ensign, etc is that they all have quirks and issues that need to be worked around. Probably the most common question we get in the room is "why does my TS screen look slightly different than your ninja screen?" Of course the biggest reason is inconsistencies across the data feeds. But the secondary answer is that the computations have to be adjusted slightly, per platform, to account for their oddities. I would say the #1 programmatic cause of platform differences in our indicator output has to do with event timing, which the platforms seem to differ about quite a bit.

[Tasuki 10]

 

 

With work you can make TS produce deterministic output.

 

But the secondary answer is that the computations have to be adjusted slightly, per platform, to account for their oddities. I would say the #1 programmatic cause of platform differences in our indicator output has to do with event timing, which the platforms seem to differ about quite a bit.

 

Richard, thanks for the insights. I don't suppose your previous "day job" would have included programming for Tradestation? You obviously understand its idiosyncracies intimately.

 

Tasuki

[RichardTodd 10]

I don't suppose your previous "day job" would have included programming for Tradestation?

 

No, I used to design huge distributed software systems for government contractors. My last gig was to help bring a failing project (way over time and over budget) back to life. It sucked, but it paid so well that I was able to leave that behind forever.

 

I've been programming computers in one form or another since I was 6, so it's kinda in my blood now I guess.

[cooper59 10]

here is the ELD using Blowfish Code

there are two indicators in the file; one plots bars, the second, candles. (it doesn't have the startup improvements, but these only matter if you're interested in absolutes)

 

Vol_Split_OHLC

Vol_Split_Candles

 

just import into TS and look for the above names

I personally like to plot the candles under the price candles and watch for divergences....

 

 

For those that want a trendline on it, calculate the average price of the candle (DeltaH+DeltaL+DeltaCu)/3, average it and add a 5th plot

 

For MACD (which is what i think the EOT indicator is), calculate 2 trendlines, take the difference between them, and average a little. (standard MACD)

 

 

phall

 

Thank you very much for the ELD for the Blowfish #4. It is much appreciated. If I want the candles (or the bars) to measure orders from 1 contract to 50, wouldn't I simply put in a 1 at the small block filter and a 50 at the large block filter? On the same chart if I wanted to compare those trades to trades above 200 contracts, would it be small block filter at 200 and and large block filter at 9999? In fact, my minute chart looks more like a ladder going up and down.

Can this indicator be used on a tick chart as well as a minutes chart? My tick chart does not function the same, thats why I ask? Would this have anything to do with reseting the Delta at each bar to over zero?

 

Thank you for any help:)

[Tasuki 10]

Thank you very much for the ELD for the Blowfish #4. It is much appreciated. If I want the candles (or the bars) to measure orders from 1 contract to 50, wouldn't I simply put in a 1 at the small block filter and a 50 at the large block filter? On the same chart if I wanted to compare those trades to trades above 200 contracts, would it be small block filter at 200 and and large block filter at 9999? In fact, my minute chart looks more like a ladder going up and down.

Can this indicator be used on a tick chart as well as a minutes chart? My tick chart does not function the same, thats why I ask? Would this have anything to do with reseting the Delta at each bar to over zero?

 

 

Looks like you've got it right regarding the contract sizes. The indicator will plot on a tick chart and a volume chart as well, but not on a momentum or range bar chart. Not sure why. See for yourself. I should clarify that it will plot, meaning you'll see something, but it never seems to advance properly on mom and range charts.

 

The real question is whether it is giving correct or incorrect information. If you put this indicator on multiple types of charts, you'll get widely divergent information. One chart will suggest that the big traders are buying, while another chart will show that they're selling. So, basically it's untrustworthy as it is, and possibly will do more harm than good to your trading.

 

Caveat emptor.

[phall 10]

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

Edited June 11, 2009 by phall
add code

[RichardTodd 10]

The indicator will plot on a tick chart and a volume chart as well, but not on a momentum or range bar chart.

 

Just as a point of interest, when TS came out with their latest bar types, a few of our indicators didn't work on them. We were able to fix it, though, and I have reports of people using our splitter successfully on momentum bars at least. I don't have TS anymore so I haven't seen it myself, but our clients are pretty **** about comparing their screens to our moderator's so I think they are happy with the new TS bar types now.

[Tasuki 10]

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

 

FWIW, here's a comparison of phall's ELD (which I've renamed "271" because his post is permalink #271 in this thread) and the Blowfish #4 (from permalink #162 of this thread).

 

The first two charts are 1 minute charts which include volume.

The second pair of charts are 233 tick.

All four are of the @ES.

In each case, the upper indicator is set to large contracts (100-9999) and the lower indicator is set to small contracts (1-5).

 

Clear, but not dramatic, differences can be seen, but I'm not sure what this tells us. What I should have done was to create multiple instances of phall's new indicator on identical charts and see if they all track the same or not. That would be a valuable test for consistency.

[phall 10]

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

[BlowFish 10]

I think the issue is with InsideAsk and InsideBid. Essentially you are 'peaking' at those values (which fluctuate) at a moment in time. They are not synchronised with last in any way shape or form.

 

You could mitigate any issues by storing those values as the first thing the study does. They will never be truly eliminated by using the InsideAsk InsideBid mechanism.

 

You might be able to eliminate the issue completely by having last bid and ask as data1 data2 and data3 in the same chart.