June 19, 2007
Introduction to Debugging AFL
Designing Automated-Trading systems can be complicated, and you can expect to spend a significant amount of time debugging your code. You will undoubtedly experience elusive problems that may be due to Internet delays, faulty data (such as low volume data spikes), orders that do not get processed, lack of volume, communication problems, etc. Such problems require you to know how to capture and display transient conditions, such as, for example, how orders are processed and acknowledged.
In real-time trading many events are not completed in a single AFL execution but in a sequence of small steps that are spread out over time and over many chart refreshes (AFL executions). This requires debugging techniques that are very different from EOD programming.
This category covers basic debugging techniques, such as: how to capture transient events, maintain a log, zero in on run-time bugs, display system variables, etc. Developing basic debugging techniques up front will save you significant time later.
Edited by Al venosa
Filed by Herman at 8:56 pm under Debugging AFL
6 Comments
hi,
I suggest a registered Author should add some instructions on using the Interpretation window with printf() [I would do it but don’t want to sign up as author for 1 paragraph of text]
if (Status(“action”) == actionCommentary)
{
printf(“Buy=%f\n”, Buy);
}
I find that I generally never need to use _trace() i can almost always use printf() and look at the interpretation window.
Dan.
That is a good idea Dan, I will cover that in a future post.
Thanks for your feedback!
herman
Hello Dan, please see: http://www.amibroker.org/userkb/2007/07/14/debugview-vs-interpretation-window/
Debugging AFL for automated trading is an extension of debugging AFL for other purposes. Many debugging techniques will apply to both. Just getting your custom indicator to do what you want requires understanding how AFL deals with arrays, undefined values, boundary conditions, etc.
One technique I use frequently to debug my indicators is to simply plot intermediate values, even boolean values. Seems obvious to experienced developers, but it shouldn’t be skipped in a tutorial.
Dan, I am not quite sure what you mean with plotting ‘intermediate values’ and ‘boundary conditions’… can you explain?
I have a draft on Timing Diagrams. In this post I display binary signals as they would be displayed using a Logic Analyzer (as is used in an electronic lab). However I usually display binary data using ribbons and will add that to the post as well.
By “intermediate values”, I mean for a complex formula, it may help to look at results of some of the subexpressions to find out what might be going wrong with the end result.
By “boundary conditions”, I just mean where things can go wrong on the edges, such as the beginning and ending of loops, the initial values of arrays, data values that are flakey extremes, things like that.