Volume Splitter

[zdo 20]

Thanks, Blowfish. Could you provide us references for the relavent articles?

[AgeKay 10]

  BlowFish said:

Yes really You are assuming that the bid ask spread is always 1 tick. It it is not. YM is 10313 bid 10317 asked right now for example. If I bid 10315 and you offer 10315 right this second it will get matched between the best bid/ask. Actually mine could be a market order and I think (not sure depends on the matching algorithm) it will not display on the book. This is a surprisingly common occurrence at the open, round news etc.

 

The size of the bid/ask spread does not matter. You just confirmed what I said. If you bid 10315, then that will be the best bid at that point in time. I can't enter an order at the exact "same" time, it will either be a microsecond before you or after you. So if I offer the same price just a microsecond after you then that will obviously appear as a trade on the bid since my order will be matched with your order on the bid which was the best bid at that time. If I had entered my order a microsecond before you then the trade would have been reported on the ask since I offered first at that price. Your limit order acts like a market order in that case since it hits the market price.

So to repeat it again: A trade always happens at the best bid or ask at that point in time (even if it happens so quickly that you can't see it) whether using limit or market orders. Go call up your exchange, they will tell you the same.

 

  BlowFish said:

Zenfire does indeed time stamp micro seconds however that is several orders of magnitude greater accuracy than stuff can actually happen in the real world.

 

Regarding time stamps, the most accurate I have seen is TT's API which gives you 100 nanoseconds, it's still not accurate enough and they don't even come from the exchange. Trades will still appear to have occurred at the same time. Even Eurex sells tick data stamped only down to seconds.

 

  BlowFish said:

It is also quantitatively demonstrateable that ticks occur between bid and ask and there are many papers that show and discuss just that.

 

What papers are you talking about? See above how that is impossible.

 

  BlowFish said:

In fact one of the more recent concludes that this is the primary reason for inaccuracies in delta/order flow type indicators

 

These indicators are extremely inaccurate even if you have the best data feed in the world based on the fact that its logic is flawed. First see example above how the same trade by two traders can give you opposite results and I give you another example: 200 bid by a smaller trader, 800 offered by a larger trader. Smaller trader buys 600 at the offer, then the larger trader enters a limit order for 1000 to sell on the bid, thereby taking out the bid, so 800 remain on the offer. Another 200 are bid below that by the smaller trader. Now assume the same thing happens again. So now according to the delta indicator 1200 were bought and only 400 sold even though the smaller trader bought 1200 and is willing to buy only another 200 while the larger trader trader sold 1200 and is willing to sell another 800. If you really want to know what's going on then you should watch the order book.

 

  paolfili said:

Only EUREX (for block trades out of the book)?

 

I don't know whether it's only Eurex. All I know that it's definitely possible on Eurex.

[BlowFish 10]

It is not just how you time stamp that matters it's how quick stuff takes to get done. It is like measuring the distance from the earth to the sun in millimetres. It makes no sense to. For example the average disc seek time is 6 milli seconds (3 orders of magnitude slower). Probably a bit quicker now as magnetic density increases. Anyone expecting micro second accuracy in these sorts of systems is living in cloud cukoo land. I guess it's not surprising people get confused when some 'luminaries' post that they are achieving that.

 

AK you are now assuming that matching algorithms are strictly FIFO (first in first out). That is not the case. There are fundamentally two types of order, those that provide liquidity (limits). They are 'options' to trade. There are those that take liquidity (market, stop etc.) they are from traders that require immediacy. Within those categories you might get FIFO at any particular price level though not on every exchange it depends on there matching algorithm. Time price and size can all contribute to matching precedence. Size not so commonly on most exchanges.

 

We have not yet discussed stop orders, there can be a whole bunch of market orders sitting (as stops) ready to be matched at different levels. I don't have to hit the button at the exact split second my order could have been sitting there for a month waiting to be elected.

 

A search for 'Lee & Ready algorithm' will throw up all sorts of interesting papers. They will lead one in further directions if interested. However if it is your view that any trade reported that is not at best bid best ask is some sort of errata you may not find much mileage in them.

[paolfili 10]

Regarding time stamps, the most accurate I have seen is TT's API which gives you 100 nanoseconds, it's still not accurate enough and they don't even come from the exchange. Trades will still appear to have occurred at the same time. Even Eurex sells tick data stamped only down to seconds.

Why do you believe they are not accurate enough?

Surely they don't came directly from Exchanges.

The come from Exchanges on a High-Quality Internet connection and are timestamped on the Feeder servers.

On the assumption of a reasonable little variance in the delay of the packets arriving from a supposed HQ connection (that I suppose the serious data feeder would have) we can have a reasonable "good rapresentation" of the correct order of the packets containg the bid/ask + trade.From that (in a platfrom design that mantain the sync between data - Ticker Plant) a Cumulative Delta analysis can have some meaning IMO.

 

These indicators are extremely inaccurate even if you have the best data feed in the world based on the fact that its logic is flawed. First see example above how the same trade by two traders can give you opposite results and I give you another example: 200 bid by a smaller trader, 800 offered by a larger trader. Smaller trader buys 600 at the offer, then the larger trader enters a limit order for 1000 to sell on the bid, thereby taking out the bid, so 800 remain on the offer. Another 200 are bid below that by the smaller trader. Now assume the same thing happens again. So now according to the delta indicator 1200 were bought and only 400 sold even though the smaller trader bought 1200 and is willing to buy only another 200 while the larger trader trader sold 1200 and is willing to sell another 800. If you really want to know what's going on then you should watch the order book.

 

 

i)200-800 (P1-P2)

ii)200-200 (P1-P2) +600

iii)x(200)-800 (P1-1tk/P1) +400

---------------------------------------------------

iv) 200-200 (P1-1tk/P1) +1000

v) x(200)-800 (P1-2tk/P1-1tk) +800

-----------------------------------------------------

vi)200-200 (P1-2tk/P1-1tk) +1400

vii)x(200)-200 (P1-3tk/P1-2tk) +1200

-----------------------------------------------------

 

Price= - 3tick CumulativeDelta= +1200

Divergence between Price and CumulativeDelta.On this event there are different interpretation.

Will win the "big" sellers?Will win the (not so) small buyers?

Anyway we have more buyers on a discending price.This can say the CumulativeDelta

----------------------------------------------------------------------------------------

Can you add some words on your suggestion about order book reading ?

 

 

I don't know whether it's only Eurex. All I know that it's definitely possible on Eurex.

I know too it's possible on Eurex. :-(

I' m searching a market where this kind of "tricks" are not possible...

 

 

BTW.

Have you any experience on TT's API?

Are a clear instrument to work with (c++) or a ever-changing mess (as someone suggest me)?

 

Thanks

 

Paolo

 

 

  AgeKay said:

 

Regarding time stamps, the most accurate I have seen is TT's API which gives you 100 nanoseconds, it's still not accurate enough and they don't even come from the exchange. Trades will still appear to have occurred at the same time. Even Eurex sells tick data stamped only down to seconds.

Why do you believe they are not accurate enough?

Surely they don't came from Exchanges.

The come from Exchanges an High-Quality Internet connection

On the assumption of a reasonable little variance in the delay of the packets arriving from a supposed HQ connection (that I suppose the serious data feeder would have) we can have a reasonable "good rapresentation" of the correct order of the packets containg the bid/ask + trade.From that (in a platfrom design that mantain the sync between data - Ticker Plant) a Cumulative Delta analysis can have some meaning IMO.

 

 

These indicators are extremely inaccurate even if you have the best data feed in the world based on the fact that its logic is flawed. First see example above how the same trade by two traders can give you opposite results and I give you another example: 200 bid by a smaller trader, 800 offered by a larger trader. Smaller trader buys 600 at the offer, then the larger trader enters a limit order for 1000 to sell on the bid, thereby taking out the bid, so 800 remain on the offer. Another 200 are bid below that by the smaller trader. Now assume the same thing happens again. So now according to the delta indicator 1200 were bought and only 400 sold even though the smaller trader bought 1200 and is willing to buy only another 200 while the larger trader trader sold 1200 and is willing to sell another 800. If you really want to know what's going on then you should watch the order book.

 

 

i)200-800 (P1-P2)

ii)200-200 (P1-P2) +600

iii)x(200)-800 (P1-1tk/P1) +400

---------------------------------------------------

iv) 200-200 (P1-1tk/P1) +1000

v) x(200)-800 (P1-2tk/P1-1tk) +800

-----------------------------------------------------

vi)200-200 (P1-2tk/P1-1tk) +1400

vii)x(200)-200 (P1-3tk/P1-2tk) +1200

-----------------------------------------------------

 

Price= - 3tick CumulativeDelta= +1200

Divergence between Price and CumulativeDelta.On this event there are different interpretation.

Will win the "big" sellers?Will win the (not so) small buyers?

Anyway we have more buyers on a discending price.This can say the CumulativeDelta

----------------------------------------------------------------------------------------

Can you add some words on the order Book reading ?

 

I don't know whether it's only Eurex. All I know that it's definitely possible on Eurex.

I know too it's possible on Eurex. :-(

I' m searching a market where this kind of "tricks" are not possible...

 

 

[BlowFish 10]

re time stamps you can time stamp to nanoseconds but computers just can not measure to that resolution . It would be like measuring nano metres with a metre rod. They could time stamp in 1x10^-44 seconds (plank units) but if the actual accuracy of the measurement is only +- 10 milliseconds it is meaningless.

 

You have highlighted something that is very important and that is sequencing (bid ask last data tick sequence). Of course the process is completely asynchronous until it comes out of the matching algorithm but from then on in it is the sequence that is important not the absolute delta time. I am not convinced that exchanges preserve that under all circumstances. As we can't agree on what are meaningful time stamps and even if trades can occur between the previous best bid ask that probably is a discussion for another time

Edited March 5, 2010 by BlowFish

[AgeKay 10]

  BlowFish said:

It is not just how you time stamp that matters it's how quick stuff takes to get done. It is like measuring the distance from the earth to the sun in millimetres. It makes no sense to. For example the average disc seek time is 6 milli seconds (3 orders of magnitude slower). Probably a bit quicker now as magnetic density increases. Anyone expecting micro second accuracy in these sorts of systems is living in cloud cukoo land. I guess it's not surprising people get confused when some 'luminaries' post that they are achieving that.

 

You need more accurate time stamps to determine the order of events. It's annoying to have events occur at the "same time" even though you know they didn't. This might not bother most people, but I have programmed some pretty amazing stuff that would improve with more accurate time stamps. So this is not theoretical stuff, I actually need to know the sequence of events. It doesn't matter how long it takes to get processed as long as it is reasonable. Assuming humans can see 25 frames per second, you wouldn't even be able to see the difference with anything more accurate than 40 milliseconds.

 

  BlowFish said:

AK you are now assuming that matching algorithms are strictly FIFO (first in first out). That is not the case. There are fundamentally two types of order, those that provide liquidity (limits). They are 'options' to trade. There are those that take liquidity (market, stop etc.) they are from traders that require immediacy. Within those categories you might get FIFO at any particular price level though not on every exchange it depends on there matching algorithm. Time price and size can all contribute to matching precedence. Size not so commonly on most exchanges.

 

Sorry, I mainly look at the most liquid Futures contracts which almost all use FIFO. The only one of those that I know that doesn't strictly use FIFO is the 2 year Treasury Note which uses 40% FIFO/ 60% Pro-Rata.

 

  BlowFish said:

We have not yet discussed stop orders, there can be a whole bunch of market orders sitting (as stops) ready to be matched at different levels. I don't have to hit the button at the exact split second my order could have been sitting there for a month waiting to be elected.

 

Stop orders don't get matched any different than manual orders. They might get there quicker but they still go through the same matching algorithm.

 

 

@Paolo: Sorry, I don't understand what you are trying to say with your formulas. You bet that the largest traders win.

 

  paolfili said:

I know too it's possible on Eurex. :-(

I' m searching a market where this kind of "tricks" are not possible...

 

I wouldn't worry about these guys. They don't go through the book so they don't affect the market. At least not in the short-term.

 

  paolfili said:

Have you any experience on TT's API?

 

Yes, my front end uses TT's API.

 

  paolfili said:

Are a clear instrument to work with (c++) or a ever-changing mess (as someone suggest me)?

 

Sorry, I don't understand. Can you maybe rephrase your question or elaborate?

[RichardTodd 10]

  paolfili said:

So now according to the delta indicator 1200 were bought and only 400 sold even though the smaller trader bought 1200 and is willing to buy only another 200 while the larger trader trader sold 1200 and is willing to sell another 800.

 

Contracts bought and sold are always equal amounts, obviously, so... all you are really saying here is that you don't know how to interpret a delta indicator. In general, price moving down while delta runs up indicates not much size on the bid. And lo and behold, your example has the smaller trader on the bid. See?

[RichardTodd 10]

  AgeKay said:

Sorry, I mainly look at the most liquid Futures contracts which almost all use FIFO. The only one of those that I know that doesn't strictly use FIFO is the 2 year Treasury Note which uses 40% FIFO/ 60% Pro-Rata.

 

I have wondered myself it were possible for an exchange like Globex to match 2 market orders inside the spread. I would imagine that it's processed sequentially like you say, but I don't know. On the other hand I have seen trades matched inside the spread countless times on the NYSE, and I think it's fairly common knowledge that the specialist has a certain amount of time to hold orders for matching (which effectively makes all batched orders "simultaneous"). Or at least they used to.. it's been a while and maybe the hybrid system changed that up.

[BlowFish 10]

  AgeKay said:

I actually need to know the sequence of events. It doesn't matter how long it takes to get processed as long as it is reasonable

 

This I think we can agree on For me sequencing is what is important. particularly preserving sequence across bid ask and last data.

 

I don't want to get hung up on the trades between best bid and ask but they can and do occur. Maybe the Lee & Ready algorithm papers might explain things better than me. The thing is a stop is just a market order sitting there waiting to execute at a certain price or better. If a limit comes in and crosses that order it will execute and never display on the order book. It is also quite possible for this price to be between the current best bid and ask. Just look at a data run particularly around news or a busy open - it happens even on the ES.

 

I agree It is bothersome not knowing if a string of events happened at the same time or in sequence but slightly apart. More often than not they do occur at the same time. (I have a hunch we will have differing opinions on that ) If you see price tick above the days high and 500 orders execute at the same time there is a pretty good chance that they really did. above price extremeties there will be 100's of orders on both side of the book (stops and limits) just waiting to be filled. You would not want to see them with different time stamps nor should you. Of course with aggregation (and we dont really know who is an by how much) things get very hard to slice and dice.

[taotree 10]

  AgeKay said:

You need more accurate time stamps to determine the order of events. It's annoying to have events occur at the "same time" even though you know they didn't. This might not bother most people, but I have programmed some pretty amazing stuff that would improve with more accurate time stamps. So this is not theoretical stuff, I actually need to know the sequence of events.

 

You don't have to know the timestamps at all to know the sequence of events. So long as the data arrives in your algorithm in the proper sequence, that's all you need.

 

I use an id encoder algorithm:

 

In my code, I keep track of the most recent timestamps. When a new event comes in, I check to see if that timestamp has already arrived, if so, I increment a counter and tack that on to create my id, otherwise I tack on a 0 value for the counter. That allows me to preserve the sequence precisely regardless of the timestamp precision, and every event has a unique id.

 

Now, that assumes that the data flow from exchange through feed provider all preserve the sequence of events as they send it to you--but... no matter what you're always beholden to the accuracy of the data feed.

[paolfili 10]

@Paolo: Sorry, I don't understand what you are trying to say with your formulas. You bet that the largest traders win.

 

No.I' m saying only that you have a divergence between price and CumulativeDelta.

On this event anyone can have his opinion.

 

I wouldn't worry about these guys. They don't go through the book so they don't affect the market. At least not in the short-term.

 

I' m not so sure about it.I think (as happens in the bigSP & e-mini arena) someone can make some "tricks" selling in one side and buying on another.

For a "CumulativeDelta searcher" (as I wan to be) this is a problem ...

 

 

 

 

Originally Posted by paolfili

Are a clear instrument to work with (c++) or a ever-changing mess (as someone suggest me)?

Sorry, I don't understand. Can you maybe rephrase your question or elaborate?

 

I have no personal experience on TT's API.

Someone tell me anyway that there' s a very speed process of revision of APIs

(bugs and update).

This can be very frustrating....IMO...

Anyway... no personal experience...

[paolfili 10]

Sorry, I mainly look at the most liquid Futures contracts which almost all use FIFO. The only one of those that I know that doesn't strictly use FIFO is the 2 year Treasury Note which uses 40% FIFO/ 60% Pro-Rata.

:confused:

Someone can explain me the "Pro-Rata" matter?

Thanks

[paolfili 10]

If you are using the Zenfire' s API consider also the well know "UDP" problem of the feed...which invalidates many timestamps meaning.

Anyway I think that the "correct" sequence (send by the Exchange) can be preserved only by a "Ticker Plant" design platform.

Zenfire doesn' t offer this...

:-(

 

 

  taotree said:

You don't have to know the timestamps at all to know the sequence of events. So long as the data arrives in your algorithm in the proper sequence, that's all you need.

 

I use an id encoder algorithm:

 

In my code, I keep track of the most recent timestamps. When a new event comes in, I check to see if that timestamp has already arrived, if so, I increment a counter and tack that on to create my id, otherwise I tack on a 0 value for the counter. That allows me to preserve the sequence precisely regardless of the timestamp precision, and every event has a unique id.

 

Now, that assumes that the data flow from exchange through feed provider all preserve the sequence of events as they send it to you--but... no matter what you're always beholden to the accuracy of the data feed.

Edited March 5, 2010 by paolfili

[taotree 10]

  paolfili said:

If you are using the Zenfire' s API consider also the well know "UDP" problem of the feed...which invalidates many timestamp.

Anyway I think that the "correct" sequence (send by the Exchange) can be preserved only by a "Ticker Plant" design platform.

Zenfire doesn' t offer this...

:-(

 

All that has nothing to do with my comment--it's all still valid. The only thing you pointed out is that Zenfire does not satisfy the requirement in my last statement.

 

And to be accurate... Zenfire's out of order problem doesn't invalidate the timestamp--it's just passing that along from the exchange--it invalidates the sequence of arrival.

[paolfili 10]

The thing is a stop is just a market order sitting there waiting to execute at a certain price or better. If a limit comes in and crosses that order it will execute and never display on the order book.

 

Are you sure about it?

Is this the correct Exchanges behaviour?

Where can I find some (CME,EUREX,etc) explanation on the market dynamics you suggest? (order on trade never displayed on the book)

 

Thanks

 

 

  BlowFish said:

This I think we can agree on For me sequencing is what is important. particularly preserving sequence across bid ask and last data.

 

I don't want to get hung up on the trades between best bid and ask but they can and do occur. Maybe the Lee & Ready algorithm papers might explain things better than me. The thing is a stop is just a market order sitting there waiting to execute at a certain price or better. If a limit comes in and crosses that order it will execute and never display on the order book. It is also quite possible for this price to be between the current best bid and ask. Just look at a data run particularly around news or a busy open - it happens even on the ES.

 

I agree It is bothersome not knowing if a string of events happened at the same time or in sequence but slightly apart. More often than not they do occur at the same time. (I have a hunch we will have differing opinions on that ) If you see price tick above the days high and 500 orders execute at the same time there is a pretty good chance that they really did. above price extremeties there will be 100's of orders on both side of the book (stops and limits) just waiting to be filled. You would not want to see them with different time stamps nor should you. Of course with aggregation (and we dont really know who is an by how much) things get very hard to slice and dice.

[paolfili 10]

Sorry,but the "real" problem of Zenfire' s API is not the "out of order" (as you have noted in the Zenfire' s forum).You can solve it by re-sorting the timestamps.

Sadly to say,but the "real" problem is that UDP gives no guarantee that any packet Zenfire send will arrive.

 

 

  taotree said:

All that has nothing to do with my comment--it's all still valid. The only thing you pointed out is that Zenfire does not satisfy the requirement in my last statement.

 

And to be accurate... Zenfire's out of order problem doesn't invalidate the timestamp--it's just passing that along from the exchange--it invalidates the sequence of arrival.

[AgeKay 10]

  RichardTodd said:

Contracts bought and sold are always equal amounts, obviously, so... all you are really saying here is that you don't know how to interpret a delta indicator. In general, price moving down while delta runs up indicates not much size on the bid. And lo and behold, your example has the smaller trader on the bid. See?

 

I know how to interpret the delta indicator. What you don't see though is that after taking out the bid, 800 were left on the offer. He might even offer an additional 1000 and some long traders will be hitting the bid to get out of their losing position since they won't get filled on the offer with a huge offer like that. You always need to interpret whatever you are looking at. My point is that indicators like this leave out a lot of information.

 

  RichardTodd said:

On the other hand I have seen trades matched inside the spread countless times on the NYSE, and I think it's fairly common knowledge that the specialist has a certain amount of time to hold orders for matching (which effectively makes all batched orders "simultaneous"). Or at least they used to.. it's been a while and maybe the hybrid system changed that up.

 

I'd never trade a market with specialists. You have an information disadvantage. In Futures everyone sees the same information.

 

 

  BlowFish said:

Maybe the Lee & Ready algorithm papers might explain things better than me.

 

You are comparing apples with oranges. These papers use historical data from the exchanges that includes spread trades and OTC trades that are not reported in real-time so you do not see them in a live-feed any way. So yes they do happen, but you won't see that live-trading. I was on the phone with TT and Eurex yesterday with regards to another issue and they confirmed that you won't see spread trades and OTC trades taking place in the data feed. I've actually gotten filled several times without seeing a trade being reported at that price, which must have been a spread trade.

 

  BlowFish said:

The thing is a stop is just a market order sitting there waiting to execute at a certain price or better. If a limit comes in and crosses that order it will execute and never display on the order book. It is also quite possible for this price to be between the current best bid and ask. Just look at a data run particularly around news or a busy open - it happens even on the ES.

 

Of course, it does. You see it in Time & Sales, don't you? Well if it's there, then it was in the order book, you just couldn't see it with your eyes because it happened to quickly for your eyes to see. I can actually prove this because I have developed a way of visualizing all changes in the order book. And I do look at it during news.

 

  BlowFish said:

I agree It is bothersome not knowing if a string of events happened at the same time or in sequence but slightly apart. More often than not they do occur at the same time. (I have a hunch we will have differing opinions on that ) If you see price tick above the days high and 500 orders execute at the same time there is a pretty good chance that they really did. above price extremeties there will be 100's of orders on both side of the book (stops and limits) just waiting to be filled. You would not want to see them with different time stamps nor should you. Of course with aggregation (and we dont really know who is an by how much) things get very hard to slice and dice.

 

The exchange still executes these market orders sequentially (it's software after all) and if it's sequential then there is a small time difference. If you don't understand this, then I don't see the point of continuing this discussion. You just say stuff that isn't true and makes no sense.

 

 

  taotree said:

Now, that assumes that the data flow from exchange through feed provider all preserve the sequence of events as they send it to you

 

Well, they don't. At least in none of the data feeds I've worked with can you get sequential order book updates. Instead you get the state of entire order book at one point in time.

 

  paolfili said:

Is this the correct Exchanges behaviour?

Where can I find some (CME,EUREX,etc) explanation on the market dynamics you suggest? (order on trade never displayed on the book)

 

You won't find it because it's not true. I think before believe anything on an anonymous forum you should use common sense and/or call the exchange and just ask them if it is important to you to know how that works.

[taotree 10]

  Quote

Well, they don't. At least in none of the data feeds I've worked with can you get sequential order book updates. Instead you get the state of entire order book at one point in time.

 

Which data feeds have you worked with? Aside from the drop/sequence issues, Zenfire does give you sequential order book updates. And from what FulcrumTrader has said, I get the impression that DTN does give you that without the issues.

[BlowFish 10]

AgeKay I really can't understand why you can not see this. You are obviously a smart guy and a poster I respect. You seem to be coming at this from a completely blinkered direction. Your original argument was an order can not execute at 'half a tick' (showing an assumption that the spread can never be more than a tick wide) this suggests to me you have really not considered this properly.

 

Incidentally most of the papers on Lee & Readys algorithm either exclude data that there is not a complete audit trail for or present results with and without it. OTC trades certainly do not account for trades between best bid and ask. In fact as you can see them in a live data stream by your definition they can not be OTC trades.

 

Maybe if we go through things one step at a time we can see where we have a disconnect.

Would you agree a limit order improving best bid or ask can arrive and be elected immediately if there are enough stop orders currently on the book to fill it?

[RichardTodd 10]

  AgeKay said:

I know how to interpret the delta indicator. What you don't see though is that after taking out the bid, 800 were left on the offer. He might even offer an additional 1000 and some long traders will be hitting the bid to get out of their losing position since they won't get filled on the offer with a huge offer like that. You always need to interpret whatever you are looking at. My point is that indicators like this leave out a lot of information.

 

Delta's only there to show you one thing, and if that's not the thing you are wanting to see, don't blame delta. That's like complaining that a hammer can't turn bread into toast. And if you are trying to pull data out of a delta indicator that it's not designed to show you, then I would argue that you actually don't know how to interpret it. Sorry...

 

As I'm sure you know, the whole point of most indicators is to leave out some data in order to highlight other features. Very few are isomorphic to the data they start with. I could go around complaining that my low-pass filters leave out a lot of high-frequency data, I guess. But would I be making some kind of "point"?

[AgeKay 10]

  taotree said:

Which data feeds have you worked with? Aside from the drop/sequence issues, Zenfire does give you sequential order book updates. And from what FulcrumTrader has said, I get the impression that DTN does give you that without the issues.

 

You're right taotree. I need to take back my statement. I was wrong. I've worked with Ninja Trader, IQFeed's API (DTN), X_Trader API and another one that was tied to a specific broker. I've worked so long with the X_Trader API that I thought all of them didn't give me sequential order book updates while I just checked the API documentation of each data feed again and it looks like X_Trader API is the only one that doesn't. I stopped working with Ninja Trader and IQFeed pretty quickly because Ninja Trader didn't allow access to its data from external applications and I had latency issues with the IQFeed.

 

  BlowFish said:

Would you agree a limit order improving best bid or ask can arrive and be elected immediately if there are enough stop orders currently on the book to fill it?

 

A limit order that improves the best bid or ask will by definition be the new best bid or ask. Do you agree? If so, then you have to agree that a trade cannot occur between the best bid or ask, right?

 

I don't understand "if there are enough stop orders currently on the book to fill it". Stop orders are triggered by trades not limit orders improving market prices. And even if they were, they would still trade on that bid or ask and not some magical "mid-point". All I have been saying is that a trade always occurs at the best bid or ask.

[AgeKay 10]

  BlowFish said:

Incidentally most of the papers on Lee & Readys algorithm either exclude data that there is not a complete audit trail for or present results with and without it. OTC trades certainly do not account for trades between best bid and ask. In fact as you can see them in a live data stream by your definition they can not be OTC trades.

 

So are they using live data in their analysis or historical data?

[paolfili 10]

I've worked with Ninja Trader, IQFeed's API (DTN), X_Trader API and another one that was tied to a specific broker. I've worked so long with the X_Trader API that I thought all of them didn't give me sequential order book updates while I just checked the API documentation of each data feed again and it looks like X_Trader API is the only one that doesn't.

 

I' m working with ZenFire API.

You can have the Bid/Ask and Best_Bid/Best_Ask data,but....

But UDP streams can loose data.

If you cannot afford a very High quality connection (as the usual Rythmic customers can probably afford) you have not guaranteed sync (and no value from any CumulativeDelta analysis... if you believe in any value about CumulativeDelta analysis...).

The same problem is related to any Book Analysis/Visualization process(following Agekay point of view).

DTN seems TCP.But from the API documentation I' ve seen there 's the cumulative bid/ask wothout single level analysis.

Someone can add something on this matter about TT' s API?

 

Thanks

 

 

I stopped working with Ninja Trader and IQFeed pretty quickly because Ninja Trader didn't allow access to its data from external applications and I had latency issues with the IQFeed.

 

Can you explain the latency issue between Ninja/IQFeed?

 

  AgeKay said:

You're right taotree. I need to take back my statement. I was wrong. I've worked with Ninja Trader, IQFeed's API (DTN), X_Trader API and another one that was tied to a specific broker. I've worked so long with the X_Trader API that I thought all of them didn't give me sequential order book updates while I just checked the API documentation of each data feed again and it looks like X_Trader API is the only one that doesn't. I stopped working with Ninja Trader and IQFeed pretty quickly because Ninja Trader didn't allow access to its data from external applications and I had latency issues with the IQFeed.

 

 

 

A limit order that improves the best bid or ask will by definition be the new best bid or ask. Do you agree? If so, then you have to agree that a trade cannot occur between the best bid or ask, right?

 

I don't understand "if there are enough stop orders currently on the book to fill it". Stop orders are triggered by trades not limit orders improving market prices. And even if they were, they would still trade on that bid or ask and not some magical "mid-point". All I have been saying is that a trade always occurs at the best bid or ask.

Edited March 8, 2010 by paolfili

[BlowFish 10]

  AgeKay said:

So are they using live data in their analysis or historical data?

 

Historical data. They generally pick markets where there is a historical database available where trade direction is recorded. This information might not be available to participants but appears to be to researchers. Specialist type markets are an obvious example though there are others. (I agree with your observations about specialist markets btw). I think you might get a kick out of some of the stuff as you are interested in market microstructure.

 

I am on vacation this month and sitting in the lobby with a fast fading laptop battery so can't get involved here as much as I'd like to. It's nice to get a couple of opening DAX trades after a leisurely breakfast though!

[BlowFish 10]

Not sure if I mentioned it on this thread but NinjaTrader have really dropped the ball with NT7.0 with regards to historical bid ask last data. Sad really. On the bright side I think I have multicharts working correctly, (there are issues with multicharts & tradestation listed way back in this thread, I think I have overcome them). I just need to make sure everything holds up under heavy loads and weird unforeseen conditions.

 

The UDP issue that paolfili mentions is as he describes but it might not be that big of a deal as delta is not a precise measure of order flow anyway. Many of the afore mentioned papers seek to determine how precise it is.