SetBarsRequired(sbrAll, sbrAll);
SetCustomBacktestProc("");
function applyCustomBacktesterRules()
{
bo = GetBacktesterObject(); // Get backtester object
bo.PreProcess();
dt = DateTime();
for( i = 0; i < BarCount; i++ )
{
_TRACE( "bar=" + i + ", bo.GetSignalQty(i, 0)=" + bo.GetSignalQty( i, 0 ) );
for( sig = bo.GetFirstSignal( i ); sig; sig = bo.GetNextSignal( i ) )
{
}
bo.HandleStops( i ); // Handle programmed stops at this bar
bo.UpdateStats( i, 1 ); // Update MAE/MFE stats for bar
bo.UpdateStats( i, 2 ); // Update stats at bar's end
}
bo.PostProcess();
}
Short = BarIndex()==1295;
Cover = BarIndex()==1298;
if (Status("action") == actionPortfolio)
applyCustomBacktesterRules();
I have a situation like above (not exact but similar). The short signal is NOT present in bar 1295. bo.GetSignalQty( i, 0 ) returns 0.
How do I debug this?
Yes this code is a representation my code is different and because it is too long I cannot post it here. I am not able to debug it. How do I debug it?. The signal is there in exploration. I have checked excessive signals. The signal is present till the last line of the indicator code but vanishes in cbt.
Special attention should be given to the picture that shows how entry and signals are matched and how redundant ones are removed. See also SetBacktestMode function that controls what signals are kept and which are not.
Generally you should not be using CBT unless you understand the core principles explained in very detail in the manual.
Another important thing is PADDING. Depending on pad and align option, the quote might be padded to reference symbol and the absolute bar number in CBT that represent ALL bars that are present in any of the symbols under test might NOT be the bar number that you are referring to DO NOT use absolute hard coded bar numbers!!!!
Use date time instead. ONLY date times are guaranteed to accurately represent bars. Bar numbers are NOT ! Bar numbers vary when you use padding, other unaligned symbols, quickafl, etc.
Yes on SetBacktestMode( backtestRegularRaw ); the signal shows up along with many other duplicate scalein and scaleout signals. I don't know how to debug this because when i check the short, cover count (see below trace command) it seems perfect. Where are the raw redundant signals. How do i trace?
I am just going crazy over this. I don't know where the redundant signals are. On chart everything seems fine. But running backtest in backtestRegularRaw mode brings back the missing signal (along with a few duplicates). I don't know how to debug this. Tomasz any hints?
Setting your signals via bar number is a very bad idea, as the bar numbers for a particular date will change depending on the start date of your analysis as well as the indicators that you’re using because AmiBroker always tries to ensure that all indicators are valid no later than the first bar of the analysis date range. For example, if your AFL uses a 200 period simple moving average, then Bar 0 will be at least 200 bars prior to the start of your analysis date range.
During Phase 2 of the backtest (CBT), the bar numbers change again to align with the ~~~Equity symbol. Generally that means that bar 0 aligns with the first date and time that is within the analysis date range.
If you want to see if AmiBroker is eliminating your signals, try changing the Backtest Report to Detailed Log. All signals are shown for every bar, along with a date/time stamp
But how do I hunt down the redundant signals? Buy, sell, cover, short count is OK. I checked. Where else are this so called redundant raw signals. Please tell me how to debug.
@AlgoEnthusiast, did you test the different modes of SetBacktestMode that do not remove redundant signals?
Then in your CBT code you can then select what signal to actually process and what to discard.
In general, debugging in the CBT is done using a lot of detailed_TRACEF() calls (for example see this post) - I use DebugView++ as an external logger.
In any case, I suggest to reread and study carefully the previous post by @Tomasz to properly understand how Amibroker normally process signals.
@Tomasz@beppe
Ok. So I ran the backtest under backtestRegularRaw mode which does NOT remove redundant signals. I ran only with 1 stock. I traced the signal in cbt and find that bar no. 134 has following signals short, short, scalein, short, scalein, short, scalein
My code on the other hand has only one signal on this bar i.e. Short=99998 (ScaleIn)
But i don't understand one thing how can 1 stock have so many signals on one bar? how short=1 and short=scalein for same bar same stock? bar 120 is the bar with short signal (short open) and this bar has right signal in CBT too.
If i trace before CBT it shows only one signal on this bar i.e short=99998
