The code below is an little bit more complex example of Low Level Graphics functions (see http://www.amibroker.com/guide/a_lowlevelgfx.html)

It allows to display three kinds of charts:

1. yearly/monthly profit table
2. yearly profit bar chart
3. average monthly profit bar chart

The type of chart is switchable from Parameters dialog.

It should be applied to ~~~EQUITY – portfolio equity symbol (so it only produces output if you run backtest before using it).

SetBarsRequired(1000000,1000000);
eq = Foreign("~~~EQUITY", "C" );

yr = Year();
mo = Month();

YearChange = yr != Ref( yr, -1 );
MonChange = mo != Ref( mo, -1 );

FirstYr = 0;
LastYr = 0;

startbar = 0;

////////////////////////////
// SKIP non-trading bars
////////////////////////////
for( i = 0; i < BarCount; i++ )
{
  if( eq[ i ] )
  {
    startbar = i;
    break;
  } 
}

////////////////////////////
// collect yearly / monthly changes in equity
// into dynamic variables
////////////////////////////

LastYrValue = eq[ startbar  ];
LastMoValue = eq[ startbar  ];

MaxYrProfit = MinYrProfit = 0;
MaxMoProfit = MinMoProfit = 0;

for( i = startbar + 1; i < BarCount; i++ )
{
  if( YearChange[ i ] || i == BarCount - 1 )
  {
    Chg = 100 * ( -1 + eq[ i ] / LastYrValue );
    VarSet("ChgYear"+ yr[ i - 1 ], Chg );

    MaxYrProfit = Max( MaxYrProfit, Chg );
    MinYrProfit = Min( MinYrProfit, Chg );

    if( FirstYr == 0 ) FirstYr = yr[ i - 1 ];
    LastYr = yr[ i ];

    LastYrValue = eq[ i ];
  }

  if( MonChange [ i ] || i == BarCount - 1 )
  {
    mon = mo[ i - 1 ];

    Chg = 100 * ( -1 + eq[ i ] / LastMoValue );

    VarSet("ChgMon" + yr[ i - 1 ] + "-" + mon, Chg );
    VarSet("SumChgMon"+ mon, Chg + Nz( VarGet("SumChgMon"+ mon ) ) );
    VarSet("SumMon" + mon, 1 + Nz( VarGet("SumMon"+ mon ) ) );
 
    MaxMoProfit = Max( MaxMoProfit, Chg );
    MinMoProfit = Min( MinMoProfit, Chg );

    LastMoValue = eq[ i ];
  }
}

/////////////////////////////////////////////////
// Drawing code & helper functions
////////////////////////////////////////////////

GfxSetOverlayMode( 2 );

CellHeight = (Status("pxheight")-1)/(LastYr - FirstYr + 3 ); 
CellWidth = (Status("pxwidth")-1)/14; 
GfxSelectFont( "Tahoma", 8.5 ); 

GfxSetBkMode( 1 );

function PrintInCell( string, row, Col ) 
{
 Color =  ColorRGB( IIf( row == 0 || col == 0 || col == 13, 220, 255 ), 255, IIf( row % 2, 255, 220 ) );
 GfxSelectSolidBrush( Color   );
 GfxRectangle( Col * CellWidth, 
                    row * CellHeight, (Col + 1 ) * CellWidth + 1, 
                    (row + 1 ) * CellHeight  + 1); 
 GfxDrawText( string, Col * CellWidth + 1, 
                    row * CellHeight + 1, 
                    (Col + 1 ) * CellWidth, (row + 1 ) * CellHeight, 32+5 ); 
} 

YOffset = 25;
XOffset = 15;

function DrawBar( text, bar, numbars, y, Miny, Maxy )
{
 BarWidth = (Status("pxwidth") - 4 * XOffset )/( numbars + 1 ); 
 BarHeight = Status("pxheight") - 2 * YOffset;
 relpos = ( y - Miny ) / (Maxy - Miny );

 xp = XOffset + ( bar + 0.5 ) * BarWidth;
 yp = YOffset + BarHeight * ( 1 - relpos );
 xe = XOffset + ( bar + 1 ) * BarWidth;
 ye = YOffset + BarHeight * ( 1 - ( -miny )/( maxy - miny ) );
  
 if( y > 0 )
 {
 GfxGradientRect( xp, yp, 
                  xe , ye,
                  ColorHSB( 70, 255 * relpos, 255 ), ColorHSB( 70, 20, 255 ) ); 
 }
 else
 {
 GfxGradientRect( xp, ye, 
                  xe , yp,
                  ColorHSB( 0, 20, 255 ), ColorHSB( 0, 255 * ( 1 - relpos ), 255 ) ); 
 }
 GfxTextOut( text, xp, ye );
 GfxTextOut( StrFormat("%.2f", y ), xp, yp );
}    

function DrawLevels( Miny, Maxy )
{
  range = Maxy - Miny;

  grid = 100;
  if( range < 10 ) grid = 1;
  else 
  if( range < 20 ) grid = 2;
  else 
  if( range < 50 ) grid = 5;
  else 
  if( range < 100 ) grid = 10;
  else 
  if( range < 200 ) grid = 20;
  else 
  if( range < 500 ) grid = 50;

  _TRACE("grid = "+grid +" range "+range );
  
  width = Status("pxwidth") - 4 * XOffset;
  height = Status("pxheight") - 2 * YOffset;

  GfxSelectPen( colorBlack, 1, 2 );
  for( y = grid * ceil( Miny / grid ); y <= grid * floor( Maxy / grid ); y += grid )
  {
    yp =  YOffset + Height * ( 1 -  ( y - Miny ) / (Maxy - Miny ) );

    GfxMoveTo( XOffset, yp );
    GfxLineTo( XOffset + width , yp );
    GfxTextOut( ""+ y, XOffset + 2 + width, yp );
  }

  GfxSelectPen( colorBlack, 1, 0 );
  GfxMoveTo( XOffset, YOffset );
  GfxLineTo( XOffset + width, YOffset );
  GfxLineTo( XOffset + width, YOffset + Height );
  GfxLineTo( XOffset , YOffset + Height );
  GfxLineTo( XOffset , YOffset );
}

MonthNames = "Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec";

function DisplayProfitTable( )
{
 Header = "Year,"+MonthNames+",Yr Profit%";
 for( Col = 0; (Colname = StrExtract( Header, Col ) ) != ""; Col++ )
 {
  PrintInCell( ColName, 0, Col );
 }

 Row = 1;
 for( y = FirstYr; y <= LastYr; y++ )
 {
  PrintInCell( StrFormat("%g", y ), Row, 0 ); 
  PrintInCell( StrFormat("%.1f%%", VarGet("ChgYear" + y ) ), Row, 13 ); 
  for( m = 1; m <= 12; m++ )
  { 
   Chg = VarGet("ChgMon" + y + "-" + m);
   if( Chg ) 
     PrintInCell( StrFormat("%.1f%%", Chg ), Row, m );
   else
     PrintInCell( "N/A", Row, m );
  }
  Row++;
 } 

 PrintInCell("Mon. Avg", Row, 0 );
 for( m = 1; m <= 12; m++ )
 { 
   PrintInCell( StrFormat("%.1f%%",  Nz( VarGet("SumChgMon" + m)/VarGet("SumMon" + m ) ) ), Row, m );
 }

}

function DisplayYearlyProfits()
{
 Bar = 0;
 for( y = FirstYr; y <= LastYr; y++ )
 {
   Chg = VarGet("ChgYear" + y );
   DrawBar( ""+y, Bar++, ( LastYr - FirstYr + 1 ), Chg, MinYrProfit, MaxYrProfit );
 }
 GfxTextOut("Yearly % Profit chart", 10, 10 );

 DrawLevels( MinYrProfit, MaxYrProfit ); 
}

function DisplayMonthlyProfits()
{
 Bar = 0;
 
 MinAvgProf = MaxAvgProf = 0;
 for( y = 1; y <= 12; y++ )
 {
   Chg = VarGet("SumChgMon" + y ) / VarGet("SumMon" + y );
   MinAvgProf = Min( MinAvgProf, Chg );
   MaxAvgProf = Max( MaxAvgProf, Chg );
 }

 for( y = 1; y <= 12; y++ )
 {
   Chg = VarGet("SumChgMon" + y ) / VarGet("SumMon" + y );
   DrawBar( StrExtract(MonthNames, y-1 ), Bar++, 13, Chg, MinAvgProf , MaxAvgProf );
 }
 GfxTextOut("Avg. Monthly % Profit chart", 10, 10 );

 DrawLevels( MinAvgProf , MaxAvgProf ); 
}

///////////////////////////
// This function checks if currently selected symbol
// is portfolio equity
//////////////////////////
function CheckSymbol()
{
 if( Name() != "~~~EQUITY" )
 {
  GfxSelectFont( "Tahoma", 20 ); 
  GfxSetBkMode( 2 );
  GfxTextOut("For accurate results switch to ~~~EQUITY symbol", 10, 10 );
 }
}

////////////////////////////
// Main program - chart type switch
////////////////////////////
type = ParamList("Chart Type", "Profit Table|Yearly Profits|Avg. Monthly Profits", 0 );

switch( type )
{
 case "Profit Table": 
         DisplayProfitTable();  
         break;
 case "Yearly Profits": 
         DisplayYearlyProfits();
         break;
 case "Avg. Monthly Profits": 
         DisplayMonthlyProfits();
         break;
}

CheckSymbol();

Figure 1. Profit chart in table mode

Figure 2. Profit chart in yearly mode

Figure 3. Profit chart in monthly mode

Recently released AmiBroker 5.05 BETA features the automatic Walk-Forward Optimization mode.

The automatic Walk forward optimization is a system design and validation technique in which you optimize the parameter values on a past segment of market data (“in-sample”), then test the system forward in time on data following the optimization segment (“out-of-sample”). You evaluate the system based on how well it performs on the test data (“out-of-sample”), not the data it was optimized on.

To use Walk-Forward optimization please follow these steps:

1. Goto Tools->Automatic Analysis
2. Click Settings button, then switch to “Walk-Forward tab”
3. Here you can see Walk forward settings for In-sample optimization, out-of-sample backtest
   “Start” and “End” dates mark initial period begin / end
   This period will be moved forward by “Step” until the “End” reaches the “Last” date.
   The “Start” date can move forward by “step” too, or can be anchored (constant) if “Anchored” check is on.
   If you mark “Use today” then “Last” date entered will be ignored and TODAY (current date) will be used instead

   By default an “EASY MODE” is selected which simplifies the process of setting up WF parameters.
   It assumes that:
   a) Out-of-sample segment immediatelly follows in-sample segment
   b) the length of out-of-sample segment equals to the walk-forward step

   Based on these two assumptions the “EASY” mode takes in-sample END date and sets
   out-of-sample START date to the following day. Then adds in-sample STEP and this becomes out-of-sample END date.
   In-sample and Out-of-sample step values are set to the same values.

   The “EASY” mode guarantees correctness of WF procedure settings.

   In the “ADVANCED” mode, the user has complete control over all values, to the extent that
   they may not constitute valid WF procedure.
   The interface allows to selectivelly disable in-sample and out-of-sample phases using checkboxes at top
   (for special things like runnign sequential backtests without optimization).

   All settings are immediatelly reflected in the PREVIEW list that shows all generated IS/OOS segments and their dates.

   The “Optimization target” field defines the optimization raport COLUMN NAME that
   will be used for sorting results and finding the BEST one. Any built-in column can be used
   (as appears in the optimization output), or you can use any custom metric that you define
   in custom backtester. The default is CAR/MDD, you can however select any other built-in metric from the combo.
   You can also TYPE-IN any custom metric that you have added via custom backtester interface.

4. Once you defined Walk-Forward settings, please go to Automatic Analysis and
5. press the dropdown ARROW on the Optimize button and select “Walk Forward Optimization”

This will run sequence of optimizaitons and backtest and the results will be displayed in the “Walk Forward” document that is open in the main application frame.
When optimization is running you can click “MINIMIZE” button on the Progress dialog to minimize it – this allows to see the Walk Forward output during the optimization steps.

IN-SAMPLE and OUT-OF-SAMPLE combined equity

Combined in-sample and out-sample equities are available by
~~~ISEQUITY and ~~~OSEQUITY composite tickers (consecutive periods of IS and OOS are concatenated and scaled to
maintain continuity of equity line – this approach assumes that you generally speaking are compounding profits)
To display IS and OOS equity you may use for example this:

PlotForeign("~~~ISEQUITY","In-Sample Equity", colorRed, styleLine); 
PlotForeign("~~~OSEQUITY","Out-Of-Sample Equity", colorGreen, styleLine); 
Title = "{{NAME}} - {{INTERVAL}} {{DATE}} {{VALUES}}"; 

Recently I heard the suggestion to add a security symbol written in big letters in the chart background. Well, actually it is pretty simple to do using low-level gfx. Just add this code sniplet anywhere in your chart formula.

GfxSetOverlayMode(1);
GfxSelectFont("Tahoma", Status("pxheight")/2 );
GfxSetTextAlign( 6 );// center alignment
GfxSetTextColor( ColorRGB( 200, 200, 200 ) );
GfxSetBkMode(1); // transparent
GfxTextOut( Name(), Status("pxwidth")/2, Status("pxheight")/12 );

UPDATE: I have added transparent mode, so it works fine on non-white backgrounds too.

Recently on the AmiBroker mailing list some users expressed wish to have access to some of portfolio backtest metrics available in “historical” form (i.e. as date series, as opposed to scalars), so they can be plotted as an indicator.

Implementing such functionality is actually easy with existing tools and does not require any OLE scripts. Everything you need is small custom-backtester procedure that just reads built-in stats every bar and puts them into composite ticker.
In the accompanying indicator code all you need to do is simply use Foreign() function to access the historical metrics data generated during backtest.

The code below shows the BACKTEST formula with custom backtester part:

// Replace lines below with YOUR TRADING SYSTEM
EnableRotationalTrading(); 
PositionScore = 1/RSI(14); 
PositionSize = -25;
SetOption("WorstRankHeld", 7 );
SetOption("MaxOpenPositions", 4 ); 

////////////////////////////////////////
// BELOW IS ACTUAL CUSTOM BACKTESTER PART
// that can read any built-in metric (in this example UlcerIndex)
// and store it into composite ticker for further
// retrieval as data series

SetOption("UseCustomBacktestProc", True ); 

if( Status("action") == actionPortfolio )
{
  bo = GetBacktesterObject();
 
  bo.PreProcess(); // Initialize backtester
 
  // initialize with null 
  // you can have as many historical metrics as you want 
  // (just duplicate line below for many metrics you want)
  MyHistStat1 = Null; 
  MyHistStat2 = Null; // add your own 

  for(bar=0; bar < BarCount; bar++)
  {
   bo.ProcessTradeSignals( bar );
  
   // recalculate built-in stats on EACH BAR
   stats = bo.GetPerformanceStats( 0 ); 
 
   // the line below reads the metric and stores it as array element
   // you can add many lines for each metric of your choice
   MyHistStat1[ bar ] = stats.GetValue("UlcerIndex"); // get ulcer index value calculated this bar
   MyHistStat2[ bar ] = stats.GetValue("WinnersPercent"); // add your own

  }

  bo.PostProcess(); // Finalize backtester

  // now STORE the historical data series representing the metric of your choice
  // duplicate the line below for as many metrics as you want
  AddToComposite( MyHistStat1, "~~~UI_HISTORICAL", "X", atcFlagEnableInPortfolio | atcFlagDefaults );

  // you can add your own as shown below
  AddToComposite( MyHistStat2, "~~~WP_HISTORICAL", "X", atcFlagEnableInPortfolio | atcFlagDefaults ); 
}

In the code above, for illustration purposes, we are exporting UlcerIndex and Winners Percent metrics as data series. They are stored in composite tickers for easy retrieval from indicator level.
You can easily extend code to include ANY number of metrics you want.

Now in order to Plot metrics as indicators, use this simple formula:

PlotForeign("~~~UI_HISTORICAL", "UlcerIndex Historical", colorRed, styleLine );
PlotForeign("~~~WP_HISTORICAL", "Winners Percent", colorBlue, styleLine | styleOwnScale );


As you can see with one Foreign function call you can read the historical value of any metric generated by the backtester.

NOTE: when running backtest please setup a filter in AA that EXCLUDES composites (group 253) from backtest set.

QuickAFL(tm) is a feature that allows faster AFL calculation under certain conditions. Initially (since 2003) it was available for indicators only, as of version 5.14+ it is available in Automatic Analysis too.

Initially the idea was to allow faster chart redraws through calculating AFL formula only for that part which is visible on the chart. In a similar manner, automatic analysis window can use subset of available quotations to calculate AFL, if selected “range” parameter is less than “All quotations”.

So, in short QuickAFL works so it calculates only part of the array that is currently visible (indicator) or within selected range (Automatic Analysis).

Your formulas, under QuickAFL, may or may NOT use all data bars available, but only visible (or “in-range”) bars (plus some extra to ensure calculation of used indicators), so when you are using Close[ 0 ] it represents not first bar in entire data set but first bar in array currently used (which is just a bit longer than visible, or ‘in-range’ area).

The QuickAFL is designed to be transparent, i.e. do not require any changes to the formulas you are using. To achieve this goal, AmiBroker in the first execution of given formula “learns” how many bars are really needed to calculate it correctly.

To find out the number of bars required to calculate formula AmiBroker internally uses two variables ‘backward ref’ and ‘forward ref’.

‘backward ref’ describes how many PREVIOUS bars are needed to calculate the value for today, and ‘forward ref’ tells how many FUTURE bars are needed to calculate value for today.

If these numbers are known, during execution of given formula AmiBroker takes FIRST visible (or in-range) bar and subtracts ‘backward ref” and takes LAST visible (or in-range) bar and adds ‘forward ref’ to calculate first and last bar needed for calculation of the formula.

Now, how does AmiBroker know a correct “backward ref” and “forward ref” for the entire formula?
Well, every AmiBroker’s built-in function is written so that it knows its own requirements and adds them to global “backward ref” and “forward ref” each time given function is called from your formula.

The whole process starts with setting initial BackwardRef to 30 and ForwardRef to zero. These initial values are used to give “safety margin” for simple loops/scripts.

Next, when parser scans the formula like this:

Buy = C > Ref ( MA( C, 40 ), -1 );

it analyses it and “sees” the MA with parameter 40. It knows that simple moving average of period 40 requires 40 past bars and zero future bars to calculate correctly so it does the following (all internally):

BackwardRef = BackwardRef + 40;
ForwardRef = ForwardRef + 0;

So now, the value of BackwardRef will be 70 (40+30(initial)), and ForwardRef will be zero.

Next the parser sees Ref( .., -1 );

It knows that Ref with shift of -1 requires 1 past bar and zero future bars so it “accumulates” requirements this way:

BackwardRef = BackwardRef + 1;
ForwardRef = ForwardRef + 0;

So it ends up with:

BackwardRef = 71;
ForwardRef = 0;

The BackwardRef and ForwardRef numbers are displayed by AFL Editor’s Tools->Check and Profile as well as on charts when “Display chart timing” is selected in the preferences.

If you use Check and Profile tool, it will tell you that the formula

Buy = C > Ref ( MA( C, 40 ), -1 );

requires 71 past bars and 0 future bars.

You can modify it to

Buy = C > Ref ( MA( C, 50 ), -2 );

and it will tell you that it requires 82 past bars (30+50+2) and zero future bars.

If you modify it to

Buy = C > Ref ( MA( C, 50 ), 1 );

It will tell you that it needs 80 past bars (30+50) and ONE future bar (from Ref).

Thanks to that your formula will use 80 bars prior to first visible (or in-range) bar leading to correct calculation result, while improving the speed of execution by not using bars preceding required ones.

IMPORTANT NOTES

It is very important to understand, that the above estimate requirements while fairly conservative,
and working fine in majority of cases, may NOT give you identical results with QuickAFL enabled, if your formulas use:
a) JScript/VBScript scripting
b) for/while/do loops using more than 30 past bars
c) any functions from external indicator DLLs
d) certain functions that use recursive calculation such as very long exponential averages or TimeFrame functions with much higher intervals than base interval

In these cases, you may need to use SetBarsRequired() function to set initial requirements to value higher than default 30. For example, by placing

SetBarsRequired( 1000, 0 );

at the TOP of your formula you are telling AmiBroker to add 1000 bars PRIOR to first visible (or in-range) bar to ensure more data to stabilise indicators.

You can also effectively turn OFF QuickAFL by adding:

SetBarsRequired( sbrAll, sbrAll );

at the top of your formula. It tells AmiBroker to use ALL bars all the time.

It is also worth noting that certain functions like cumulative sum (Cum()) by default request ALL past bars to guarantee the same results when QuickAFL is enabled. But when using such a function, you may or may NOT want to use all bars. So SetBarsRequired() gives you also ability to DECREASE the requirements of formula. This is done by placing SetBarsRequired at the END of your formula, as any call to SetBarsRequired effectively overwrites previously calculated estimate. So
if you write

x = Cum( 1 );
SetBarsRequired( 1000, 0 ); // use 1000 past bars DESPITE using Cum()

You may force AmiBroker to use only 1000 bars prior first visible even though Cum() by itself would require all bars.

It is also worth noting that when QuickAFL is used, BarIndex() function does NOT represent elements of the AFL array, but rather the indexes of ENTIRE quotation array. With QuickAFL turned on, an AFL array is usually shorter than quotation array, as illustrated in this picture:

SPECIAL CASE: AddToComposite function

Since AddToComposite creates artificial stock data it is desirable that it works the same regardless of how many ‘visible’ bars there are or how many bars are needed by other parts of the formula.

For this reason internally AddToComposite does this:

SetBarsRequired( sbrAll, sbrAll );

which effectivelly means “use all available bars” for the formula. AddToComposite function simply tells the AFL engine to use all available bars (from the very first to the very last) regardless of how formula looks like. This is to ensure that AddToComposite updates ALL bars of the composite

The side-effect is that “Check And Profile” feature will see that it needs to reference future bars and display a warning even though this is false alert because AddToComposite itself has no impact on trading system at all.

Now why this shows only when flag atcFlagEnableInBacktest is on ??
It is simple: this is so because it means that AddToComposite is ACTIVE in BACKTEST.
http://www.amibroker.com/guide/afl/afl_view.php?name=ADDTOCOMPOSITE

Since “Check And Profile” uses “BACKTEST” state you get such result.

If atcFlagEnableInBacktest is not specified AddToComposite is not enabled in Backtest and hence does not affect calculation of BackwardRef and ForwardRef during “Check And Profile”.

BACKWARD COMPATIBILITY NOTES

a) QuickAFL is available in Automatic Analysis in version 5.14.0 or higher
b) sbrAll constant is available in Automatic Analysis in version 5.14.0 or higher. If you are using older versions you should use numeric constant of: 1000000 instead.

AmiBroker Formula Language (AFL) thanks to its array processing model is able to run at the same speed as code written in assembler (i.e. machine code). The following article explains how.

AFL runs with native assembly speed when using array operations.
A simple array multiplication like this:

X = Close  * H; // array multiplication (each array element is multiplied)

gets compiled by AmiBroker to just 8 assembly instructions:

loop: mov         edx,dword ptr [esp+58h]
      inc         esi                       ; increase counters
      add         eax,4
      cmp         esi,edi
      fld         dword ptr [edx+esi*4-4]   ; get element of close array
      fmul        dword ptr [eax+ecx-4]     ; multiply by element of high array
      fstp        dword ptr [eax-4]         ; store result
      jl          loop                      ; continue until all elements are processed

As you can see there are three 4 byte memory accesses per loop iteration (2 reads each 4 bytes long and 1 write 4 byte long)

With such tight loop, single processor core running an AFL formula is able to saturate memory bandwidth in majority of most common operations/functions if total array sizes used in given formula exceedes DATA cache size.

On my (2 year old) 2GHz Athlon x2 64 single iteration of this loop takes 6 nanoseconds (see benchmark code below). 6 nanoseconds to process one bar of data, or 166 million bars per second. So, during 6 nanoseconds we have 8 byte reads and 4 byte store. Thats (8/(6e-9)) bytes per second = 1333 MB per second read and 667 MB per second write simultaneously i.e. 2GB/sec combined !

Now if you look at memory benchmarks you will see that 2GB/s is the limit of system memory speed on Athlon x64 (DDR2 dual channel)
And that’s considering the fact that Athlon has superior-to-intel on-die integrated memory controller (hypertransfer)

// benchmark code
// for accurrate results run it on LARGE arrays -
// intraday database, 1-minute interval, 50K bars or more)
GetPerformanceCounter(1); 
for(k = 0; k < 1000; k++ )  X = C * H; 
"Time per single iteration [s]="+1e-3*GetPerformanceCounter()/(1000*BarCount); 

Only really complex operations that use *lots* of FPU (floating point) cycles such as trigonometric (sin/cos/tan) functions are slow enough for the memory to keep up.

Sometimes when using low-level graphics functions it is needed to convert from bar number to pixel X co-ordinate and from price level to pixel Y co-ordinate. Converting between them needs knowing visible bar range, Y-axis value range and pixel dimensions of drawing area. Once these params are known it is just a matter of performing simple scale transformation. The code example below shows how to do that.

function GetVisibleBarCount() 
{ 
 lvb = Status("lastvisiblebar"); 
 fvb = Status("firstvisiblebar"); 

 return Min( Lvb - fvb, BarCount - fvb ); 
} 

function GfxConvertBarToPixelX( bar ) 
{ 
 lvb = Status("lastvisiblebar"); 
 fvb = Status("firstvisiblebar"); 
 pxchartleft = Status("pxchartleft"); 
 pxchartwidth = Status("pxchartwidth"); 

 return pxchartleft + bar  * pxchartwidth / ( Lvb - fvb + 1 ); 
} 

function GfxConvertValueToPixelY( Value ) 
{ 
 local Miny, Maxy, pxchartbottom, pxchartheight; 

 Miny = Status("axisminy"); 
 Maxy = Status("axismaxy"); 

 pxchartbottom = Status("pxchartbottom"); 
 pxchartheight = Status("pxchartheight"); 

 return pxchartbottom - floor( 0.5 + ( Value - Miny ) * pxchartheight/ ( Maxy - Miny ) ); 
} 

Plot(C, "Price", colorBlack, styleHistogram ); 

GfxSetOverlayMode(0); 
GfxSelectSolidBrush( colorRed ); 
GfxSelectPen( colorRed ); 

AllVisibleBars = GetVisibleBarCount(); 
fvb = Status("firstvisiblebar"); 

for( i = 0; i < AllVisibleBars ; i++ ) 
{ 
  x = GfxConvertBarToPixelX( i ); 
  y = GfxConvertValueToPixelY( C[ i + fvb ] ); 

  GfxRectangle( x-1, y-1, x + 2, y+1 ); 
} 

RequestTimedRefresh(1); // ensure 1 sec refresh

Note that when chart scale changes, it will usually require one extra refresh to get low-level graphics alignment to new scale. That’s why we added RequestTimedRefresh call at the end.

IMPORTANT: This article applies ONLY to AmiBroker version 5.24 and earlier. Version 5.25 includes native support for log scale in Study() function and this workaround is no longer needed.

Some of you may have tried using Study() function in logarithmic scale charts and noticed that the output of Study() function becomes curved line (not straight) as soon as logarithmic scale is used.

Before giving you solution, I would like to state some obvious things:
A straight line in log scale is NOT straight line in linear scale and vice versa. Trendlines drawn in log scale do NOT cross at the same points (except beginning and ending) as same trendline drawn in linear scale. This is pretty much the same in all charting programs.

As for the Study() function – it always uses LINEAR equation y = a*x + b regardless of particular chart scale. So, Study() always produces straight line in the linear price domain, so “a” coefficient is constant and represents the slope in price terms (dollar per bar)

This is done so, because Automatic Analysis does not have a concept of “scale” (linear vs logarithmic), therefore if Study() function was dependent on given pane setting it would not produce the same result, if the same formula was used in automatic analysis.

If you want to have “straight” line in the logarithmic price domain you need to convert to log domain in the formula, as shown in the code below


function StudyInLogScale( Studyid, Chartid )
{
  if( Version() < 5.25 )
  {
   SetBarsRequired( sbrAll, sbrAll );

   temp = Study( Studyid, Chartid );

   bi = BarIndex();

   beg = LastValue( ValueWhen( ExRem( temp, 0 ), bi ) ); 
   end = LastValue( ValueWhen( temp, bi ) );

   result = Null;
 
   if( beg < BarCount AND end < BarCount )
   {
    begval = temp[ beg ];
    endval = temp[ end ];
    factor = endval/begval;

    for( i = beg; i <= end; i++ )
    {
      result[ i ] = begval * factor ^ ( ( i - beg )/( end - beg ) ); 
    }
   }
  }
  else
  {
    result = Study( Studyid, Chartid );
  }

  return result;        
}

logscale = ParamToggle("Log Scale", "Off|On", 0 );

SetChartOptions( IIf( logScale, 2, 3 ), chartLogarithmic );

Plot( C, "Price", colorBlack, styleCandle );

if( logscale AND Version() <= 5.24 )
{
 ss = StudyInLogScale("RE", GetChartID() );
}
else
{
 ss = Study("RE", GetChartID() );
}

Plot( ss, "Study", colorRed );

In general, to represent numbers with fractional parts, computers use a “floating point” binary representation. Floating point arithmetic is also used by AmiBroker for AFL calculations. For some more information about floating point representation in general see the following article, here we will only discuss some practical aspects.

http://en.wikipedia.org/wiki/Floating_point

Floating point calculations are performed in hardware by FPU (Floating Point Unit), which today is a part of your computer’s processor (CPU). The calculations are performed according to IEEE754 standard (see below) that all CPU manufacturers follow.

Internally in computers all numbers are represented in binary system.
This fact has some important consequences in practice. One of it is that some fractions that have finite representation in decimal system are not finite in binary.

For example, 0.1 is endless (infinite) fraction in binary system, as 1/3 or 2/3 fractions are in decimal system.

The mantissa of 0.1 fraction in binary system is cyclical:
1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 (1001)* …….

* represents endless cycle.

Since computers operate on limited word length, 32 bit binary representation of 0.1 is:
01111011 10011001100110011001100 (not rounded) (in decimal it is 0.09999999403953552)
or
01111011 10011001100110011001101 (rounded) (in decimal it is 0.10000000149011612)

Later is used by FPU (floating point processor) in your CPU because it has smaller relative error. If you add it nine times you will end up with 0.9000000134110449 which is of course higher than 0.9.

It will be easier for you to understand when explaining on decimal numbers. For example 2/3 represented in decimal is:
0.666666667

Now add THREE times this number (0.666666667 + 0.666666667 + 0.666666667) and what you will get?
2.000000001 and that is greater than 2.

Therefore, it is rule in programming, NEVER use fractions for loop counters. For that reason you should not use fractions in Optimize(), or if you need to use them use them in WISE way by adding HALF of “step” value to the “max” value.

step = 0.1;
x = Optimize(“x”, 0.5, 0.1, 0.9 + step/2, step);

Another thing to keep in mind is that 32-bit floating point number has only 7 significant digits (those digits that carry meaning contributing to its precision). So in 123.4567 all digits are significant and accurate, but in 123.456789, last two digits (’8′ and ’9′) are not significant and subject to floating point rounding – see links below).

See also:
About significant figures:
http://en.wikipedia.org/wiki/Significant_figures

IEEE754 conversion calculators:
http://babbage.cs.qc.edu/IEEE-754/Decimal.html
http://babbage.cs.qc.edu/IEEE-754/32bit.html

IEEE754 standard description:
http://en.wikipedia.org/wiki/IEEE_754-1985

Essay about comparing floatin point numbers:
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Microsoft Knowledge Base: “Precision and Accuracy in Floating-Point Calculations”
http://support.microsoft.com/kb/125056

Using 32-bit floating point (as opposed to 64-bit double precision) has two main advantages:
a) consumes HALF of memory required for doubles (this *is* important, more important that you think, because if you have for example an array of 500000 elements, in floats it is 2MB and it fits into CPU cache, while in doubles it would be 4MB and may not fit into CPU cache).
b) 32-bit floating point numbers can be computed much faster. It simply takes less processor cycles to compute 32-bit float than 64-bit float. 64-bit version of AmiBroker is going even further and is using SSE2 instructions. This means that vectors of 4 single-precision numbers are processed in parallel using single SSE2 instruction on SINGLE processor. This gives more speed on single core than achievable using multiple cores.

Note also AmiBroker does use double precision (64bit) where it is necessary (for certain internal calculations)

All developers of 3rd party plugin should NOT change the default project settings that are provided in sample projects in the ADK. If you change anything, you must make sure that you are using multi-threaded C runtime library as shown below:

It is absolutely essential to check this setting, as the default for Visual C++ 6.0 static links is to use single-threaded version. Also you should avoid static linking to C runtime. It only makes your DLL bigger and unsafe (because security fixes applied by Windows update can’t fix statically linked programs).

So, once again you absolutely need to make sure that your plugins use “Multithreaded DLL” run-time library.

Failure to do so results in bizarre crashes, mainly occurring in OS Kernel at InterlockedDecrement or at RtlInterlockedFlushSList calls.

Note that this applies NOT ONLY to multi-threaded editions of AmiBroker but to ALL editions, since you must not mix run time libraries within single application.

Note also that most recent editions of Visual C++ compilers (2005 and 2010) do not allow to choose single-threaded runtime anymore.

Some users coming from Metastock ask for “points-only” test.

One needs to know that AmiBroker features way more sophisticated futures mode than MS ever had: http://www.amibroker.com/guide/h_futbacktest.html
It provides full support for futures trading, handling margin deposit, point value, etc.

“Points-only” test is kind of the simplest possible case, but if you want to do just that, it can be implemented using these two lines:

SetOption("FuturesMode", True );
SetPostionSize( 1, spsShares ); // trade just 1 contract

That is all what you need to add to your formula to get point-only test.

Zig-zag indicator, as well as other functions using it (Peak/Trough, PeakBars, Troughbars), inherently look into the future. As such they should not be used in trading system formulas without taking precautions. The only way to fix the ‘problem’ is to delay the signal as long as it takes for zig/zag to stabilise last ‘leg’. The delay is variable and depends how much time it takes for defined percentage change to occur in the price series since last peak/trough.

Ready-to-use solution is presented in the Traders’ Tips section of the AmiBroker members area:
http://www.amibroker.com/members/traders/11-2003.html

(NOTE: access to members’ area is limited to licensed users only, if you forgot your password use reminder at http://www.amibroker.com/login.html)

From time to time we receive questions about why you can get different results back-testing the same code.

There are five reasons for differences in backtest results:

1. Different data (for example if past history is updated/changed due to splits for example or backfill)
2. Different settings / parameters (if your formula uses Param() functions that output values that may be changed from the Parameter window)
3. Different formula (sometimes even slight change to the formula causes big change in the results, for example if your formula uses #include and included code has changed)
4. The formula that self-references its previously generated results. Such code produces some data that is later used to produce next run output (for example your code produces composites that are later used – if those composites change – the input data change so the results change, or if your formula uses previous backtest equity)
5. The formula directly or indirectly calls any function that produces random numbers such as Random or mtRandom, or functions that read external data that have changed

Some trading systems may benefit from attempt to time the broad market. A market-wide valuation, such as moving average, sentiment or some other mechanism may be used to tell if we should be in the market or not.

Flexibility of AFL language allows to create rules or indicators, which are based on more than just one symbol. This enables us to introduce additional filters based on wide-market index performance.

For the purpose of reading quotes of another symbol one can use Foreign or SetForeign functions.

The following formula shows how to generate entry signals in individual stocks when S&P500 index is above its 200-period moving average and exit signals when S&P500 is equal or below 200-period average (^GSPC is a ticker for Yahoo Finance data for S&P500)

//
// read S&P 500 values from ^GSPC ticker
//
sp500 = Foreign( "^GSPC", "C" );
//
// market-wide filter should be in "state" form 
// (so it is True all the time when market is up)
//
marketup = sp500 > MA( sp500, 200 );
marketdown = NOT marketup;
//
// sample trading rules (MACD crossovers)
//
BuySignal = Cross( MACD(), Signal() );
SellSignal = Cross( Signal(), MACD() );
//
// combine per-symbo signals with broad-market timing
//
Buy = BuySignal AND marketup; // enter trade only when buy signal AND market is in up trend
Sell = SellSignal OR marketdown; // exit position if sell signal OR market turns down

A more complex broad-market timing that requires not only closing price of market index can be implemented using SetForeign function. SetForeign replaces all OHLCV data series with that of the “other” security and allows to calculate all kind of indicators that would normally use current security. Broad market timing does not need to be just “all-in” or “all-out” switch. For example one can switch the trading method depending on whenever broad market is trending or sideways.

//
// Switch to S&P symbol to calculate broad-market timing
//
SetForeign( "^GSPC" );
//
// now we can calculate any indicator based on SP500 
//
MarketIsTrending = ADX( 40 ) > 20; // ADX (40 days) from SP500
//
// now go back to original data (current symbol)
// 
RestorePriceArrays();
//
// you can have different rules that are switched
// depending on what broad market is doing
//
TrendingBuy = Cross( C, MA( C, 30 ) );
TrendingSell = Cross( MA( C, 30 ), C );
//
SidewaysBuy = Cross( MACD(), Signal() );
SidewaysSell = Cross( Signal(), MACD() );
//
// switch methods using broad-market timing
//
Buy = IIf( MarketIsTrending, TrendingBuy, SidewaysBuy ); 
Sell = IIf( MarketIsTrending, TrendingSell, SidewaysSell ); 

In this simple example we assume that market timing signals change very infrequently so they change much less often than Trending/Sideways Buy/Sell signals are generated. If that is not the case the switching logic would need to be more complex to decide what to do when we are in the “trending” trade and market switches to sideways mode. In such situation, the code above uses SidewaysSell signal to sell the position, which may or may not be what you are after.

Another example is changing position sizing depending on broad market conditions. We can choose to be fully invested when broead market is up and only 30% invested in down market.

//
// Switch to S&P symbol to calculate broad-market timing
//
SetForeign( "^GSPC" );
//
// now we can calculate any indicator based on 
// SP500
//
MarketIsUp = C > MA( C, 200 ); // here C represents closing price of SP500
//
// now go back to origiginal data (current symbol)
// 
RestorePriceArrays();
//
// normal rules (in this example they do not chang)
//
Buy = Cross( MACD(), Signal() );
Sell = Cross( Signal(), MACD() );
//
// no more than 10 positions open at a time
//
SetOption("MaxOpenPositions", 10 );
//
// change position sizing depending on broad market conditions
// in this example we will allocate:
// 10% per position
// if broad market is up (so we can be allocated upto 100% of funds)
// 3% per position 
// if broad market is down (so we can be allocated upto 30% of funds)
// 
SetPositionSize( IIf( MarketIsUp, 10, 3 ), spsPercentOfEquity );

A typical AFL function returns one value. For example sin( x ) returns sine value of argument x. Sometimes however it is useful and/or required to return more than one value from the function.

Returning multiple values is possible only via arguments passed by reference, but trouble is that in AFL all arguments are passed by value (as in C language). Passing by value means that only value of variable is passed, not the variable itself, so original variable is not modified as shown in the example below:

function Dummy( x )
{
    x = 7; // x is treated as function-local
}
//
val = 10;
Dummy( val );
printf( "%g\n", val ); // will print 10 because 'val' is unaffected by function call

The behaviour shown above is desirable because we usually want the function to be opaque and do not interfere with what is defined outside of the function except for returning the result of the function.

But what if we actually wanted to write to variables passed as arguments? Well that is possible if we pass the names of the variables as arguments.

// This example shows how to return multiple values
// the idea is to pass the name of the variable instead of
// value
//
function fun_multiple_results( result1name, result2name )
{
  VarSet( result1name, 1 ); // setting variable using passed name
  VarSet( result2name, 2 );
  return;
}
//
// to get multiple values from a function
// we call the function passing NAMES of variables
//
a = 10;
b = 20;
printf("a = %g\n", a );
printf("b = %g\n", b );
//
fun_multiple_results( "a", "b" ); // pass the names of variables
//
printf("a = %g\n", a ); // see new values assigned to variables
printf("b = %g\n", b );

Of course we can use arguments passed by name for two-way communication – we can use them as both inputs and outputs as shown in the following example that swaps the values of arguments

function Swap( var1name, var2name )
{
    temp1 = VarGet( var1name ); // read the value from variable 
    temp2 = VarGet( var2name );
    VarSet( var1name, temp2 ); // write the value to variable
    VarSet( var2name, temp1 );
}
// Initial values
x = 5;
y = 37;
//
printf("Before swap x = %g, y = %g\n", x, y );
//
Swap( "x", "y" ); // pass names of variables
//
printf("After swap x = %g, y = %g\n", x, y );

The code above will produce output like this:

Before swap x = 5, y = 37
After swap x = 37, y = 5

So it is clear that variables were passed to the function, swapped and returned successfully.

From time to time some users face “Error 10. Subscript out of range” in their formulas. The error itself is described in the manual, but still a few words of explanation why it happens may be useful.

The error usually occurs when formula uses hard-coded number of bars in the loop statements like this:

for( i = 0; i < 300; i++ ) // MISTAKE: FIXED number of bars
{
  x = Close[ i ]; // ERROR 10. because 'i' becomes greater than BarCount
}

or like this:

for( i = BarCount - 1; i > BarCount - 300; i-- ) // MISTAKE: FIXED number of bars
{
  x = Close[ i ]; // ERROR 10. because 'i' becomes LESS than zero
}

In both cases the code will FAIL if it is run on symbol that has LESS than 300 bars (BarCount < 300). In fact it will even fail on symbol that has more than 300 bars because of two facts:

1. during AFL Editor’s Verify Syntax not more than 200 most recent bars are used
2. a chart may be zoomed in so number of visible bars may be much lower and QuickAFL kicks in (so your AFL is executed with visible bars only).

This all means that one should never make any assumptions on number of bars your formula would get, because if you do, the formula will fail.

The formula should be written so it is able to execute without errors with BarCount as small as 1 (ONE).

This is normally done by writing a ‘for’ loop in a way recommended in the manual:

for( i = 0; i < BarCount; i++ )
{
   x = Close[ i ]; // this will never produce Error 10 because i is in the range 0..BarCount-1
}

If your formula references past data, say 10-bars earlier, you should start your loop with index 10, as below:

for( i = 10; i < BarCount; i++ )
{
  x[ i ] = Close[ i ] - Close[ i - 10 ]; // both subscripts will be OK
}

What to do if your formula, for some reason, really requires fixed number of bars? Well, the answer is that you should check if you really get as many bars as you think:

if( BarCount > 300 ) // check first if you have enough bars
{
   // here we know that we have more than 300 bars
   for( i = 0; i < 300; i++ )
   {
      x = Close[ i ]; 
   }
}

When designing a trading system we often need to quickly identify which of the rules used in the code triggered the particular Buy or Sell signal. Here are some techniques that may be useful in such identification.

For the purpose of this demonstration let us use a sample formula, where the Buy signal may be triggered by one of three independent rules:

Buy1 = Cross( MACD(), Signal() );
Buy2 = Cross( Close, MA(Close, 50) );
Buy3 = Cross( RSI(), 30 );
//
Buy = buy1 OR Buy2 OR Buy3; 

To determine which of those three rules generates the entry signal, we can either visualize signals in the chart or use Exploration feature of the Analysis window.

In case a custom chart is used, we can do the following:

1. display the signal in custom chart title
2. use PlotShapes function to indicate certain buy rule
3. use PlotText to add pre-defined text labels.

The formula below shows sample implementations of these three techniques. This is actually one of many ways that can be used for coding such custom output:

Buy1 = Cross( MACD(), Signal() );
Buy2 = Cross( Close, MA(Close,50) );
Buy3 = Cross( RSI(), 30 );
//
Buy = buy1 OR Buy2 OR Buy3;
//
// Standard price plot
Plot( Close, "Close", colorBlack, styleCandle);
//
// Custom title definition
BuyReason = EncodeColor(colorGreen ) + WriteIf(Buy,"Buy signals: ","") 
           + WriteIf(buy1, "Buy1 ", "") +WriteIf(buy2, "Buy2", "") 
           + WriteIf(buy3, "Buy3", "");
Title = StrFormat( "{{NAME}} - {{INTERVAL}} {{DATE}} Close %g ",Close ) +BuyReason;
//
// Plotshapes function calls
PlotShapes(Buy*shapeUpArrow, colorGreen, 0, Low);
PlotShapes(Buy1*shapedigit1, colorGreen, 0, Low,-30);
PlotShapes(Buy2*shapedigit2, colorGreen, 0, Low,-45);
PlotShapes(Buy3*shapedigit3, colorGreen, 0, Low,-60);
//
//
// Custom text labels displayed with PlotText
if( SelectedValue(Buy) )
{    
   i = SelectedValue( BarIndex() );
   maxy = Status("axismaxy");
   miny = Status("axisminy");
   y = 0.15 * (maxy - miny) + miny;
   text = WriteIf(buy1[ i ], "nBuy1 ", "") 
          +  WriteIf(buy2[ i ], "nBuy2 ", "") 
          +  WriteIf(buy3[ i ], "nBuy3 ", "");
   PlotText( text, i,  y, colorWhite, colorGreen );
} 

The chart below shows how to use signal visualization technique implemented in the formula.

The other method is to use the Exploration feature of Analysis window that allows to generate tabular output, where we can display the values of selected variables. The detailed tutorial explaining this feature is available at:
http://www.amibroker.com/guide/h_exploration.html

For the discussed purpose of tracking the signals that triggered entry or exit, we can add the following code to our trading system to show the values of each Buy1, Buy2, Buy3 variables:

Filter = Buy;
AddColumn( Buy1, "Buy1", 1, colorDefault, IIf( Buy1, colorGreen, colorDefault ) );
AddColumn( Buy2, "Buy2", 1, colorDefault, IIf( Buy2, colorGreen, colorDefault ) );
AddColumn( Buy3, "Buy3", 1, colorDefault, IIf( Buy3, colorGreen, colorDefault ) ); 

With regard to exit signals they can be visualized in a similar way as shown above, but there is also an additional functionality in the backtester, which allows to indicate the exit condition directly in the trade list. This can be done by assigning values higher than 1 (but not more than 127) to Sell variable.

Sell1 = Cross( Signal(), MACD() );
sell2 = Cross( MA(Close, 50), Close );
Sell = Sell1 * 10 + Sell2 * 20; 

The above expression will result in assigning value of 10 to Sell variable for the bars where Sell1 is true, 20 for the bars where Sell2 is true and 30 for the bars where both conditions are true.

These values will be indicated in the trade list:

It is worth to mention that values 1 to 9 are reserved for built-in stops and used internally by the backtester, and have special meaning:

1. normal exit
2. maximum loss stop
3. profit target stop
4. trailing stop
5. n-bar stop
6. ruin stop (losing 99.96% of entry value)
7. reserved
8. reserved
9. reserved

Note also that you must not assign value greater than 127 to Sell or Cover variable. If you assign bigger value it will be truncated.

This is further discussed here: http://www.amibroker.com/guide/afl/equity.html

When we perform historical tests on databases that contain delisted symbols – we may encounter a situation, where there are open positions in those tickers remaining till the very end of the backtest, distorting the results (as these open positions will reduce remaining maximum open positions limit for the other symbols).

Here is an easy technique which allows to force closing positions in those symbols on the very last bar traded for given symbol. The code below just adds an additional Sell signal on the last available bar in the database for this symbol:

bi = BarIndex();
exitLastBar = bi == LastValue( bi );
Sell = /*your regular sell rules*/ OR exitLastBar;

If we are using 1-bar trade delays in our backtesting settings, then the exit signal would need to be triggered one bar in advance (so the delayed signal could still be traded on the last bar) and the code would look like this:

SetTradeDelays(1,1,1,1);
bi = BarIndex();
exitLastBar = bi == LastValue( bi - 1 );
Sell = /*your regular sell rules*/ OR exitLastBar;

There is also a dedicated field in Symbol->Information window which allows to store the delisting date directly in the database. AmiBroker allows to read that field from AFL code using GetFnData() function. If we have this field populated for delisted symbols for our symbols, then the code forcing exits on delisting date would be:

exitLastBar = datetime() >= GetFnData("DelistingDate");
Sell = /*your regular sell rules*/ OR exitLastBar; 

What is important, this approach would work also, when Pad and Align to reference symbol feature is used in Analysis window settings.

In order to populate Delisting Date field in the database, we can enter the dates manually through Symbol->Information window or use ASCII importer to import the information from the input text files. More details about ASCII importing can be found at:
http://www.amibroker.com/guide/d_ascii.html

AmiBroker 5.84 (released today) offers users an easy way to create their own code snippets. Code snippet is a small piece of re-usable AFL code. AmiBroker comes with lots of pre-defined snippets. You can learn more about built-in snippets here.

But now you can add your own! And it is fairly easy using new Code Snippet window. Code Snippets window is available in new AFL editor (in floating frame mode). It can be shown/hidden using Window menu.

To create your own snippet, do the following:

1. type the code you want
2. select (mark) the code you want to place in a snippet
3. press Save selection as snippet button in the Code Snippets window

If you do the steps above the following dialog will appear:

Now you need to enter the Name of the snippet, the Description and Category. Category can be selected from already existing items (using drop down box), or new category name can be typed in the category field. Key trigger field is optional and contains snippet auto-complete trigger (to be implemented later). Once you enter all fields and press OK, your new snippet will appear in the list.

From then on you can use your own snippet the same way as existing snippets. Perhaps most convenient method is using drag-drop from the list to AFL editor.

As you may have noticed user-defined snippets are marked with red color box in the Code Snippets list. Only user-defined snippets can be overwritten and/or deleted. To overwrite existing user-defined snippet, simply follow the steps above and give existing name. AmiBroker will ask then if you want to overwrite existing snippet. To delete a snippet, select the snippet you want to delete from the list and press Delete (X) button in the Code Snippet window.

From time to time people send us their formulas asking what happens in their own code. Or they do not know why given trade is taken or not. These questions are usually caused by the fact that people lack the insight what is happening inside and what values values their variables hold.

The first general-purpose debugging technique is using Exploration.

You need to add several AddColumn statements and run your code as Exploration, so you can actually see the values of all variables. This will reveal whenever you really have values that you expect and would make it easier for you to understand what is happening inside your code.

In simplest form add this code to your system formula:

Filter = 1; // show all bars
AddColumn( Buy, "Buy" );

and it will show you if you are getting expected values in Buy array. You can use the same technique to track the content of any variable. Add as many columns as you want. You would be surprised how much insight into your own code you will get.

You can use Exploration to learn how particular function works, for example, if you don’t understand how ValueWhen works, you can display its results this way:

Filter = 1; // show all bars
//
m = MA( C, 10 );
cond = Cross( C, m );
bi = BarIndex();
//
AddColumn( C, "Close" );
AddColumn( m, "Mov Avg" );
AddColumn( cond, "Condition");
AddColumn( bi, "BarIndex" );
AddColumn( ValueWhen( cond, bi ), "ValueWhen( cond, BarIndex() )" );
AddColumn( ValueWhen( cond, Close), "ValueWhen( cond, Close )" );

If you run above code you will clearly see how ValueWhen picks the value when condition is true and “holds” it for all other bars (when condition is false).

Once you get this level of insight into your code you will be better equipped to fix any errors.
Exploration is number one choice in getting detailed view on what is happening inside your code.

For more information about Exploration see http://www.amibroker.com/guide/h_exploration.html