Errors in tick bid, ask and trade data

[ddresser]

When tick data is requested using RequestHistory, it should arrive as double precision numbers which the API can obtain by examining BarData. It appears that the double precision numbers for dTickBid, dTickAsk and dTickTrade are arriving with the two words that make up the double precision number reversed. Examples are set forth below. I am using eSignal 10.6.2124.1086 (10/25/2010), and examining the data with Delphi 10. With the same setup, I have been receiving other BarData fields, which also arrive in double precision format, correctly for several years.

The examples below are all from the symbol RF, chosen because it trades at a slow pace, and were captured this morning. The stock traded in a range of 7.20-7.30, and the following examples were repeated several times --

When the stock traded to 7.24, my software captured the double precision numbers dTickTrade as -1.10707273898053E-234 and dClose as 7.24. If one takes the dTickTrade number and converts it to hexadecimal, it is 8F5C28F6 401CFFF1. The hex value of 7.24 is 401CF5C2 8F5C28F6. Note that the two hex numbers are nearly identical if the two words are reversed. Rounding explains the small differences.

Here are similar examples --
trade price 7.25 = hex 401D0000 00000000
dTickTrade received 5.31439236186186E-315 = hex 00000000 401D0A3D

trade price 7.26 = 401D0A3D 70A3D70A
dTickTrade = 3.94265077742761E234 = hex 70A3D70A 401D147E

trade price 7.28 = hex 401D1EB8 51EB851F
dTickTrade = 4.27698109103153E86 = hex 51EB851F 401D1EBF

The dTickBid and dTickAsk numbers arrive reversed in the same fashion.

Please let me know if there is anything else that I can provide to help get this fixed.

Thanks,
Don

[eSignal_AveryH]

ddresss,
Thank you for the post and the example. I'm not familiar with Delphi so it difficult for me to understand how you're getting the hexadecimal number. But using a VB sample I created for history request this is what I was able to come up with for the request below. The attached screenshot displays the returned data.


lHistoryHandle = esignal.RequestHistory (RF, T, btBars, 9, -1, -1)

rivate Function FormatBarData(lIndex As Long, item As BarData)
Dim sRet As String

sRet = Str$(item.dtTime)
sRet = sRet + ": Open" + Str$(item.dOpen)
sRet = sRet + ", High" + Str$(item.dHigh)
sRet = sRet + ", Low " + Str$(item.dLow)
sRet = sRet + ", Close " + Str$(item.dClose)
sRet = sRet + ", Bd " + Str$(item.dTickBid)
sRet = sRet + ", Ask " + Str$(item.dTickAsk)

FormatBarData = sRet




Is it possible that you can try one of our samples and see if you get the same results?

Thank you


AveryH

[ddresser]

Avery,

Thanks for the quick reply.

The curiosity is that I am receiving 5 minute bar data just fine (there is a problem with dtTime, but I will leave that for later). But tick data contains really odd numbers for bid, ask and trade, not at all like your VB program shows. So, I looked at the results using a fancy calculator to see what the data I was seeing looked like in hex form. See http://babbage.cs.qc.edu/IEEE-754/Decimal.html, which translates floating point numbers into their machine representation.

One possible cause of the problem is that BarData is not being unpacked properly by Delphi. Because bfFlags is a single word, and the rest are doubles, I might be getting the remaining data offset by one word, which would explain what I am seeing.

I will check this possibility and let you know.

Don

[ddresser]

Avery,

I think that I have solved the problem.

The type library that eSignal provides, named winsig.tlb, contains record formats for BarData and other data that is available via the API. As it translates in Delphi, at least, and probably other languages as well, BarData and other records are designated as "packed", meaning that the fields are not aligned to some specific length.

In reality, BarData records show up as unpacked, aligned to double word lengths. Accordingly, when my software read the last three fields in the record (dTickBid, etc.), believing that it was looking at a packed record, the double word that it picked up was off by 32 bits, and the result looked as if the words were switched.

This result might be due to the fact that the system that was receiving the BarData records from eSignal has a 64 bit processor.

To resolve the problem, all that I had to do was change the BarData from a packed record to "record" in the type library, and recompile.

I am letting you know because it is likely that other users will come across the same issue, and might be able to use the same solution.

Thanks for the help,
Don