Skip to content
AmiBroker TA Course

Advanced AFL

Nothing in this part is required to finish the course. You can build a research workstation, backtest it honestly and run it every evening without reading a word of what follows.

What this part is for is the second kind of trouble — the kind that does not announce itself. A formula that gives one answer on a zoomed chart and a different answer on the full history. A static variable left behind by last week’s exploration that quietly poisons this week’s ranking. A loop that runs fifty times slower than the array expression it replaced, on a machine with thirty-two threads doing nothing. A backtest metric you needed that AmiBroker does not report, and the object model that can add it.

Each of those is a real failure mode with a documented cause. This part covers the causes.

What is here, and why these six

Section titled “What is here, and why these six”

Dynamic variables — VarSet, VarGet, VarSetText, VarGetText — build variable names at run time. They solve exactly one problem: the name is not known when you write the formula, because it comes from the data. They are also the single easiest way to make a formula unreadable, so the lesson spends as much time on when not to use them.

Static variables in depth picks up where Part 13 left off. Part 13 used them to carry ranking scores between passes. Here the subject is what they actually are: a process-wide key/value store that outlives every formula run, that nothing clears for you, that can be written to disk, and that several threads read at once. Every one of those properties is a way to corrupt state if you are careless with it.

Matrices are AFL’s two-dimensional numeric type, added in version 6.00. The lesson lists what the fifteen documented matrix functions actually do, is explicit that @ is the only true matrix product and every other operator is element-wise, and shows one worked case where a matrix genuinely beats arrays.

QuickAFL is the most important page in this part. It is a speed optimisation that gives your formula fewer bars than the database holds, and AmiBroker’s own knowledge base documents four categories of code where that can change the answer without any warning at all. If you read one lesson here, read that one.

Debugging and tracing covers the visual debugger, _TRACE/_TRACEF, and — more useful than either — a method for formulas too tangled to eyeball: bisect them, build a harness, and check the result against a calculation you did another way.

The custom backtester interface is the object model that lets AFL take part in the second phase of a portfolio backtest. The lesson gives a working example that adds two metrics to the report, explains what the three levels of the interface are, and then stops and tells you where to learn the rest. That boundary is deliberate.

What this part will not do

Section titled “What this part will not do”

It will not turn into a reference manual. The AFL Function Reference already exists, it is mirrored in your AmiBroker installation, and it is more complete and more current than any course could be. Where a lesson lists functions, it does so because the list itself is the point — as with the matrix family, where knowing what is absent is what stops you inventing calls that do not exist.

It will not teach the whole custom backtester. The mid-level and low-level approaches give you control over signal processing and over the bar-by-bar trading loop, and doing that correctly means understanding the order in which the backtester updates equity, handles stops and closes positions. That is a subject with its own failure modes, and a half-taught version of it produces backtests that look plausible and are wrong.

It will not teach automated order execution. As everywhere else in this course, the chain ends at alert, human review, decision.

Part36 of 36Level3 — AFL DeveloperPages6Estimated time2.9 hours

0 / 6 lessons in this part completed