amibroker

From time to time we receive questions from customers wanting to buy new computer asking about recommended hardware / software configuration to run AmiBroker.

We won’t focus too much on the details here as hardware evolves very fast, instead we will give some general information that will help you make informed buying decision.

AmiBroker, by itself is very fast and it is not very demanding. However, if user wants to run some very complex and long optimizations then it may be worthwhile to think about choosing proper hardware / software configurations.
The two most critical components are CPU and RAM. AmiBroker is able to fully saturate CPU and RAM so these two should be selected with more care. The other components do not really matter much.

Currently (as of October 2011) we can recommend:

1. CPU: Intel i7 or i5 CPU. 4 (or more) cores recommended. AmiBroker is multi-threaded application and is able to utilize as many cores as your CPU has. AMD processors are good too, but not as fast as i7.
2. RAM: 6GB or more (triple channel), or 8GB (dual channel). Triple channel recommended, however dual channel is OK too. With more memory you would access disk less and RAM is orders of magnitude faster than disk.
3. HDD: it can be any hard disk, good brand is Western Digital Caviar Black. 1 TB (terabyte) is enough for all measures. With regards to SSD (solid state) disks – they are very fast, but be aware of many reliability issues that plague some SSD disks (Intel and Crucial seem to be most reliable, other brands are questionable). That said, recently I changed to dual SSD/HDD drive setup. Crucial m4 64GB SSD disk as my system-only drive and mechanical drive for programs and data. No problems so far, but the reliability of SSD is yet to be proven. In case of system failure, make sure to have full disk image made on frequent basis (see below). Disks fail, sooner or later – be prepared.
4. Graphic card: any card that has WDDM v1.1 drivers is OK. This is so because in Windows 7 GDI is more efficient when using WDDM 1.1 drivers. Personally we use nVidia cards.
5. Sound card: any
6. Motherboard: any. Personally we use Asus motherboards.
7. Monitor/display: any with DVI/HDMI connection. Digital (DVI/HDMI) gives better picture quality. Personally we use EIZO monitors.
8. Power supply: it is important to get stable and adequately strong power supply. Instable power can give some mysterious problems.
9. Internet connection: via hardware router with NAT (Network Address Translation) and built-in firewall. Good hardware router with firewall is your first line of defense and should make your computer completely invisible (“stealth” mode) to any potential attackers. I can recommend Linksys routers. For example good and inexpensive router is Linksys WRT54GL. This particular router allows loading open-source firmware that is way better than one shipped with the router.
   If you are enabling Wi-Fi access on the router make sure to use WPA2/PSK authentication and long password.

With regards to software:

1. OS: Windows 7 64-bit Home Premium or higher. “Home” version is perfectly adequate. 64-bit allows you to use more memory.
2. Firewall: Windows 7 has built-in firewall that is perfectly enough, especially if you are behind the router (see above)
3. Anti-virus: Microsoft Security Essentials (MSE) – it is good and free. What is even more important, it does not slow down your system. It is good idea to exclude data folder(s) and data files from virus scan/monitoring. Some other antiviruses are very bad when it comes to affecting normal operation of Windows. MSE does not break your OS.
4. Disk imaging: it is very good idea to make backups of your disks using disk imaging software so you can restore your system in case of failure or virus infection in a matter of 4-5 minutes instead of hours. Good imaging software is Macrium Reflect Free or Acronis True Image. True Image was a winner some years ago, but now it is rather bloated, so we would rather recommend free Macrium Reflect.
   It is recommended to divide your hard disk into at least 2 partitions, one for system and one for programs/data, or better 3 partitions system/programs/data. Then you will be able to easily make an image of your hard disk (especially system partition) and restore image without problems. Also in case of virus infection it is easier to restore system partition only instead of entire disk. It is faster and way more reliable than attempts to “cure” any computer virus.

5. Don’t install things you don’t need. Especially beware of any “enhancers” and “turbo” programs. They do nothing but harm. The less software you install on your computer, the more stable it will be.
   

   Related articles:

   1. How to backup AmiBroker configuration
   2. Third party software “black list”
   3. Running OLE automation scripts with 32- and 64-bit versions of AmiBroker
   4. How to migrate AmiBroker to a new computer
   5. Running AmiBroker on Windows Vista (both 32 and 64 bit editions)

   Filed by Tomasz Janeczko at 9:18 am under Installation
   Comments Off on Recommended hardware/software for AmiBroker

Literally every day we receive at least a couple of “I am interested in your software please call me” requests.

We are very happy that you are interested in our software, and we are all here to help, but we don’t contact users via telephone. We use e-mail only.

There is a completely FREE trial version that you can download from http://www.amibroker.com/download.html We do not ask for your personal data or e-mail to allow you to use the free trial. Just download. No questions asked.

If you have questions, technical support and sales information is provided by e-mail only. We are small company and that is the only way qualified support personnel can manage time in efficient manner and provide best answers in shortest possible time. Typically we respond in a matter of hours Monday-Friday and we also try to handle most urgent e-mails on weekends. E-mails are handled by qualified engineers who know their stuff that can give you meaningful and helpful response.

So, please e-mail us (support at amibroker.com) and we will be happy to provide solutions / help to any questions that you may have.

If you are not convinced yet, here is some good reading on this topic:
https://signalvnoise.com/posts/1161-why-would-you-want-to-call-me

Filed by Tomasz Janeczko at 5:38 pm under Troubleshooting
Comments Off on Support and sales is by e-mail only

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.

Filed by Tomasz Janeczko at 10:51 am under Troubleshooting
Comments Off on Third-party plugins must use multithreaded run-time

First of all it is absolutely necessary to run full setup on the new system to ensure proper configuration and appropriate access rights on the new system.

The setup program can be downloaded from:

http://www.amibroker.com/download.html

Once the program has been installed – you can either activate the program (if you want to start with a fresh copy) or also restore your settings from the old computer.

If you want to start with a fresh installation, then it’s enough to run the software activation wizard. To get a copy you can use the form at:
http://www.amibroker.com/lostkey.html

TRANSFER “EVERYTHING”

If you want to transfer all data from the old computer:

1. run full setup on a new computer,
2. copy the entire contents of AmiBroker folder from the old computer (with all the databases) into the location where you have installed AmiBroker on the new machine (see the installation path above), overwriting the existing files.

That is the end of the procedure.

TRANSFER “CHARTS ONLY” (not recommended)

It is advised to just copy everything as described above, but if for some reason, you want to copy ONLY the layouts / charts, then you need to copy just some of the files

1. run full setup on a new computer (for best results use same directory name as on the old computer)
2. *.awl files from Layouts folders inside AmiBroker main folder and inside database folder (holding layouts calling certain charts recognized by their ID)
3. broker.newcharts file which contains list of charts (their IDs) and their corresponding formula files
4. contents of Formulas folder – to have formula referenced by certain charts
   This is because layouts refer to certain charts recognised by their chart ID number. So all elements have to be present.

More information about files used by AmiBroker can be found at:
http://www.amibroker.com/guide/x_files.html

Filed by AmiBroker Support at 5:59 am under Installation
Comments Off on How to migrate AmiBroker to a new computer

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.

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/SSE2) or extended precision (80bit/x87) where it is necessary (for certain internal calculations).

Note also that due to the architectural differences between compilers for 32-bit and 64-bit programs,
small numerical differences may exist between 32-bit and 64-bit version of AmiBroker due to the fact that 32-bit version uses x87 FPU code while 64-bit version uses SSE2 code and the underlying floating point hardware is different and operate slightly differently.
x87 FPU code internally offers more (80bit) precision than SSE2 (64-bit).
For in-depth discussion see:
https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/

Filed by Tomasz Janeczko at 3:37 am under AFL
Comments Off on About floating point arithmetic

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

Filed by Tomasz Janeczko at 8:14 am under Indicators
Comments Off on Study() function in logarithmic scale

NOTE: This article describes old method of using bar/value coordinates. New code should use GfxSetCoordsMode which allows you to use bar/value without any extra calculations.

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.

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.

Filed by Tomasz Janeczko at 4:45 am under Indicators
Comments Off on How to convert from bar-value to pixel co-ordinates

NOTE: Benchmarks and timings given below are little outdated because article was written back in 2008. Today’s CPUs are faster and memory bandwidth is also higher.

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:

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)

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.

Filed by Tomasz Janeczko at 2:20 pm under AFL
Comments Off on AFL execution speed

That is the common question we receive through support channel, so even though it is explained in the LICENSE.TXT file that you have in your AmiBroker folder, let us make some facts straight.

First take a look what the license says:

“REGISTERED VERSION:
One registered copy of the program may either be used by a single person who uses the software personally on one or more computers, or installed on a single workstation used non-simultaneously by multiple people, but not both.
You may not disclose registration key(s) to non-registered users.
Storage/Network Use. You may also store or install a copy of the Software on a storage device, such as a network server, used only to install or run the Software on your other computers over an internal network; however, you must acquire and dedicate a license for each separate computer on which the Software is run from the storage device. A license for the Software may not be shared or used concurrently on different computers.”

So the answer to most common question: “Can I install and use it on both desktop and laptop?” is YES, you can.

It is however NOT allowed to use single license to RUN SIMULTANEOUSLY on MULTIPLE machines connected via network, like for example running optimization on many machines in parallel. For that you must purchase license for every machine you are using simultaneously.

Filed by Tomasz Janeczko at 12:21 pm under Installation
Comments Off on Single license use on multiple computers?

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:

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):

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:

So it ends up with:

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

requires 71 past bars and 0 future bars.

You can modify it to

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

If you modify it to

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

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:

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

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:

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.

Filed by Tomasz Janeczko at 5:33 am under AFL
Comments Off on QuickAFL facts