Support Board
Date/Time: Mon, 25 Nov 2024 14:50:33 +0000
Post From: "accurate" backtest results change when multiple charts opened
| [2014-02-03 05:14:00] |
| |
|
Also, the "bar-based" back-test gives an even different result. 3. "For All Charts in Chartbook" is not selected; If I do select it, I get an even different result... https://www.sierrachart.com/index.php?l=doc/doc_Backtesting.php I have spent a great amount of time finding "undocumented features" (bugs) of ACSIL and I am really starting to question if SC is even capable (or stable enough) to handle an "auto-bot" trading system... What are these? From our perspective there are none. And we take exception to this. Rather than saying this, provide us a simple example of a problem so we can reproduce it and resolve it. Otherwise, nothing is accomplished here. At this point you have provided no evidence of a problem. There has been only one recent ACSIL issue and it was identified and resolved and documented in the What Is New notes for 1086: https://www.sierrachart.com/index.php?l=doc/Whats_New.php We cannot help you unless we get a simple example to test. I use three "persisted" variables in my function and observed that the location of the declaration of the seems to have changed the results also This makes no sense. This could not possibly have any effect and if it does, this must be a code issue on your side. This could not be a cause. The only reason I mention this is that I also had a problem where the "persisted" values caused a continuous "CPU exception" error which was cause by assigning a float value to a double "persisted" value without "casting" it to double... This makes no sense either and we just tested this and encountered no exception at all. Here is the actual code tested: //Persistent variable test
double &DoubleReference= sc.PersistVars->Doubles[0]; float TestFloatValue = 3.0f; DoubleReference= TestFloatValue;//No exception occurs If you are encountering an exception with code like the above, it is a very strong indicator, something is wrong with your code or the compilation of the code. There should be no trouble with this whatsoever. None at all. This could not be a Sierra Chart issue at all. There is 0% chance of that. Sierra Chart has no involvement of the compilation or running of that code, other than actually calling the function. The compilation is handled by a separate compiler. Keep in mind if you are corrupting memory, you can run into all kinds of unusual problems that occur later on in your code and effect Sierra Chart code and are extremely hard to find. And we suspect this could be what is going on in your case. It does seem like there is a bug in your own code and then it appears like a problem within Sierra Chart. We cannot debug your own code. This is why you need to work with very simple code examples to reproduce a problem and then if there is no problem, then you know that the problem most likely will be in your own code. Start off with a simple example then gradually add to it, until there is a problem. Then determine where the source of the problem is. If it is in your own code, resolve it . If you believe it is within Sierra Chart, then give us a simple example to duplicate the problem. If you need help or think there is a problem, provide us a simple example to work with. It does not help at all to say "Please explain" to something programmatically you are doing and obviously is complicated, and not giving us anything to work with. And then you make comments about problems with out any code to back them up. We cannot respond to this differently than we have. 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: 2014-02-09 11:42:27
|