Australian (ASX) Stock Market Forum

Amibroker FAQ

I'm having some confusion with my watch list data. I'm using Amibroker with Norgate ASX Platinum.
When I run an exploration 05/04/21-09/04/21 weekly periodicity over the All Ords, I receive 499 results however when using All Ords past & current I receive 827. I think I may have missed something fundamental but I thought the two explorations should return the same number of tickers?

As a test I'm using the following exploration code:
Code:
Filter = 1;

AddColumn(Close,"Close",1.5);

Apologies if this is really dumb, however would appreciate any thoughts.

Cheers
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.pngScreen Shot 2021-04-24 at 9.56.35 am.pngScreen Shot 2021-04-24 at 9.57.21 am.png
 
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..

View attachment 123250View attachment 123253View attachment 123254
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

1621147589139.png
 
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:
1621170247455.png
now on the AWS instance:
same code just copied brand new, same filters, same settings on both platforms.

1621170312144.png
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.
 
Here's a simple but time consuming workaround allowing Amibroker to read 2020 EOD data until your vendor starts sending data in the correct format.

Open a daily EOD data file in a simple text editing program (not Word).
Select and copy date segment from one of the ticker lines. For example Jan 2, 2020 will look like this200102. 200110. Fridays data
Go to menu "Find and Change" or similar.
Enter find: 190819
Enter change to: 20200110
Press "Change All" or similar
Save
All date events for every ticker in the daily EOD file are now in correct format.
Repeat this for each daily file.
Complain to your data provider to supply data in four digit format for the year.
notepad++ is free and ok for this to work you need to replace 190819 with this 20200110 this works with comsec data save file and install with wizard this hint was taken from here https://forum.amibroker.com/ i have no problems from Norgate date
 
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?
 
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.
 
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?
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.
 
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?
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)
 
Top