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
I want to be able to control the History Data I use so that I can repeat tests (Strategy Tester) under controlled conditions.
What controlled conditions?
Thank you
What controlled conditions?
Thank you
The conditions I choose not the conditions that my Broker chooses. How else do you propose to test ? random set of conditions for each test ? but lets not get off topic.
Understood.
Thank you
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.
Hello angevoyageur,
1.000000000006551e-005
0.00001000000000006551
The second double's decimal is moved to the left five times BUT ;) can't be returned in the tester in this format because doubles return a max value of sixteen digits (significant digits) to the right of a decimal.
Moderator
1651
Hello MQL5 community,
https://www.mql5.com/en/docs/common/comment
"Data of double type are output with the accuracy of up to 16 digits after a decimal point, and can be output either in traditional or in scientific format, depending on what notation will be more compact. Data of float type are output with 5 digits after a decimal point. To output real numbers with another accuracy or in a predefined format, use the DoubleToString() function."
USDJPY's price representation in 98.370 is data of float type (output at 5 digits after decimal).
USDJPY's price representation in -0.001999999999995339 is data of double type, traditional format (output at up to 16 digits after decimal).
Why does double -0.00199999999999533[9] return an 18th digit after the decimal if a double output is only up to 16 digits after the decimal?
Thank you
Prices are always double, 98.370 is a double. There are 16 significant digits. Zeros are not significant.
If zeros aren't significant, why couldn't the value 0.00001000000000006551 be returned in the tester instead of 1.000000000006551e-005? I'd prefer crunching calculations in 0.00001000000000006551 format!
Thank you
If zeros aren't significant, why couldn't the value 0.00001000000000006551 be returned in the tester instead of 1.000000000006551e-005? I'd prefer crunching calculations in 0.00001000000000006551 format!
A floating point number ( double ) is always held internally in this format . . . 1.000000000006551e-005, did you read and understand the information at the links given ?
From here: floating point numbers
"An IEEE-754 float (4 bytes) or double (8 bytes) has three components (there is also an analogous 96-bit extended-precision format under IEEE-854): a sign bit telling whether the number is positive or negative, an exponent giving its order of magnitude, and a mantissa specifying the actual digits of the number. Using single-precision floats as an example, here is the bit layout:"
3 parts
If you want to see 0.00001000000000xyz then use DoubleToStr() to format the output to your liking.
A floating point number ( double ) is always held internally in this format . . . 1.000000000006551e-005, did you read and understand the information at the links given ?
From here: floating point numbers
"An IEEE-754 float (4 bytes) or double (8 bytes) has three components (there is also an analogous 96-bit extended-precision format under IEEE-854): a sign bit telling whether the number is positive or negative, an exponent giving its order of magnitude, and a mantissa specifying the actual digits of the number. Using single-precision floats as an example, here is the bit layout:"
3 parts
If you want to see 0.00001000000000xyz then use DoubleToStr() to format the output to your liking.
Yes, I read all your provided links and found them helpful, thank you again for providing them. My liking would be to incorporate DoubleToString and choose the double's second to last place value (example:CADJPY 95.9[5]9) as DoubleToString's second parameter. I don't think this "can price!=price" problem is too difficult to solve! What say you to this?
Thank you
Yes, I read all your provided links and found them helpful, thank you again for providing them. My liking would be to incorporate DoubleToString and choose the double's second to last place value (example:CADJPY 95.9[5]9) as DoubleToString's second parameter. I don't think this "can price!=price" problem is too difficult to solve! What say you to this?
So you mean something like this ?
Can price != price is a different, but slightly connected, issue. It can't really be solved, first you need to understand what the issue is . . . then you work around it.
So you mean something like this ?
Can price != price is a different, but slightly connected, issue. It can't really be solved, first you need to understand what the issue is . . . then you work around it.
What are your thoughts as to what this "can price != price" issue is?
Thank you
WhooDoo22:
...
Prices are always double, 98.370 is a double. There are 16 significant digits. Zeros are not significant.
If zeros aren't significant, why couldn't the value 0.00001000000000006551 be returned in the tester instead of 1.000000000006551e-005? I'd prefer crunching calculations in 0.00001000000000006551 format!
Thank you
That could be, it's only a choice of formatting output value.
It is precisely because the zeros are not significant
Yes, I read all your provided links and found them helpful, thank you again for providing them. My liking would be to incorporate DoubleToString and choose the double's second to last place value (example:CADJPY 95.9[5]9) as DoubleToString's second parameter. I don't think this "can price!=price" problem is too difficult to solve! What say you to this?
Thank you
That could be, it's only a choice of formatting output value.
It is precisely because the zeros are not significant
Sorry but I don't understand this sentence."Sorry but I don't understand this sentence."
Thank you