Skip to content
AmiBroker TA Course

Optimization

Optimization is the easiest thing in AmiBroker to do and one of the hardest to do honestly. Two lines of AFL and a button press will hand you several hundred backtests sorted best first, and the row at the top will look far better than the system you started with. Almost none of that improvement is real, and this part is about the difference between the part that is and the part that is not.

The mechanics take one lesson. Optimize() has five arguments, returns a number, and behaves differently depending on which Analysis command you ran. The remaining four lessons are about what to do with the several hundred rows that come back, because that is where the discipline lives — and where almost every published “optimised” system quietly went wrong.

The claim this part is built to resist

Section titled “The claim this part is built to resist”

Stated plainly, the claim is: the parameter values that produced the best result on historical data are the parameter values you should trade.

It sounds so obviously right that it is rarely written down, let alone examined. It is wrong for a reason that has nothing to do with markets and everything to do with arithmetic. When you evaluate two hundred and fifty parameter combinations and keep the best one, you have run a selection process on two hundred and fifty noisy measurements. The winner is high partly because it is genuinely better and partly because it was lucky, and nothing in the result list separates the two contributions.

The remedy is not to stop optimizing. It is to change what you take away from an optimization: not the argmax, but the shape. A broad region of parameter values that all behave similarly is telling you something about the rule. A single cell that towers over its neighbours is telling you something about your sample.

What changes for you

Section titled “What changes for you”

By the end of this part you should be able to:

  • write Optimize() correctly, state what it returns in each Analysis mode, and predict exactly how many backtests a given set of ranges will produce before you start one;
  • explain why AmiBroker never writes optimum values back into your formula, and why that design decision is doing you a favour;
  • read a two-parameter surface, distinguish a plateau from a spike, and name the specific properties of your data that produce spiky surfaces;
  • run a neighbourhood sensitivity test in a few minutes and interpret its spread;
  • choose an optimization target deliberately, in AmiBroker’s own metric vocabulary, and say how a different target would have chosen a different winner;
  • describe what the three search engines shipped with AmiBroker actually are, and when a non-exhaustive search is the right tool rather than a faster way to get the same mistake;
  • produce a written parameter decision that another person could audit, including an explicit list of everything that is still untested.

What this part deliberately does not do

Section titled “What this part deliberately does not do”

It does not test the chosen parameters on data you have not looked at. Everything here happens in-sample, on the same history the choice was made from, and no amount of care inside that history turns it into evidence about the future. Part 32 introduces holdout and walk-forward testing; Part 33 covers what resampling can and cannot add. Reading Part 31 alone and then trading the result would be the exact error the part is written to prevent.

It also stays inside what AmiBroker documents. The optimization chapter of the User’s Guide describes three shipped search engines, one objective-function setting in one specific place, and a set of hard limits. Third-party optimizers, external walk-forward harnesses and commercial robustness add-ons exist, and none of them are AmiBroker features; you will not find them attributed to AmiBroker here.

What you need first

Section titled “What you need first”

Part 28’s portfolio backtest, working, with costs, delays and a liquidity filter already in place. Optimizing a backtest whose fills are unrealistic simply searches for the parameters that exploit the unrealism most efficiently, and it will find them. Part 29’s vocabulary matters too: from here on, metrics are named the way AmiBroker names them — Annual Return %, Max. system % drawdown, CAR/MaxDD — because a target you cannot spell exactly is a target AmiBroker cannot match.

The AFL is straightforward, and everything runs on end-of-day data in either edition. The Professional edition optimizes faster — up to 32 threads per Analysis window against the Standard edition’s two — but nothing in this part is unavailable in Standard.

How to read it

Section titled “How to read it”

In order, and with the software open. The first three lessons build one argument and the fourth adds the machinery; the lab then puts the whole thing to work on a real run and ends with a written decision you could defend to somebody sceptical. That written decision is the actual deliverable of the part. If you finish the lab with a good-looking number and no record of how you chose it, the part has not been completed.

Part31 of 36Level4 — Trading System ResearcherPages5Estimated time2.9 hours

0 / 5 lessons in this part completed