hi all
I'm writing some code to calcualate lot size and then i'm using normalize to keep up to 2 decimals.
It's working fine except for the value 7 as shown below.
it happens in any time frame and any currency pair.
I've seen normalisedouble failing a couple of other times with other calculated values (not related to lot) when using it as a comment/print and running it through a whole chart, so i'm not sure if its a bug or just hit and miss randomly
is it? if you're not sure read the docs
https://www.mql5.com/en/docs/convert/doubletostring
![Documentation on MQL5: Conversion Functions / DoubleToString Documentation on MQL5: Conversion Functions / DoubleToString](https://c.mql5.com/36/47/documentation-on-mql5-conversion.png)
- www.mql5.com
hi all
I'm writing some code to calcualate lot size and then i'm using normalize to keep up to 2 decimals.
It's working fine except for the value 7 as shown below.
it happens in any time frame and any currency pair.
I've seen normalisedouble failing a couple of other times with other calculated values (not related to lot) when using it as a comment/print and running it through a whole chart, so i'm not sure if its a bug or just hit and miss randomly
This is the way floating-point numbers are stored in memory. Internally, 64-bit floating point numbers have some inherent imprecision, because they are coded in binary 01.
The fp number 0.07000000000000001 happens to be the closest representable number to the true real number 0.07.
This has nothing to do with the function NormalizeDouble() at all.
Try to run this script to replicate the problem:
//+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ void OnStart() { Print(0.01); Print(0.02); Print(0.03); Print(0.04); Print(0.05); Print(0.06); Print(0.07); Print(0.08); Print(0.07 == 0.07000000000000001); } //+------------------------------------------------------------------+ //output: /* 0.01 0.02 0.03 0.04 0.05 0.06 0.07000000000000001 0.08 true */
To get the internal representation of a floating-point number, use my script IEEE Floating-Point Decoder
https://www.mql5.com/en/code/19978
For further reading:
![Floating-point arithmetic | Wikiwand Floating-point arithmetic | Wikiwand](https://c.mql5.com/36/47/floating-point-arithmetic-wikiwand.jpg)
- www.wikiwand.com
hi all
I'm writing some code to calcualate lot size and then i'm using normalize to keep up to 2 decimals.
It's working fine except for the value 7 as shown below.
it happens in any time frame and any currency pair.
I've seen normalisedouble failing a couple of other times with other calculated values (not related to lot) when using it as a comment/print and running it through a whole chart, so i'm not sure if its a bug or just hit and miss randomly
NormalizeDouble(value,2); <--- 2 being the number of digits
This is the way floating-point numbers are stored in memory. Internally, 64-bit floating point numbers have some inherent imprecision, because they are coded in binary 01.
The fp number 0.07000000000000001 happens to be the closest representable number to the true real number 0.07.
This has nothing to do with the function NormalizeDouble() at all.
Try to run this script to replicate the problem:
To get the internal representation of a floating-point number, use my script IEEE Floating-Point Decoder
https://www.mql5.com/en/code/19978
For further reading:
woa i'm speechless! never knew about that and I would have never arrived to that conclusion. I'm going to read more about it tho it feels i'm going to open up a can of worms.
also your coding did work exactly as explained.
many thanks for the spot on explanation much appreciated!
also thanks to the others who took time to reply
woa i'm speechless! never knew about that and I would have never arrived to that conclusion. I'm going to read more about it tho it feels i'm going to open up a can of worms.
also your coding did work exactly as explained.
many thanks for the spot on explanation much appreciated!
also thanks to the others who took time to reply
The trade server uses the same logic as your processor, so 0.07000000000000001 lot will be executed as intended.
oh yes i guess come to think of it they speak the same language...thats another deduction i haven't arrived upon on my own! ugh
cheers tho!
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
hi all
I'm writing some code to calcualate lot size and then i'm using normalize to keep up to 2 decimals.
It's working fine except for the value 7 as shown below.
it happens in any time frame and any currency pair.
I've seen normalisedouble failing a couple of other times with other calculated values (not related to lot) when using it as a comment/print and running it through a whole chart, so i'm not sure if its a bug or just hit and miss randomly