This is a mobile optimized page that loads fast, if you want to load the real page, click this text.

Amibroker FAQ

Did you do a typo here on your interval. A 4 day period for weekly? That might explain weird results..or is it a US date format? But then why 5y chosen 10y+ ago?
 
Did you do a typo here on your interval. A 4 day period for weekly? That might explain weird results..or is it a US date format? But then why 5y chosen 10y+ ago?
Thanks for the thoughts qldfrog. I use the date selector in Amibroker, so the dates are monday-friday from April 2021 and periodicity set as weekly.. I've reached out to Norgate as well but waiting on a response..

Screen Shot 2021-04-24 at 9.56.27 am.png Screen Shot 2021-04-24 at 9.56.35 am.png Screen Shot 2021-04-24 at 9.57.21 am.png
 
This is still not right, i do not believe you can run a weekly system on five days,
The AB date range will find one week to start and same week to stop so one bar? .that makes no real sense
at the very least, select 2 weeks and proceed, if the problem is still there sure investigate but otherwise, i am sure you have better problems to solve
 
I forgot to use NorgateIndexConstituentTimeSeries. So the exploration was identifying any stock that had been in the index, not those that were in the index during the to-from dates
 
I fired up Amibroker, first time for a few days and got this.

It gives the same msg for any symbol entered.

I would prefer to fix this rather than reload Amibroker, I would be very grateful if anyone could shed any light on the problem

 
Something weird with AB and Premium Data on 2 instances
I see some differences between AB on an AWS cloud and my laptop, to the point of being seriously different and so influencing the system buy sell:
just created guppyv11 afl code:
run in on PC:
I get the following explore results:

now on the AWS instance:
same code just copied brand new, same filters, same settings on both platforms.


and arv/ter exists on both platform.
AB is supposed to be deterministic, no free will...
If anyone has any clue or experienced similar issue maybe between 2 different instances of AB..
not sure which one is the best
Note: both platforms running same version of AB, with updated data
 
I have been trying a couple of different Amibroker strategies. But when I look at the Explore for the previous day and match it to the Backtester Buys I found the following:

If a stock gives a 'Buy' signal on Day 1 and is not bought, even if it gives a 'Buy' signal on Day 2 and is the next highest in the PositionScore, the Backtester skips this stock (and any others that generated a 'Buy' on Day 1) and proceeds to the next stock that generates a 'Buy' on Day 2 (but did not give one on Day 1). This means it is choosing stocks from much further down the list than it needs to.

I am new to Amibroker and assume that I have something dumb set in my code, but even stripping most things out, it still occurs. I have TmeFrameSet(inDaily); I have also looked at the Backtester settings and tried turning things on and off, but I still get the same results.

Any help would be greatly appreciated.
 
Last edited:
Cross check all the settings in the detailed reports. Particularly the pad and align, position sizing etc.

If you're not overloading them in the AFL code ( which can't be done for some settings ) then you are at the mercy of how they're configured in the amibroker instance.

Also check the database settings too. Norgate has it's own pad and align settings as well.
 
On further reading, I've seen this:

Buy-Sell signal pairs are matched and treated as a TRADE. If trade is NOT entered on first entry signal due to weak rank, not enough cash or reaching the maximum open position count, subsequent entry signals are ignored until matching exit signal. After exit signal, the next entry signal will be possible candidate for entering trade. The process of removing excess signals occurring after first buy and matching sell (and short-cover pair respectively) is the same as ExRem() AFL function provides. To use regular mode you don't need to call SetBacktestMode function at all, as this is the default mode.

You may or may not consider removing extra signals desirable. If you want to act on ANY entry signal you need to use second mode - backtestRegularRaw.

It does NOT remove redundant entry signals and will act on ANY entry provided that it is scored highly enough and there is a cash available and maximum number of open positions is not reached. It will however allow only ONE OPEN POSITION per symbol at any given time. It means that if log trade is already open and later in the sequence appears an extra buy signal, it will be ignored until a "sell" signal comes (short-cover signals work the same). Note that you can still use sigScaleIn/sigScaleOut to increase or decrease the size of this existing position, but it will appear as single line in backtest result list.


So it seems like the behaviour I've seen is normal, unfortunately. One system backtests really well as is, so I guess now I need to try and figure out how I filter out any stocks that have not have given a Buy signal and not given a sell signal, so I can manually ignore them in my exploration. Darn, it seems like I'll need some sort of loop and I haven't learnt how to do them yet.

Strangely, the backtestRegularRaw results are much worse than the 'normal' backtest. I thought as it would be picking the top candidates it would be much better. More work need here too.
 
 
Hey all,

A quick question. When you are coding up your systems in AmiBroker do you code in your backtest settings to your system using the SetOption(), SetTradeDelays() and SetPositionSize() functions OR do you set your backtester settings in the analysis window for a specific system, save it as an .abs file, and then just load it up when you're running a backtest?

Does it matter which way you do it?
 
I enter everything into my AFL code to make sure the settings are the same every time I run a back test.

I also run Amibroker on two machines (my primary desktop PC and a laptop when I'm travelling) and learnt this the hard way. The two machines were giving slightly different back test results and it took ages to track down the culprit. Having as many settings as possible coded in my AFL didn't fix the problem but it eliminated a lot of possibilities.
 
as @BoNeZ has stated, you should include it. If you don't specify it in the code then AB will use whatever default's you have in the Settings area. when you start writing more systems you will end up just copy/paste/edit this code anyway. it will give uniformity when tested elsewhere too.
 
As others have said. It's very easy to accidentally modify settings while testing other ideas and forget to change things back before running your live system. Putting the settings into your code removes as much human error as possible.

You'll still make errors, but at least this way you'll have copied and pasted them into all your other systems too... wait...
 
One new trap I came across yesterday...

I have a system that I run on the All Ords, so when I do an explore I have the filter set to the "All Ordinaries" watchlist. Enter ALC. ALC was in the All Ords in February and generated a buy signal. It should have exited last week, but it's no longer in the All Ords watchlist, so I didn't get an exit signal. I only noticed as I manually check all open positions each week as a safety check.

Also, hot tip, ALC is sitting on a nice support level and now that I've sold is almost certain to move higher.
 
You've just encountered survivorship bias.

Since you're already a user of our data, you might want to make use of the All Ordinaries Current & Past watchlist and also the NorgateIndexConstituentTimesSeries() in your backtesting.

Also see this, so you exit a position on a backtest prior to delisting:
(if you don't, your system will be stuck in that position)