Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Thu, 18 Apr 2024 23:00:01 +0000
[Programming Help] - Bug in sc.BaseData during replay?
View Count: 960
| [2019-11-18 06:54:11] |
| BrMa - Posts: 77 |
|
Dear ladies and gentlemen, I'm having the following issue during backtesting/replaying data (regardless if I'm using Accurate Trading System Back Test Mode or Calculate at Every Tick/Trade - altough it shouldn't make a difference on this issue anyhow): The attached images MiniDAX-Backtesting-1.jpg and MiniDAX-Backtesting-2.jpg show two bars with a high of 11992. So I'd expect sc.BaseData[SC_LAST][index] to turn somewhen during the processing of these bars to the value 11992. Unfortunatelly debugging shows, it never does. What is interesting during debugging is, that in both cases sc.BaseData[SC_HIGH][index] turns to 11992 with the same tick, when sc.BaseData[SC_LAST][index] turns to 11991.Can you please check why the high of a bar (and possibly also the low but I didn't check that) is not represented by a tick representing this value? The contract I'm testing with is F.US.DXMZ19 using a volume-chart with 100 pieces per bar. If you need any additional information on this please don't hesitate coming back to me! Thank you very much in advance! Regards, Markus |
 MiniDAX-Backtesting-1.jpg / V - Attached On 2019-11-18 06:23:10 UTC - Size: 45.2 KB - 296 views MiniDAX-Backtesting-2.jpg / V - Attached On 2019-11-18 06:23:14 UTC - Size: 44.08 KB - 213 views |
| [2019-11-18 12:03:18] |
| |
|
First, there is 0% chance there is anything wrong. It is not even anything we would even look at or even consider because it is 100% impossible. There must be some other misunderstanding or explanation or incorrect analysis. Maybe you are using Renko bars.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-11-18 12:03:54
|
| [2019-11-18 13:27:52] |
| BrMa - Posts: 77 |
|
Believe me I'd be happy to be proven wrong - but another very simple test shows the following: I put together the following testing routine: SCSFExport scsf_TestIndex(SCStudyInterfaceRef sc) { if (sc.SetDefaults) { sc.GraphName = "TestIndex"; } else if (!sc.IsFullRecalculation) { float highPrice, lastPrice, debuggerStopLine; for (int index = sc.UpdateStartIndex; index < sc.ArraySize; index++) { highPrice = sc.BaseData[SC_HIGH][index]; lastPrice = sc.BaseData[SC_LAST][index]; debuggerStopLine = 0; } } } Please also note the index stays unchanged - so no new bar! Could the issue occur because of manual looping? I don't wanna bother you but this is a serious issue! Thank you for your help! Btw: I'm using version 2011 of Sierra Chart. |
| ChartSettings.jpg / V - Attached On 2019-11-18 13:12:53 UTC - Size: 176.4 KB - 275 views Debugger-1.jpg / V - Attached On 2019-11-18 13:15:54 UTC - Size: 126.39 KB - 286 views Debugger-2.jpg / V - Attached On 2019-11-18 13:16:00 UTC - Size: 130.25 KB - 280 views |
| [2019-11-18 14:31:02] |
| |
|
We cannot spend the time to be running through tests. There is simply 0% possibility of a problem here. But just simply looking at what you said in post #3 why do you think there is a problem? It is perfectly normal for the sc.BaseData values to change at indexes from the old array size up to the current size during chart updating. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-11-18 14:35:10
|
| [2019-11-18 14:34:16] |
| |
|
Post above has been updated.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2019-11-18 14:51:03] |
| BrMa - Posts: 77 |
|
But just simply looking at what you said in post #3 why do you think there is a problem? It is perfectly normal for the sc.BaseData values to change at indexes from the old array size up to the current size during chart updating.
Because: First there is an increase to 11990 - the new high (11990) is established by the last tick (11990). So far so good. In the next iteration (-> the next tick!) the new high is 11992 giving a new last tick with 11991. BUT: where is the tick that brought the high to 11992 if the last one is 11991? How can there be a new high of the bar without a tick making the high? From an exchange point of view, this is impossible. There is a one to one-relation between a tick and a price. So the bar cannot make a new high (11992) and close at a different price (11991) with one tick, because either the price of the tick is 11992 OR 11991 - it cannot be both! Do you see my point? |
| [2019-11-18 23:27:10] |
| |
|
The study function is not called at every tick.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2019-11-19 06:50:46] |
| BrMa - Posts: 77 |
|
The study function is not called at every tick.
Are you serious?Documentation (https://www.sierrachart.com/index.php?page=doc/ReplayChart.html#ReplayMode) says Calculate at Every Tick: When using Calculate at Every Tick/Trade, this is identical to the Accurate Trading System Back Test Mode Replay Mode, except that the study functions on the chart are going to be called/calculated for each data record in the Intraday data file. Therefore, when using tick by tick intraday data this is a very high accuracy, but inefficient, Back Test.
I know the quality of tick-data in intraday-files differs between the providers available. That's why I'm using intraday-data provided by CQG, as they are known to have precise intraday data. I have to admit, that your statement would make sense in terms that I experience situations in backtesting where e.g. a sell limit of a long position is not executed although the high of the bar is higher then the price of the limit. Or a stop is not triggered although the price spiked beyond it (if you're saying that's impossible, I can provide you with some examples). If your statement is right, I see two issues: 1) Documentation is wrong because it explicitely says at every tick 2) Back-testing results are partially wrong because there can be situations (as described above) where orders are not executed in backtesting but they would have been executed in reality!? If this assumption is correct, this is a serious issue! Please take a look into that! SierraChart is a great tool and famous for its replay and backtesting-functionality! If the statement and the assumptions are correct, please correct this, so proper backtesting is possible! |
| [2019-11-20 02:51:15] |
| |
|
From our perspective we cannot confirm what you are doing. And we cannot always trust what users tell us. You have said: (regardless if I'm using Accurate Trading System Back Test Mode or Calculate at Every Tick/Trade - altough it shouldn't make a difference on this issue anyhow):
So we do not even know the particular replay mode you are even using. There is always a technical explanation for something like this: a sell limit of a long position is not executed although the high of the bar is higher then the price of the limit. Or a stop is not triggered although the price spiked beyond it (if you're saying that's impossible, I can provide you with some examples). All price values are processed for filling orders. There simply cannot be any real problem with this. Refer to the documentation here:Trade Simulation: How Orders are Filled You also need to make sure that the data that you are working with during the replay is tick by tick data. It might not be even though you think it is. Refer to: Tick by Tick Data Configuration 2) Back-testing results are partially wrong because there can be situations (as described above) where orders are not executed in backtesting but they would have been executed in reality!? If this assumption is correct, this is a serious issue! And the documentation is correct. But we do not know what the replay mode is. There is no way we can validate that. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-11-20 03:10:11
|
| [2019-11-20 07:20:02] |
| BrMa - Posts: 77 |
|
Dear ladies and gentlemen, meanwhile I could resolve the issue and would like to share the solution with you as both of us seem to be right - the origin is at a completely different end: I used your function Edit >> Export Intraday Data to Text File documented in Exporting and Importing Intraday Data Files: Export and Edit to see the tick data used in detail. This shows the following for the date/time discussed: Date, Time, Open, High, Low, Last, Volume, NumberOfTrades, BidVolume, AskVolume
This extract shows, that tick data is incomplete as there is no tick provided for 11992 - it shows exactly the picture I received when debugging the data. So I can confirm your replay is really on tick-based data and correct. I will contact CQG on this issue.2019/9/2, 10:28:49, 11989, 11990, 11989, 11990, 11, 6, 4, 7 2019/9/2, 10:28:50, 11991, 11992, 11990, 11991, 17, 8, 5, 12 2019/9/2, 10:28:51, 11991, 11991, 11991, 11991, 2, 1, 2, 0 Please take my apologize - I never thought the issue could be with the tick-data provided. Thank you and regards, Markus |
| [2019-11-20 11:51:05] |
| |
|
Do not contact CQG. You are not understanding that the data is not coming directly from CQG. And CQG does not even provide historical data for expired contracts. People do not realize how limited CQG is and how expensive it is. If users were exposed to CQG pricing and its limitations, hardly anyone would be using it. Anyway without going into details, to overcome this limitation just update to the latest prerelease: Software Download: Fast Update Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-11-20 11:51:32
|
| [2019-11-20 13:02:32] |
| BrMa - Posts: 77 |
|
I updated to the latest prerelase (Version 2013), deleted and reloaded ALL data and can confirm it works! Exporting intraday data shows you somehow split the data into more detail. THANK YOU FOR YOUR HELP AND SUPPORT! |
| [2019-11-20 13:31:17] |
| BrMa - Posts: 77 |
|
One amendment: if I'm closing down SierraChart but not reconnecting to the data-feed after a restart - the yellow message "Waiting to Download Historical Data" never disappears. And much more disturbing: backtesting via the reply-functionality does not work anymore! It only starts working again if the data feed reconnected and the message regarding the historical data disappeared. Can you please restore the original behaviour on this one, so that I can constantly backtest the same period and not reload the data and "cut it down" afterwards with the Intraday Data Editor every time I restart SierraChart? Thank you! Date Time Of Last Edit: 2019-11-20 13:32:10
|
| [2019-11-20 19:17:48] |
| |
|
And much more disturbing: backtesting via the reply-functionality does not work anymore! One amendment: if I'm closing down SierraChart but not reconnecting to the data-feed after a restart - the yellow message "Waiting to Download Historical Data" never disappears. There should not be any problem like this. There is either something very unexpected going on in your particular case, or the download is just taking a long time for some reason. This issue is not reproducible by us. Let us know if you continue to see this. But we would expect not.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-11-20 19:18:29
|
| [2019-11-21 05:17:31] |
| BrMa - Posts: 77 |
|
I was able to resolve the issue the following way: I removed all F.US.FDX*.* files in the data-directory of SierraChart manually (and there were quite lots of as I'm working with it for quite some time). After the start of SierraChart all data was reloaded and the issue resolved. Thank you! |
| [2019-11-21 17:35:00] |
| |
|
Ok not sure what the issue was because that does not make sense as something that would resolve this.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2019-11-22 05:40:04] |
| BrMa - Posts: 77 |
|
You are right - I had the same issue again yesterday evening. I'll keep you updated in case I can narrow it down to a straight cause-effect relation.
|
To post a message in this thread, you need to log in with your Sierra Chart account: