Question to the MQL4 masters. Again about Double Compare. - page 2

New comment
 
Once again.

Prices, lots, money - fixed precision.
Indicators are floating.

This difference is in essence, although double is used to represent both. It actually determines what you call "programming style".
Again, everyone's criterion for "correctness" is different. To my understanding, for example, NormalizeDouble() is a ridiculously inefficient and, consequently, absolutely unnecessary function.
 
komposter:
//--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false.
bool equal( double value1, double value2, int precision = 8 )
{
    return( nd( abs( nd( value1, precision ) - nd( value2, precision ) ), precision ) < nd( MathPow( 0.1, precision ), precision ) );
}
The code is clear, and your example is very illustrative! And this one is a blip.
nd( MathPow( 0.1, precision ), precision )
wouldn't it be better to replace it with
//--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false.
bool equal( double value1, double value2, int precision = 8 )
{
    return( nd(nd( abs( nd( value1, precision ) - nd( value2, precision ) ), precision )), precision ) == 0.0 );
}
Or is it wrong?
 
Irtron:
The problem of comparing numbers to double precision is far-fetched and comes from basic ignorance of the math.
But with enviable persistence it comes up on the forum.
Either give clear instructions on how to solve this "problem", or one of the two =)

Irtron:
But there will be performance problems.
Any suggestions (user level, not MT developer level)?
 
komposter:
Any suggestions (user level, not MT developer level)?
For price, for example. Bids, there, asks, stops:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
It is often better to do all lot and level calculations in whole numbers. Many times faster and without sampling errors in principle.
 
Irtron:
Once again.

Prices, lots, money - fixed precision.
Indicators are floating.

This difference is in essence, although double is used to represent both. It actually determines what you call "programming style".
Again, everyone's criterion for "correctness" is different. To my understanding, for example, NormalizeDouble() is a ridiculously inefficient and, consequently, absolutely unnecessary function.
Recently, in some thread (I do not remember exactly), a person was complaining about the strange operation of the Expert Advisor. And it turned out that even the price taken from the server for his order still needs to be normalized!
After that, I have simply adopted NormalizeDouble() as a mandatory procedure. I really do not yet have a good understanding of how the code sometimes works, that's why I am interested in how it should be done.
And what approach do you suggest instead of NormalizeDouble()?
 
Irtron:
komposter:
Any suggestions (at user level, not MT developer level)?
For price, for example. Bids, there, asks, stops:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
It is often better to do all lot and level calculations in whole numbers. Many times faster and without sampling errors in principle.
I agree, in Omega everything was in INT. Are you suggesting to convert everything in MT to INT first, and then calculate?
P.S. And your ComparePrice is a very interesting solution, I didn't even get it right away.
ComparePriceComparePrice
 
Irtron:
Once again.

Prices, lots, money - fixed precision.
Indicators are floating.

This difference is in essence, although double is used to represent both. It actually determines what you call "programming style".
Again, everyone's criterion for "correctness" is different. To my understanding, for example, NormalizeDouble() is a ridiculously inefficient and, consequently, absolutely unnecessary function.

First, write several Expert Advisors on your own order and feel the storm of your customers because the stop loss has suddenly turned out to be 1 point wrong... And then explain to them about the absurdity of NormalizeDouble() function, I wonder how it will work out for you=)
 
VBAG:
And it turns out that even the price taken from the server from your order still needs to be normalised!!!
Not likely (c). The MT guts are almost impossible to normalize.
There were and are a lot of talks about incomprehensible performance of the EA when tested on incomprehensible historical data.
 
Irtron:
For price, for example. Bids, there, asks, stops:
That's something already. It is getting more specific ;)
If you take price comparison, you don't need such an overloaded function as I have.

And in simplified form it works as fast as ComparePrice:
int start()
{
    double a = 1.23450001, b = 1.23449999;
    int start1 = GetTickCount(), c1;
    for ( c1 = 0; c1 < 100000000; c1 ++ ) ComparePrice( a, b );
    int end1 = GetTickCount();
    
    int start2 = GetTickCount(), c2;
    for ( c2 = 0; c2 < 100000000; c2 ++ ) equal( a, b );
    int end2 = GetTickCount();
 
    Print( "ComparePrice: ", (end1-start1), ", equal: ", (end2-start2) );
 
    return(0);
}
 
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
 
bool equal( double a, double b )
{
    return( MathAbs( a - b ) < Point );
}
2007.09.10 03:19:24 CheckCompareDoubleSpeed GBPUSD,Daily: ComparePrice: 20922, equal: 20453
 
Integer:

First, write a few Expert Advisors on your own order, feel the storm of customers because the stop-loss suddenly turned out to be 1 pip wrong... And then explain them about absurdity of NormalizeDouble() function, I wonder how it will work out for you=)

Let me tell you a secret.
I have written many more custom Expert Advisors than needed to start with. I have never felt the urge to buy them because I have never gave any reason to do so. In my programs, the stoploss is guaranteed to be (and not "appears") where it should be. Accordingly, I don't have to explain anything of the kind to the customer, especially about some very specific function. It seems to me that the whole point of writing an EA is to get rid of such questions and explanations for the client.
123456789...11
New comment