QQQQ Bid Ask Precision

[fish7]

I wrote an EFS that is using the getMostRecentBid() function (and the corresponding Ask one, and the Trade one, too)...

The QQQQ trades and quotes (bid and ask) to 3 decimal places, yet eSignal seems to only report them to 2.

Is there a way around this? I need more precision for QQQQ.

The current situation makes it impossible to identify via an EFS script if a trade went off at the bid or the ask, since rounding errors obscure what price the bid, ask, and last trade were.

JOHN

[eSignal_JasonK]

Hello John,

The EFS functions see the full price precision. The problem is that number are represented in JavaScript as floating point numbers, which results in some numbers containing an extreme precision such as 43.62000000000005. The solution is to apply the .toFixed(4)*1 method to the results of the getMostRecentXXX() functions. The .toFixed() method converts a number to a string. To convert the result back to a number, multiply by 1. Try the following.

function main() {
    var nB = (getMostRecentBid()).toFixed(4)*1;
    var nA = (getMostRecentAsk()).toFixed(4)*1;
    var nL = (getMostRecentTrade()).toFixed(4)*1;
    
    debugPrintln("######################");
    debugPrintln("bid: " + nB);
    debugPrintln("ask: " + nA);
    debugPrintln("last: " + nL);

    return;
} 

[fish7]

Jason,

I put in the
.toFixed(4)*1
suggestion of yours, and it still only gets the bid, ask, and last trade price to 2 decimal places.

Try it with QQQQ for the symbol.

Or did I do something wrong?

JOHN

[eSignal_JasonK]

Hello John,

Most of the trades are only 2 decimals. However, I am seeing 3 and 4 decimals for some trades on occasion. The bid and ask prices however have only been coming through with 2 decimals. Take a look at the data in a Time and Sales window for comparison.

[fish7]

Jason,

I ran it again today on the QQQQ, and have attached a .CSV file of the output for a minute of data. B means Bid, A means Ask.

As you can see, there are substantial times when the Bid and the Ask are IDENTICAL... that is EXTREMELY un-likely. That is due to someone rounding the data from its 3 decimal place of accuracy to only 2 -- rendering any analysis of bid or ask action impossible. When eSignal EFS says the bid is exactly the same as the ask, how can anyone say whether the trade went off at the bid or the ask? OBviously, this is an error in reporting the bid and ask, due to rounding somewhere in the chain of data flow.

Keep in mind that the QQQQ is the single most liquid equity product on the market, and that at least 1/3rd of all QQQQ volume is done on INET, which trades with spreads of 0.1 to 0.3 of a cent nearly all day long. Hence, at least 1/3rd of the data should have prices (trades, bid, and ask) that have 3 digits of precision -- currently, very very few come across that way.

So , the question becomes, is the data that is available to eSignal EFS programmers only the (relatively useless) rounded numbers, or is there some way to get at the real trade values (accurate to 3 decimal places)?

JOHN

[fish7]

Oops... here's the attachment (a Microsoft Word file), showing the QQQQ data from today (partial),... showing Bid, Ask, Price, and Size, as obtained from EFS.

[eSignal_JasonK]

Hello John,

I'm seeing the identical bid ask prices on my end as well. I've started an internal inquiry regarding this issue. When I receive word on this issue I'll report back to this thread.

[fish7]

Thnx, Jason, that'll be great!

Also, fwiw... as per your suggestion below to use the .toFixed() suffix, my eSignal kept puking on that, until I re-arranged the formula, and multiplied by 1, first, and then did the .toFixed operation on the number. The .toFixed suffix does not work on strings.

The following works:
Price = (getMostRecentTrade()*1).toFixed(4);

JOHN

[eSignal_JasonK]

Hello John,

Price has you currently have it, is still a string. Try returning it to the chart from the return statement.

Not sure what you were doing that was causing it to puke. I haven't had any problems with the .toFixed() method. The proper way to convert the fixed result from a string back to a number is below. Notice that the getMostRecentxxx functions are surrounded by parens before the .toFixed() method is applied. Multiplying by 1 should be the last step in the operation. Give this a try.

function main() { 

    var nB = (getMostRecentBid()).toFixed(4)*1;
    var nA = (getMostRecentAsk()).toFixed(4)*1;
    var nL = (getMostRecentTrade()).toFixed(4)*1;
    
    return new Array(nB, nA, nL);
} 

Fyi, I haven't heard anything yet on the decimal precision of the QQQQ data.

[fish7]

When I put that into the EFS editor and then press the "checkmark" button to have it check for errors, I get the message saying "TypeError: getMostRecentBid() has no properties".

If, however, you change your line to :
var nB = (getMostRecentBid()*1).toFixed(4)
then it passes the error checking routine.

[eSignal_JasonK]

Hello John,

The error message from the syntax checker is actually correct technically because of the way the getMostRecentxxx() functions are implemented. They require access to a real time quote in order to return a valid number. The number object has the .toFixed() method. During the syntax check the getMostRecentxxx() functions cannot access a real time quote so they return null. Therefore, null.toFixed(4) is invalid syntax, which is why you get the error message upon a syntax check. If you run the code on a chart it will work properly because the real time quote data is available to the function. Anyway, the solution to allow it pass the syntax check is to add null checks as in the following example.

function main() { 

    var nB = getMostRecentBid();
    var nA = getMostRecentAsk();
    var nL = getMostRecentTrade();
    if (nB == null || nA == null || nL == null) return;
    
    nB = nB.toFixed(4)*1;
    nA = nA.toFixed(4)*1;
    nL = nL.toFixed(4)*1;
    
    return new Array(nB, nA, nL);
} 

The reason var nB = (getMostRecentBid()*1).toFixed(4) passes the syntax check is because the result of getMostRecentBid() *1, which occors first in the order of operations, equates to 0 (ie. null*1 = 0). Since 0 is a valid number, which accepts the .toFixed(4) method, 0.toFixed(4) passes the syntax check. However, the result of (getMostRecentBid()*1).toFixed(4) is still a string.

I hope this clears up any confusion I may have caused for you.

[eSignal_JasonK]

Hello John,

I just realized another solution to this problem based on the code you're using. This one is even better.

var nB = (getMostRecentBid()*1).toFixed(4)*1;

As I just explained, the first *1 in the expression avoids the null.toFixed(4) result, which is invalid syntax, with a result of 0.toFixed(4). So adding another *1 at the end of the expression converts the string to a number. Therefore the null check routine I used in the prior reply can be eliminated.

[fish7]

Jason, I like that second fix even better!.. thnx!

Still looking fwd to hearing what you find out about the rounding on the QQQQ bid/ask.

Cheers!

[eSignal_JasonK]

Hello John,

Here's the scoop on the bid/ask data. All of the exchanges we receive data from only send us 2 decimal precision data for bid and ask prices. We are not doing any rounding or truncation on this data. If it comes to us with more than 2 decimals it would be shown in the time and sales window. EFS would also see the same thing.

The reason we see the bid and ask price at the same price sometimes is because the multiple exchanges we receive this data from are not synchronized with each other. The combined data will sometimes result in the same price for the bid and ask. There isn't anything we can do to resolve this, it's simply the nature of the data.

Therefore, it isn't currently possible for EFS to determine if a trade price occurred at the bid or ask for the occurrences where all 3 prices are the same. In order to resolve this within EFS, we would need the bid Exchange and ask Exchange data exposed to EFS. Please feel free to submit a request for this feature to our development team at [email protected].