Amibroker — Afl Code Verified

By following this guide, your AFL code will be verified both syntactically (it runs) and logically (it does what you think it does).

To generate and verify a full backtest report in AmiBroker using AFL code, you must configure specific backtester options within your script or the Analysis window settings. 1. Enabling the Full Report via AFL

You can force AmiBroker to generate a full report for every test by adding the following SetOption command to your AFL code:

SetOption("GenerateReport", 2); – This enables the generation of a full report.

Report Storage: Once enabled, reports are stored in the Report folder within the AmiBroker directory.

Viewing: You can access them through the Report Explorer in the Analysis window. 2. Manual Verification and Settings

If you prefer to configure this through the user interface rather than code:

Generate Reports: In the System Test Settings window, ensure "Generate detailed reports for individual backtests" is enabled.

Include Trade List: Verify that "Include trade list in the report" is turned ON (default) to see individual transaction details.

Performance Impact: Note that generating full reports for large batches (like optimizations) will significantly slow down the process and consume more disk space. 3. Basic Backtest Verification Code

To ensure your code is "verified" (syntax-ready for a report), it must include at least one Buy and Sell rule. Below is a template for a basic strategy that includes the full report option: amibroker afl code verified

// Enable Full Report Generation SetOption("GenerateReport", 2); // Strategy Rules Buy = Cross(Close, MA(Close, 50)); Sell = Cross(MA(Close, 50), Close); // Optional: Add custom columns for report verification Filter = Buy OR Sell; AddColumn(Close, "Price"); Use code with caution. Copied to clipboard 4. Advanced Reporting with Custom Backtest Procedure (CBT)

For more detailed verification (e.g., custom metrics like "Max % Trade"), you can use the Custom Backtester Interface: Use SetCustomBacktestProc(""); to define custom logic.

Access the backtester object via bo = GetBacktesterObject(); to manually add metrics like bo.AddCustomMetric("MyMetric", value);. Summary of Report Outputs A verified full report typically includes:

Performance Metrics: Net Profit, CAR (Compound Annual Return), Max Drawdown, and Sharpe Ratio.

Trade List: Detailed entry/exit dates, prices, and individual trade profits.

Charts: Equity curve and drawdown charts, which are often exported in HTML format to preserve color and formatting.

AI responses may include mistakes. For financial advice, consult a professional. Learn more System test settings window - AmiBroker

Title: The Critical Importance of Code Verification in Amibroker Formula Language (AFL) Development

Introduction

In the fast-paced world of financial markets, technical analysis software serves as the backbone of modern trading strategies. Amibroker stands out as one of the most powerful and versatile platforms available, largely due to its proprietary scripting language, Amibroker Formula Language (AFL). AFL allows traders to create custom indicators, scanning tools, and algorithmic trading systems tailored to their specific methodologies. However, the power of custom coding comes with significant risks. A single syntax error or a flaw in logic can lead to misleading backtests and substantial financial losses. Therefore, the concept of "AFL code verified" is not merely a technical formality; it is a critical step in ensuring the reliability, accuracy, and safety of an automated trading system. By following this guide, your AFL code will

The Technical Definition of Verification

In the context of Amibroker, "code verified" refers to a dual-layered process. The first layer is syntax verification. This is the basic check performed by the Amibroker editor to ensure the code adheres to the grammatical rules of the programming language. It checks for missing semicolons, undeclared variables, mismatched parentheses, and spelling errors in function names. When a user clicks the "Verify" button or presses the designated shortcut, the Amibroker engine scans the script. If the code is verified successfully, no errors are reported, and the formula is ready for use. If verification fails, the user receives a specific error message and line number, preventing the flawed code from executing.

The Logical Necessity of Verification

While syntax verification ensures the code can run, the second layer—logical verification—ensures the code runs correctly. A script can be syntactically perfect yet logically disastrous. For example, a trader might write a moving average crossover strategy. Syntactically, the code may be valid, but if the logic mistakenly enters a trade on the closing of the signal bar rather than the opening of the next bar, the backtest results will be skewed by "peeking" at future data. Logical verification involves rigorous backtesting, walk-forward analysis, and visual inspection of charts to ensure the signals generated by the AFL code align with the trader's intent. A truly "verified" code is one that has passed both the compiler’s syntax check and the trader’s stress tests.

Avoiding the Trap of Curve Fitting

One of the greatest dangers in writing custom AFL is "curve fitting" or "over-optimization." This occurs when a trader tweaks code parameters to perfectly match historical data, creating a strategy that looks excellent in backtesting but fails in live markets. The verification process serves as a gatekeeper against this. By adhering to strict verification protocols, such as out-of-sample testing, a trader can validate that the code is robust. A verified code does not just replicate past price movements; it captures a genuine market inefficiency. Without this disciplined approach, a trader may deploy a strategy that is mathematically perfect but financially ruinous.

Security and Community Trust

Beyond personal use, the concept of verified code is vital in the trading community. Many traders purchase or download free AFL codes from third-party vendors and forums. In this context, "verified" takes on a security dimension. Unverified code from external sources can contain malicious elements, "Trojan horse" logic designed to manipulate trades, or simply poor coding that crashes the platform. Reputable vendors often provide verified backtest reports and open-source logic to prove the integrity of their products. For the end-user, verifying third-party code—by reading through the logic and checking for red flags—protects both their capital and their data privacy.

Conclusion

The transition from a trading idea to an executable algorithm is a journey fraught with potential pitfalls. Amibroker’s AFL provides the tools to traverse this landscape, but it requires diligence to navigate safely. "AFL code verified" is more than a status message in a dialogue box; it is a certification of quality. It represents the difference between a reckless gamble based on faulty code and a calculated investment based on rigorous analysis. Whether through syntax checks, logical backtesting, or security reviews, the verification process is the indispensable foundation of successful algorithmic trading. In the high-stakes environment of the financial markets, trust is the most valuable currency, and it is earned only through verified, error-free code. If this red line deviates significantly from your

Add this line to the end of your AFL:

Plot(Equity(1), "Recalculated Equity", colorRed, styleOwnScale);

If this red line deviates significantly from your backtest equity, your code is leaking future information.

// Verified: next bar open after signal
Buy = condition;
BuyPrice = Open; // But this assumes signal at bar close, fill next open. Good.
// Verified: limit order on same bar (if allowed)
Buy = condition;
BuyPrice = ValueWhen( condition, Close, 1 ); // More realistic for intraday?

Even if code verifies, it must be readable.

Before trusting numbers, verify that your signals appear where you expect them to.

Plot key intermediate variables:

Plot(Close, "Close", colorBlack, styleCandle);
Plot(mySignalLine, "Signal", colorRed, styleLine);
Plot(myBuyCond, "Buy Cond", colorGreen, styleOwnScale);

Manually inspect 10–20 bars to see if conditions trigger at plausible points.

Search for these patterns:

AFL check snippet:

// Verified: No look-ahead
Buy = Cross( MACD(), Signal() ); // OK, uses current bar only
// NOT verified (look-ahead)
Buy = Ref( Cross( MACD(), Signal() ), -1 ); // Signals based on NEXT bar? Wait: Ref(..., -1) is past? No: Ref(array, -1) is PREVIOUS bar. Ref(..., +1) is future. Be careful.