Bug: Faulty getMostRecentBid()/Ask in Tick Replay?

[Dave180]

10.2.1391
An efs interested in bid ask analysis will use getMostRecentBid()/Ask to compare the trade price with the Bid Ask quote prices. What I've noticed is that when both the Ask and the Bid quotes occur between trades, only the last of them is returned to getMostRecentBid()/Ask, hence, if there has been a bid and ask price change rather than just a size change, the code thinks that only one price has changed. This can result is an apparent zero-sized spread, and other complications.

Here is a commented fragment from a Tick download of ES #F for Friday.

Q,081205,150000,0,827.75,0,287,, ;; AQ 7.75
T,081205,150000,827.75,1,
Q,081205,150000,0,827.75,0,287,,
Q,081205,150000,0,827.75,0,288,,
Q,081205,150000,0,827.75,0,289,,
T,081205,150000,827.75,1,
T,081205,150000,827.75,16,
Q,081205,150000,0,827.75,0,272,,;; AQ 7.75
T,081205,150000,827.75,1,
Q,081205,150000,827.5,0,37,0,,
Q,081205,150000,0,827.75,0,271,,    ;; AQ 7.75 still, new size
Q,081205,150000,827.5,0,40,0,,
Q,081205,150000,827.5,0,48,0,, ;; BQ 7.5 still,new size
T,081205,150000,827.5,1,    ;;TB
T,081205,150000,827.5,1,    ;;TB
T,081205,150000,827.5,1,    ;;TB
T,081205,150000,827.5,2,    ;;TB
T,081205,150000,827.5,6,    ;;TB
T,081205,150000,827.5,24,    ;;TB
T,081205,150000,827.5,2,    ;;TB
T,081205,150000,827.5,11,    ;;TB, Bid size consumed
Q,081205,150000,827.25,0,418,0,,;; BQ Lower price 7.25 (was 7.5)

Q,081205,150000,827.25,0,318,0,,;; Q,081205,150000,0,827.5,0,282,,;; AQ Lower price 7.5 (was 7.75)
Q,081205,150000,827.25,0,317,0,,;; BQ 7.25 still, new size
Q,081205,150000,0,827.5,0,280,,;; AQ 7.5 still, new size

;; At the call to main() for this next trade getMostRecentBid() provides NO value (==null || ==0 test), 
;; hence the code thinks the Bid Quote is still 7.5, however getMostRecentAsk() returns 7.5,
;;  ie they are the same, the spread appears to be 0.

T,081205,150000,827.5,3, ;; TA, but code thinks TB too
T,081205,150000,827.5,3, ;; and so on, until size changes 

In other words, getMostRecentAsk(); and getMostRecentBid() never seem to both return a value. So if both the bid and ask price quote have changed there is only one update noticed by the code.

[eSignal_JasonK]

-

Hello Dave,

EFS only executes when there is a trade update, unless you are looking at a raw tick interval (i.e. T ). When the trade occurs the getMostRecent.... functions return the most recent bid or ask price. This is the current design.

[Dave180]

Jason
I'm not sure I understand. This means that all the published bid vs ask efs analysis code will not work on any chart except a "T" chart?

You did realise that the title of my post says "... Tick Replay". Why should tick replay be different to live charts, where you DO get both, not always, but usually.

Dave

[eSignal_JasonK]

-

Hello Dave,

I understand what you're saying. In tick replay the bid and ask lines are not plotted, nor do they execute main() while processing a "T" interval.

I'll add this to our backlog for a future enhancement.

[Dave180]

Jason, I still think there is a missunderstanding here, for instance I have not questioned the ability to plot the bid ask lines as you just mention.
And I am not asking for anything new to be added - I simply don't understand what it is you think I'm asking for.
To repeat:
In 10.2 the getMostRecent() calls DO NOT return the same price data when run in Tick Replay as when run live. That's it.

Although, having said that:
1) It would seem that in 10.0 there was an even worse problem as when I compare the same epf replayed on 10.0 it is different to a replay on 10.2, and worse (as shown by Bid-Ask using your BidAskRatio.efs).
2) The epfs (as downloaded with 10.2) still contain faulty (or missing) quote data.
3) When I download a tick replay with 10.0 I don't get quotes, but when I download with 10.2 I do. As far as I know the last change to my TSTQ setting was to switch it off. [Note that I do want the quote data in the tick replays, but had been assured I didn't need to have TSTQ to get that for a download, Scott has now corrected that miss-information, but I haven't changed the setting as it doesn't seem to affect 10.2).

Dave