Support Board
Date/Time: Tue, 26 Nov 2024 06:47:20 +0000
Post From: Combine Trades into Original Summary Trade - ACSIL data issue with s_IntradayRecord
| [2023-12-31 12:56:10] |
| curious16 - Posts: 10 |
|
Hi Sierra Team, There is an issue with the s_IntradayRecord data which occurs only if the "Combine Trades into Original Summary Trade" option is set. I use Teton/Denali - I understand that the "Combine Trades" functionality does not work reliably with other feeds. I did the following test: - set chart to 1 trade - write ACSIL test code to loop over the s_IntradayRecord records for each bar (ibar) and trade (itrd) while readOK is true: (readOK = sc.ReadIntradayFileRecordForBarIndexAndSubIndex(ibar, itrd, intraRec, IFLA_NO_CHANGE)) - calculate volume for each bar by summing intraRec.TotalVolume of all trade records in the bar - compare this to the base data bar volume -> there should be no difference Without using Combine Trades, there are no differences between the two volume data traces, as expected. However, when Combine Trades is enabled, differences appear. It seems that these differences are caused by incorrectly allocating trade records of a bundled trade to the s_IntradayRecords of the PREVIOUS bar index. This happens if the successive bar index starts with a bundled trade on the opposite side (bid vs. ask) compared to the previous bar. I saw the same behaviour across various CME futures and dates - this almost certainly is not a data issue but a bug in the mapping logic used for allocating raw data to the s_IntradayRecord records. The two attachments give an example to illustrate the issue. Data: RTYH24_FUT_CME, latest date = 2023-12-29, chart set to 1 trade, Combine Trades enabled. The bottom trace shows differences between base volume data and volume obtained from the s_IntradayRecords (yellow bars). The debug output shows a sequence of intraRec data. It highlights the start of a bar (ibar=359783) with data discrepancy. This bar (visible also on the screenshot) has a sum of the s_IntradayRecord volumes that exceeds the base data volume. The bar with ibar=359783 has the first trade at 16:06:03.824 and continues to include further trades at 16:06:04.313. This is suspicious as a single trade bar should not extend over multiple milliseconds. The additional trades (itrd >= 1) allocated to this bar start with an initial record of a bundled trade (open = large negative number). The next bar with ibar=359784 has the first and only trade at 16:06:04.313. This is the final record of a bundled trade. If the trades starting with itrd=1 of ibar=359783 were instead allocated to ibar=359784 (that is, if the entire bundled trade was allocated to the next bar), there would be NO discrepancy between the base data volume and the volume obtained from the s_IntradayRecord data. I understand this is rather subtle and may seem a bit tedious to review, but it would be highly valuable to have this issue fixed. It is beneficial to use the Combine Trades function (fewer bars, faster processing, better insight into large trades), but that shouldn't come at the cost of getting data issues when using the s_IntradayRecord data. I feel a bit sorry for raising this on the last day of the year. I really appreciate the high quality and performance of SC and the flexibility offered by the ACSIL interface. With other trading platforms it wouldn't even be possible to dive into such tick-level detail. However, as you do offer this level of data granularity it is valuable to iron out such wrinkles. Happy New Year to you and hope to hear back about this in Jan 2024. |
 Screenshot_VolumeDiscrepancies.jpg / V - Attached On 2023-12-31 12:43:46 UTC - Size: 54.63 KB - 64 views DebugOutput_s_IntradayRecord_RTYH24.jpg / V - Attached On 2023-12-31 12:43:53 UTC - Size: 198.44 KB - 57 views |