
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
Obsolete
The standard library has a granularity-aware price normalisation function
The standard library has a granularity-aware price normalisation function
I was beginning to guess that NormalizeDouble(new_lot-sum_lots,Lots_Digits); it doesn't output exactly 0 and stores some tail
If variables new_lot and sum_lots are equal, then the difference is exactly 0. But it is unknown how you calculate them, they may indeed be unequal when calculated, hence the non-zero difference. Do the same thing like this:
NormalizeDouble(new_lot, Lots_Digits) - NormalizeDouble(sum_lots, Lots_Digits).
If variables are equal within specified number of digits, then the difference will be strictly 0.
If variables new_lot and sum_lots are equal, then the difference is exactly 0. But it is unknown how you calculate them, they may indeed be unequal when calculated, hence the non-zero difference. Do the same thing like this:
NormalizeDouble(new_lot, Lots_Digits) - NormalizeDouble(sum_lots, Lots_Digits).
If the variables are equal within the specified number of digits, the difference will be strictly 0.
Again about rounding......
Please advise on the situation (don't throw tomatoes, I'm a humanitarian),
there is such a variable:
double delta=NormalizeDouble(new_lot-sum_lots,Lots_Digits);
if(delta>0) delta-=OrderLots();
if(delta<0) delta+=OrderLots();
The delta is originally normalized,
OrderLots should probably return normalized dubs,
but somehow sometimes on rare occasions I get numbers like 2.775557561562891e-17
So it's almost zero but not zero.......
first question - is this normal?
...
I read it again carefully. It's not normal. If NormalizeDouble function operation :
- The integer part is selected - I
- Fractional part is selected - F
- F = F * 10^digits
- F = F (+ or - depending on the sign) 0.5
- F = (integer part of F) / 10^digits
- result = I + F
then also theNormalizeDouble(new_lot - sum_lots, Lots_Digits) resultshould be strictly zero if new_lot and sum_lots are equal within the specified number of digits. In rare cases there may be a difference of 1 in the last digit (the reason is in items 4 and 5), but the result 2.775557561562891e-17 is strange, it should not be.I wrote a little tutorial code (I was interested in poking around myself) that turns out the innards of a floating number. If anyone is interested, you can run it (C++ code, you can use some online compiler. Here https://goo.gl/tP691X, for example)
The output at f == 0.5 + 1/(2^24). 1/(2^24) is the least significant digit of the mantissa at a given degree:
Degree = 126 - 127 = -1
mantissa = 1.0000000000000000000000001
Shift the mantissa to degree -1 = 0.1000000000000000000001 = 1^(-1) + 1^(-24) = 1/(2^1) + 1/(2^24) = 0.5 + 0.00000005960464478 = 0.50000005960464478
As a theory https://habrahabr.ru/post/112953/.
SZZ: this online compiler is nicer than http://rextester.com/l/cpp_online_compiler_gcc
I wrote a little tutorial code (I was interested in poking around myself) that turns out the innards of a floating number. If anyone is interested, you can run it (C++ code, you can use some online compiler. Here https://www.tutorialspoint.com/compile_cpp11_online.php, for example)
You can also run it in MQL5 - replace c[Pos] with _R(f)[(char)Pos] (or _R(f).Bytes[Pos]) by connecting this library.
SZ
Result
What happened to the mantissa?
32 is the ascii code of the problem. It looks like the library with the error does not have a char version. I think we need to remove the problems between mantissa values. Or maybe instead of ' ' write " "?
What happened to the mantissa?
32 is the ascii code of the problem. It looks like a library with a bug. I think we need to remove the problems between mantissa values. Or maybe instead of ' ' write " "?
The fmtprntl.mqh is not mine, so I can't say for sure.
I don't want to bother, so for your f printed byte values
A related side effect.
It turned out to be convenient. But it was not originally intended to be used in this way.
There are special functions for printing real numbers with the required accuracy.
Tell me why you need to round real numbers in the calculation process? Because in this case, you lose calculation accuracy!
We are talking about the correct comparison of prices, stops, lots
You need a certain accuracy here.