Im checking out the trail version of Amibroker. I have a question, not too sure if its been asked before.
When running AFL code through the Exploration functionality, Amibroker will round up, eg a stock price is .775 Amibroker will round this close price to .76 the implications are that when using a function like ROC, the percent is incorrect. I double checked the output with Excel and proved it to be incorrect. I know you can change decimal places in Preferences->Misc but that only changes the decimal places in the chart heading.
Is there a way to stop Amibroker from rounding using/displaying only the correct data?
Your understanding/assumptions/findings are totally incorrect. AmiBroker does NOT round data to cents as you assumed and does NOT use rounded data for calculations, and ROC percent is correct.
The thing is that you do not differentiate between calculations vs formatting.
Calculations in ALL binary computers regardless of program that you are using are done on BINARY numbers, not decimals.
Decimal system is only used for DISPLAY and conversion between native binary system and human-readable decimal system is called "formatting".
After reading relevant section of the manual, you will understand that the formatting for the display is user-definable. If you want 3 digits - voila - you get it
Filter = 1; AddColumn( Close, "Close", 1.3 ); // 3 decimals AddColumn( ROC( Close, 10 ), "ROC", 1.4 ); // 4 decimals
Calculations do NOT depend on formatting. Calculations are performed on binary data using precision available from hardware floating point unit that is part of your processor and that is governed by IEEE 754 standard.
By the way: exact same thing is done by Excel. Excel uses BINARY numbers and for the DISPLAY it uses definable formatting.
And as an eye opener, if you think that Excel is doing calculation on decimal numbers, you may enter
1 in cell
A1 in Excel and
1e-15 in cell
B1 and in cell
C1 enter the formula
=A1+B1-A1. If you expect that it would give you
B1, you will be surprised, because Excel would insist that it is zero (even if you tell it to use 30 decimal places)
Recommended reading: http://www.amibroker.com/kb/2010/07/20/about-floating-point-arithmetic/ (which also explains Excel behavior)
On a side note: it is sad that even today schools don't teach how computers work on bare-bone level. I've got children in schools and the binary system is only covered in max 1 hour of math lesson. Really education system is so badly flawed and not up-to-date.
Did you bother to add a ROC function on a few days then check the percentage with a manual calculation or in an Excel spreadsheet?
And did you bother to do that ? I guess you neither did read the manual nor the explanation made by @Tomasz - sorry to say (well, actually I'm not sorry) but perhaps you have some issue with understanding a simple text in English language.
@Mikeman - maybe you just post your Excel formula and we will gladly point out where you are making mistake.
AmiBroker produces correct result. And AmiBroker numbers are in-line with Excel.
AmiBroker formula for you:
Filter = 1; AddColumn( Close, "Close", 1.5 ); AddColumn( ROC( Close, 10 ), "ROC10", 1.5 ); // correct rate of change divides difference by STARTING value (not ending value) Close10 = Ref( Close, -10 ); roc10 = 100 * ( ( Close - Close10 ) / Close10 ); AddColumn( roc10, "ROC10(manual)", 1.5 );
AmiBroker result for you (EURUSD 5 decimal digits formatting):
And here it comes in Excel. The LAST column is EXCEL calculation and it yields same results.
The proof is in the pudding!