NormalizeDouble is working always...except for values of 7.xxx

[zelda_lee]

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

[Sardion Maranatha]

zelda_lee:

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

[amrali]

zelda_lee:

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:

https://www.wikiwand.com/en/Floating-point_arithmetic

https://floating-point-gui.de/

[Icham Aidibe]

zelda_lee:

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

[zelda_lee]

amrali:

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:

https://www.wikiwand.com/en/Floating-point_arithmetic

https://floating-point-gui.de/

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

[amrali]

zelda_lee:

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. 

[zelda_lee]

amrali:
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!