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

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 4.00 out of 5)
Loading...Loading...

7 Responses to “Introduction to Debugging AFL”

  1. dan prosser
    July 12th, 2007 | 9:15 am

    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.

  2. Herman
    July 14th, 2007 | 11:16 am

    That is a good idea Dan, I will cover that in a future post.

    Thanks for your feedback!

    herman

  3. Herman
    July 15th, 2007 | 9:29 pm
  4. Daniel Laliberte
    July 18th, 2007 | 5:53 pm

    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.

  5. Herman
    July 18th, 2007 | 6:24 pm

    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.

  6. Daniel LaLiberte
    July 18th, 2007 | 10:05 pm

    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.

  7. dan prosser
    October 4th, 2007 | 2:05 am

    I agree that interpretation window can slow down large formulas.
    DebugView is appropriate for large formulas or auto-trading formulas
    Interpretation Window is appropriate for small formulas or doing problem solving on ‘code fragments’
    My formulas are all pretty fast so I never notice the extra cycle.