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

New comment
 
Integer:
VBAG take a look at this script
And you work nights too, thanks for the support, now I have to digest it all.
 
Integer:

price = 1.1111

ma = 1.11110001

When normalised to 8 digits ma>price is correct. Normalizing to fewer digits will result in equal - incorrect. This is how maximum accuracy is achieved.

It's a joke, isn't it? :)
In general, without normalising ma > price is also the right thing to do. Why achieve maximum accuracy when it is already there, and already known to be greater than achievable?

Normalizing to 9 digits does not work. The impression is that the price is sort of 9 digits and the indictor has 8 or vice versa (I do not remember), in short it is covered by the mystery of the unknown.


Yes, most likely, it's in NormalizeDouble itself only counts up to 8 digits. I'm telling you, it's a ridiculous function, no matter how you spin it.
 
komposter:

And in simplified form it works as fast as ComparePrice:
2007.09.10 03:19:24 CheckCompareDoubleSpeed GBPUSD,Daily: ComparePrice: 20922, equal: 20453
And in its original form it's just a song :)
int start()
{
    double a, b;
    int start1, start2, end, c;
    
    a = 1.23450001;
    b = 1.23449999;
    
    start1 = GetTickCount();
    
    for (c = 100000000; c > 0; c--)
        ComparePrice(a, b);
    
    start2 = GetTickCount();
    
    for (c = 100000000; c > 0; c--)
        equal(a, b);
    
    end = GetTickCount();
 
    Print("ComparePrice: ", start2 - start1, ", equal: ", end - 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 value1, double value2, int precision = 8)
{
    return (NormalizeDouble(MathAbs(NormalizeDouble(value1, precision) - NormalizeDouble(value2, precision)), precision) < NormalizeDouble(MathPow(0.1, precision), precision));
}
2007.09.10 02:39:57 testScript USDJPYm,H4: ComparePrice: 23843, equal: 178704
Eh, but komposter has a better car!
 
Irtron:
And in its original form, it's just a song :)
Well yes, you have to pay for versatility.
Or is ComparePrice also suitable for comparing any numbers with any given accuracy?
 
komposter:

Or is ComparePrice also suitable for comparing any numbers with any given accuracy?
Of course it does! If the accuracy is known, which is the case when working with trading values. Fixed point.
 
Irtron:
Of course! If the accuracy is known, which is the case with trading values. Fixed point.
I agree.
Only it is necessary to explain it to numerous authors of topics "about comparison of doubles".
That is why I proposed a _universal_ (but far from optimal) way of comparing.
And it works. Slowly but reliably. And in all the cases.

And when a topic "About optimization of comparison of doubles" appears we will be able to develop it ;)
 

Is price normalisation needed anywhere?

It is written in the documentation that prices in trade requests must be normalised.

In the 'Unnormalized History and Opening Positions' branch, it says the following:

Renat 16.02.2007 10:01
We have deliberately added the normalized price to trade requests in order to avoid sending inadvertently wrong prices to the server.
 
I'd like to thank all the pros for their insight!

Irtron, I chose your variant, I liked it very much. I corrected it a little for general cases and checked it:

int ComparePrice(double a, double b, double digit)
{
a -= b;
b = digit;
if (a > b)
return (1);
if (a < -b)
return (-1);
return (0);
}
Thanks.
 
With digit=0 there will be problems. Also the function is slower than a single call to NormalizeDouble()
 
Integer:
Digit=0 will cause problems.

Any digit will cause problems. I don't understand what digit is and what is the point of modification.

Integer:
Also the function is slower than a single call toNormalizeDouble().
Also it will be slower than MathAbs, 2+3 etc. :)

What's the topic of comparing functions with different functionality? One simplified (unworkable, though), now it's NormalizeDouble.
What and to whom do you want to prove with such a blatant... (insert word yourself)?
1234567891011
New comment