mt5 strategy tester ticks - page 9
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Hello MQL5 community,
Has anyone else encountered numbers like these when running strategies in the tester? -1.000000000006551e-005 and 1.000000000006551e-005 (yep, that's eleven zeros). It must be a specific double format type but what double format type, hmm?
Also, I'm reading MQL5 documentation like yeah, ok, ok, standard int data type has a min value of -2 147 483 648 and a max value of 2 147 483 647 then yes, of course there's the unsigned int data type with a min value of 0 and a max value of 4 294 967 295 BUT ;) there's no int data type with a min value of minus -4 294 967 295 and a max value of 0. I'd a thought there would be an int data type having these min and max values but it is what it is. The previous statement might also apply to additional data types.
Thank you
0.00001 is the same a 1 e-5 is an exponent format. The extra digits at the end, the 6551 are equivalent to 0.00000000000000006551 and this is why we have problems comparing doubles . . . you need to read this, and do some research if you need to, so you understand what is going on: Can price != price ?
Simon,
Much obliged, I'm reading the thread and believe the involved mql4 thread posters' general solution for double comparison was to discover and utilize a method for rounding these doubles appropriately to return correct values. What say you to this?
Thank you
Simon,
Much obliged, I'm reading the thread and believe the involved mql4 thread posters' general solution for double comparison was to discover and utilize a method for rounding these doubles appropriately to return correct values. What say you to this?
Thank you
In the context of your post above comparisons of doubles is not important, understanding why you can't simply compare doubles is what is important.
Why? Because I think price values are returned in a format of four and five digits (with exceptions like USDJPY which returns price values of two and three digits). I'll try to just break it down once and for all because I don't wish to drag this on longer than needed.
USDCHF's bid price is currently 0.92909 and I believe the furthest MetaTrader5 calculates these price values is sixteen places to the right of the decimal, if this is the case then there's eleven places after the last digit nine being thrown into calculations of USDCHF's price of 0.9290900000000000. I think the reason doubles can't simply be compared is because the rest of the places to the right of a price's decimal (not the ones readable in the terminal but the ones not readable in the terminal) cause inequality problems.
Thank you
Why? Because I think price values are returned in a format of four and five digits (with exceptions like USDJPY which returns price values of two and three digits). I'll try to just break it down once and for all because I don't wish to drag this on longer than needed.
USDCHF's bid price is currently 0.92909 and I believe the furthest MetaTrader5 calculates these price values is sixteen places to the right of the decimal, if this is the case then there's eleven places after the last digit of nine being thrown into calculations of USDCHF's price of 0.9290900000000000. I think the reason doubles can't simply be compared is because the rest of the places to the right of a price's decimal (not the ones readable in the terminal but the ones not readable in the terminal) cause a problem of inequality.
Thank you
Why?
It's all explained on the first page of the thread I gave a link to, in essence; a value of 1.57373 may actually be held as a double value of 1.5737300000000001 while NormalizeDouble(1.57373, 5) might produce a double value of 1.5737299999999999 both values rounded to the nearest 5th digit are equal but compared directly are not equal . . . this is how double values are stored, they are floating point numbers ( look up floating point numbers, read and understand ) and often the value held is not exactly the same as the value that you think is being held.
So your comment shows a subtraction of two doubles and you see the difference as 1.0000000000xyz -e5 this is because this is how doubles are stored - floating point numbers.
The problem with double come from their binary representation. There are double that don't have an exact binary representation, so you obtain things like 1.000000000006551e-005. I don't enter here in detailed explanation, if interested you can read this for example.
1.000000000006551e-005's sixteenth place to the right of the decimal is e-005.
Are you saying 1.000000000006551e-005 doesn't have an exact binary representation because its sixteenth place to the right of the decimal isn't an integer, its e-005?
"I don't enter here in detailed explanation,"
Why not? If you wish to write a detailed explanation then by all means, do so.
"if interested you can read this for example."
I've begun reading it.
Thank you
"I don't enter here in detailed explanation,"
Why not? If you wish to write a detailed explanation then by all means, do so.
1.000000000006551e-005's sixteenth place to the right of the decimal is e-005.
Are you saying 1.000000000006551e-005 doesn't have an exact binary representation because its sixteenth place to the right of the decimal isn't an integer, its e-005?
No. If you read my link and/or the one of RaptorUK, that would be more clear to you. If not, read again :-D
1.000000000006551e-005 is simply another notation for 0.00001000000000006551.
It's all explained on the first page of the thread I gave a link to, in essence; a value of 1.57373 may actually be held as a double value of 1.5737300000000001 while NormalizeDouble(1.57373, 5) might produce a double value of 1.5737299999999999 both values rounded to the nearest 5th digit are equal but compared directly are not equal . . . this is how double values are stored, they are floating point numbers ( look up floating point numbers, read and understand ) and often the value held is not exactly the same as the value that you think is being held.
So your comment shows a subtraction of two doubles and you see the difference as 1.0000000000xyz -e5 this is because this is how doubles are stored - floating point numbers.
1.57373 (ignore)
1.5737300000000001
1.5737299999999999
"both values rounded to the nearest 5th digit are equal"
Both values rounded to the nearest 5th equal 1.57373.
"but compared directly are not equal"
Yes, because there's a difference.
"this is how double values are stored"
Double values such as 1.5737300000000001 are stored as 1.57373 (if normalize double is used I assume). If normalize double isn't used, the double value 1.5737300000000001 would keep this value format, correct?
"and often the value held is not exactly the same as the value that you think is being held."
My last statement responds to this statement as well.
I'll read the link you provided, thank you for it.
Thank you