CompareDoubles - a 'security question'

New comment
 

I have read avout the problems of CompareDoubles.

But would it be safe (and faster) NOT to use the coorect way: if( NoramlizeDouble(doubleValue,8)<0.0) ... if I only check the sign:

if (doubleValue < 0.0) Alert("negative"); else Alert("not negative");

Thanks in advance,

Carl

 
NormaizeDouble is not the correct way and it can also give you the wrong result . . . understand the issue, solve it in the way that is best for you. My solution was to convert both values to ints (after multiplying up) and then comparing the ints . . .
 

Yeah man.... Converting to Int works wonders. I had this code thing which seemed stupid but after awhile I'm realizing how nice it is.

if(StringFind(Symbol(),"JPY")>-1){int _2Real=100;}else{_2Real=10000;}

Changes any Price on any Digit broker to Integer_Pips. And then get used to working in Integer Pips.

 

converting them to int is not very accurate because the doubles are rounded up or down in the first decimal place.

 
SDC:

converting them to int is not very accurate because the doubles are rounded up or down in the first decimal place.

We need accuracy to the Digits digit.
 
SDC:

converting them to int is not very accurate because the doubles are rounded up or down in the first decimal place.

I imagine they were first multiplied by 100000 or some such value, since converting 1.23425 to an int would not give much useful information :-)
 
SDC:

converting them to int is not very accurate because the doubles are rounded up or down in the first decimal place.

There is need for conversion to ints for arrays indexes and exact comparison in many(more) cases, exact double search is paradox on more decimals (endless), ie. exact return can't be done with doubles (+- is not nN dna).

Files:
farraysxn.mq4  3 kb
testing.mq4  5 kb
 

Hm,

in order to be fast and slim I made this:

#define  _EQ 0  // equal
#define  _NE 1  // not equal
#define  _GE 2  // greater or equal
#define  _GT 3  // greater than
#define  _LE 4  // less or equal
#define  _LS 5  // lesss than
#define  _ZERO 0.0000001

// usage: if ( dC( a, _EQ, b ) ) { ...
bool dC(double d1, int comp, double d2){
        switch (comp){
                case _EQ: retrun( MathAbs(a-b) < _ZERO );
                case _NE: return( MathAbs(a-b) > _ZERO );

                case _GE: return( (a-b) > -_ZERO );
                case _GT: return( (a-b) >  _ZERO );

                case _LE: return( (b-a) > -_ZERO );
                case _LS: return( (b-a) >  _ZERO );
                default: return(false);
        }
}

I guess / hope it'l do it and its faster than the others. Am I right?

Thanks, Gooly

  
  1. case _EQ: if ( MathAbs(d1-d2) < _ZERO ) return(true); else return(false);
    return(true) else return(false) is unnecessary
    case _EQ: return( MathAbs(d1-d2) < _ZERO );
  2. Your zero may generally work for prices (but not for indicator values.) The double value from the broker could be anywhere from 1.234575000000000000 through 1.23458499999999999 and still be considered the same 1.23458 price. This is why I used Point/2 for prices. For a 0-100 indicator I'd define epsilon as 1/100 * 10%
  3. Why use the overhead of a function call instead of a plain readable IF.
  4. Also remember, these cases are only necessary when the equal/not-equal case is important in the presence of roundoff. Your original question was if(aDouble < 0) Do you really care if the calculation was essentially zero but rounded down to negative? Do you really want the IF to function randomly near zero? Shouldn't the code be if(aDouble < -0.0001) .. else if (aDouble > 0.0001) .. such as when the aDouble is a slope (e.i. pips/bar.)
 

I changed my code acc. to 1.) - you were right!

2.hmm. If you calc (smallets pip-size I know) 0.00001*0.00001 you get 0.0000000001. It may be use full to reduce _ZERO

3. This I don't understand, what do you mean? IF will not be a function or just 

bool IF(double a, int c, double b) { ... }

Then you will have

if( IF(x,_EQ, y)){ .. }

4. You are right, my guess was that there is a signature bit to be check, but an calculation result of - 0.0000000000001 would be negative and not 0.0, if that is important!

12
New comment