mt5 strategy tester ticks - page 11

 
RaptorUK:

 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

 
WhooDoo22:

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.
 
RaptorUK:
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

 
angevoyageur:

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
angevoyageur 2013.04.14 09:39
WhooDoo22:

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

 
WhooDoo22:


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

SignMantissaExponent
+1.000000000006551-005

 

If you want to see 0.00001000000000xyz then use DoubleToStr() to format the output to your liking.

Articles - Understanding Floating Point Number Representation - Cprogramming.com
Articles - Understanding Floating Point Number Representation - Cprogramming.com
  • www.cprogramming.com
Floating point representations vary from machine to machine, as I've implied. Fortunately one is by far the most common these days: the IEEE-754 standard. This standard is prevalent enough that it's worthwhile to look at it in depth; chances are good you'd be able to use this information on your platform (look for ieee754.h). An IEEE-754...
 
RaptorUK:

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

SignMantissaExponent
+1.000000000006551-005

 

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

 
WhooDoo22:

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 ?

double value = 95.959;

Print("Value: ", DoubleToStr(value, _Digits - 1) );

 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. 

 
RaptorUK:

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. 

double value=95.959;

Print("value returns ",DoubleToString(value,2));//value's expected print return is 95.95.

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.

All equivalents
0.00001000000000006551
0.0001000000000006551e-001
0.001000000000006551e-002
 0.01000000000006551e-003
 0.1000000000006551e-004
1.000000000006551e-005

It is precisely because the zeros are not significant

WhooDoo22:

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

Sorry but I don't understand this sentence.
 
angevoyageur:

That could be, it's only a choice of formatting output value.

All equivalents
0.00001000000000006551
0.0001000000000006551e-001
0.001000000000006551e-002
 0.01000000000006551e-003
 0.1000000000006551e-004
1.000000000006551e-005

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."

double value=95.959;

Print("value returns ",DoubleToString(value,2));//value's expected print return is 95.95.

Thank you

Reason: