# double numbers problem

```double NORMALIZE(double DOUBLE)
{
return round(DOUBLE/0.01)*0.01;
}

VOLUME=MathPow(FACTOR,PositionsTotal()-2)*(MathPow(FACTOR,2)-1)*P.Volume();
// result : 0.6333333333333334

// result : 0.63

VOLUME=NORMALIZE(MathPow(FACTOR,PositionsTotal()-2)*(MathPow(FACTOR,2)-1)*P.Volume());

// result : 0.6333333333333334     why not 0.63?

```

why last line doesnt work?

Elsa Hejazian: why last line doesnt work?

Problems with division especially when there's 7

William Roeder, 2021.06.15 14:43

Floating-point has an infinite number of decimals, it's you, not understanding floating-point and that some numbers can't be represented exactly. (like 1/10.s)
Double-precision floating-point format - Wikipedia

If you want to see the correct number of digits, convert it to a string with the correct/wanted accuracy.
question about decima of marketinfo() - MQL4 programming forum 2016.05.18

Elsa Hejazian: why last line doesnt work?

Floating-point has an infinite number of decimals, it's you, not understanding floating-point and that some numbers can't be represented exactly. (like 1/10.s)
Double-precision floating-point format - Wikipedia

If you want to see the correct number of digits, convert it to a string with the correct/wanted accuracy.
question about decima of marketinfo() - MQL4 programming forum 2016.05.18

A double precision floating point number is just a binary approximation to the true real value. There is always this sort of roundoff errors. It is a drawbabk of the binary (base 2) floating point format, and you have to deal with it.

For precision. It so not a drawback by the binary representation.

It is the nature of real numbers.

As an example, try to think of the smallest possible number above 0.

As you can see, the "issue" is also within your brain. It is the natural limitation given by the universe we live in.

It has nothing to do with the representation.

The representation only defines the finite granularity, here limited to 64 bit. And therefore the result of the "rounding process" is based on the granularity of the underlying representation. In this case it's a Base2 representation. But the granularity is given with any representation.

There is no way out.

0.63 is a finite decimal fraction. It can be represented exactly if MQL5 has support for decimal (base 10) floating point type. What I meant that using base 2 has drawbacks of not being able to represent the numbers the way humans do (base 10).

Of course we all know that 1/3 cannot be represented and this is not an issue in itself.

Yes. You are right. I understud the quantity of numbers.
Reason: