♥ 0 |
There is some good news, we can debug scan code by using the plot statement to let the scan engine test a condition. We see that the condition is true if the results are the full set of symbols. Example: <pre> input offset = 0; <pre> The plot statement gets executed once only at the last bar – therefore it always works as expected. The interesting part when we discover a bug, mainly when our test fails (expected vs actual value). Failing example: <pre> input offset = 0; </pre> This is interesting because this discovers a bug in the scan engine not a bug in our code. WE see that simply reading the previous value of <pre>sum</pre> changes its value. I have tried to discuss this with Ameritrade which is difficult because they usuallly take a week to respond. Therefore, a real dialog is not possible. I am urging thinkscript scan developers to review this and try to increase AmeriTrade’s awareness of the problem. I hope this helps a little with your own scan efforts.
Marked as spam
|
Private answer
We have a workaround:
We now have definite proof that my test case exposes a thinkscript bug. There should be no need to use dynamic indexing with So it pays to be exact and thorough (testing variable content using the I was getting sick of the nonsense responses from Ameritrade. Whether this workaround is actually stable and generally applicable is still an open question.
Marked as spam
|
|||||||||
Private answer
I believe this issue is addressed when you convert your recursive variable, Details here: http://toslc.thinkorswim.com/center/reference/thinkScript/Functions/Others/CompoundValue.html This is the code I ended up with after debugging the code to make sure it works:
Marked as spam
|
Please log in to post questions.