Rounding numbers in MT4 via NormalizeDouble - page 14

New comment
 

Made functions for rounding off the bottom and top once upon a time

Might help someone

//+------------------------------------------------------------------+
double RoundMax(double price,double symbol_point,int symbol_digits)
  {
   return(NormalizeDouble(price+MyK(price,symbol_point,symbol_digits)*symbol_point, symbol_digits-1));
  }
//+------------------------------------------------------------------+
double RoundMin(double price,double symbol_point,int symbol_digits)
  {
   return(NormalizeDouble(price-MyK(price,symbol_point,symbol_digits)*symbol_point, symbol_digits-1));
  }
//+------------------------------------------------------------------+
int MyK(double price,double symbol_point,int symbol_digits)
  {
   double tmp1=NormalizeDouble(price, symbol_digits);
   double tmp2=NormalizeDouble(price, symbol_digits-1);
   return((MathAbs(tmp1-tmp2)<symbol_point)?10:5);
  }
//+------------------------------------------------------------------+
 
Victor Nikolaev:

Made functions for rounding off the bottom and top once upon a time

Might help someone

Thanks, I'll get it for my collection.
 
lilita bogachkova:

try to get a result of0.9999999999999999999

X = 0.99999999999999999

10*X = 10*0.99999999999999999

10*X-X = 10*0.999999999999999-0.9999999999999

9*X = 9*0.99999999999999999

we get 9*X = 9 or X equals 1 (one)

v1 = (1/3) = 0.33333333 | v2 = 3*(1/3) = 1.00000000

or 0.999999999999999 = 1.0

v1 (1.00000000) >= 1.0

In this case, 0.9999999999999999999999 represents 1.0. But the task is to "discard", so the result must include nines.
 

Thank you all for the helpful thread!

I've chosen the solution of rounding 1 digit more viaNormalizeDouble, and then trimming the last digit. So far, it's completely suitable.

 

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?

second question - as i understand it will be enough for me to do the second normalization to avoid tails?

Third question (I feel that I won't understand it anyway, but I'll ask anyway):

can addition of two normalized numbers give non-normalized numbers?

P.S. I apologize for bringing this up again, but I just don't have the strength to re-read it all again


 
transcendreamer:

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?

second question - as i understand it will be enough for me to do the second normalization to avoid tails?

Third question (I feel that I won't understand it anyway, but I'll ask anyway):

can addition of two normalized numbers give non-normalized numbers?

P.S. Pardon me for bringing it up again, but I just don't have energy to reread it all

  1. Yes.
  2. Yes.
  3. Yes.
 
fxsaber:
  1. Yes.
  2. Yes.
  3. Yes.
Thank you
 
transcendreamer:

P.S. I apologise for bringing this up again, but I just don't have the energy to go through it all again

It's better to check it yourself with different examples, it will give you an understanding.

The only thing is, I'm doing it wrong:

if(delta>0)

but like this.

if(delta>0.0)

For double numbers. I don't know if it really matters, but with my variant I never encountered an error (I try to compare only the same types of variables).

 
Andrey Dik:

I don't know if it really matters, but I've never encountered an error with my version (I only try to compare the same types of variables).

It doesn't.
 
Some numbers can only be represented as an infinite fraction, e.g. 1/3 in the decimal system. But 1/3 is not an infinite fraction in the tertiary system, there it == 0.1. That is, different number systems have their own infinite fractions. Hence, a non-infinite fraction in decimal can be one in binary. For example: 0.1, 0.2, 0.3, 0.4, ... have no exact binary representation. If you call NormalizeDouble ten times, it will be either 0.19999999999...1 or 0.200000...1. I don't know, maybe this is news.
1...7891011121314151617
New comment