Frage an die MQL4-Meister. Nochmals zu Double Compare. - Seite 2

Neuer Kommentar
 
Noch einmal.

Preise, Partien, Geld - feste Präzision.
Die Indikatoren sind frei beweglich.

Dieser Unterschied besteht im Wesentlichen darin, dass double verwendet wird, um beides darzustellen. Sie bestimmt, was Sie als "Programmierstil" bezeichnen.
Auch hier gilt, dass jeder ein anderes Kriterium für "Korrektheit" hat. Meines Erachtens ist zum Beispiel NormalizeDouble() eine lächerlich ineffiziente und folglich absolut unnötige Funktion.
 
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 ) );
}
Der Code ist klar, und Ihr Beispiel ist sehr anschaulich! Und das hier ist ein Eklat.
nd( MathPow( 0.1, precision ), precision )
Wäre es nicht besser, ihn zu ersetzen durch
//--- Если 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 );
}
Oder ist das falsch?
 
Irtron:
Das Problem des Vergleichs von Zahlen mit doppelter Genauigkeit ist weit hergeholt und beruht auf grundlegender Unkenntnis der Mathematik.
Aber mit beneidenswerter Hartnäckigkeit taucht es im Forum auf.
Entweder geben Sie klare Anweisungen, wie dieses "Problem" zu lösen ist, oder eines von beiden =)

Irtron:
Aber es wird Leistungsprobleme geben.
Gibt es Vorschläge (auf Benutzerebene, nicht auf MT-Entwicklerebene)?
 
komposter:
Gibt es Vorschläge (auf Benutzerebene, nicht auf MT-Entwicklerebene)?
Zum Beispiel beim Preis. Gebote, da, fragt, stoppt:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Oft ist es besser, alle Berechnungen für Partien und Ebenen in ganzen Zahlen durchzuführen. Im Prinzip um ein Vielfaches schneller und ohne Stichprobenfehler.
 
Irtron:
Noch einmal.

Preise, Partien, Geld - feste Präzision.
Die Indikatoren sind frei beweglich.

Dieser Unterschied besteht im Wesentlichen darin, dass double für beides verwendet wird. Sie bestimmt, was Sie als "Programmierstil" bezeichnen.
Auch hier gilt, dass jeder ein anderes Kriterium für "Korrektheit" hat. Meines Erachtens ist zum Beispiel NormalizeDouble() eine lächerlich ineffiziente und folglich absolut unnötige Funktion.
Vor kurzem beschwerte sich eine Person in einem Thread (ich erinnere mich nicht genau) über die seltsame Funktionsweise des Expert Advisors. Und es stellte sich heraus, dass sogar der Preis, der vom Server für seine Bestellung genommen wurde, noch normalisiert werden muss!
Danach habe ich einfach NormalizeDouble() als obligatorisches Verfahren übernommen. Ich habe wirklich noch kein gutes Verständnis dafür, wie der Code manchmal funktioniert, deshalb bin ich daran interessiert, wie es gemacht werden sollte.
Und welchen Ansatz schlagen Sie anstelle von NormalizeDouble() vor?
 
Irtron:
komposter:
Gibt es Vorschläge (auf Benutzerebene, nicht auf MT-Entwicklerebene)?
Zum Beispiel beim Preis. Gebote, da, fragt, stoppt:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Oft ist es besser, alle Berechnungen für Partien und Ebenen in ganzen Zahlen durchzuführen. Im Prinzip um ein Vielfaches schneller und ohne Stichprobenfehler.
Ich stimme zu, in Omega war alles in INT. Schlagen Sie vor, zuerst alles in MT in INT umzuwandeln und dann zu berechnen?
P.S. Und Ihr ComparePrice ist eine sehr interessante Lösung, ich habe sie nicht einmal auf Anhieb verstanden.
ComparePriceComparePrice
 
Irtron:
Noch einmal.

Preise, Partien, Geld - feste Präzision.
Die Indikatoren sind frei beweglich.

Dieser Unterschied besteht im Wesentlichen darin, dass double verwendet wird, um beides darzustellen. Sie bestimmt, was Sie als "Programmierstil" bezeichnen.
Auch hier gilt, dass jeder ein anderes Kriterium für "Korrektheit" hat. Meines Erachtens ist zum Beispiel NormalizeDouble() eine lächerlich ineffiziente und folglich absolut unnötige Funktion.

Schreiben Sie zunächst mehrere Expert Advisors auf Ihre eigene Order und spüren Sie den Windsturm Ihrer Kunden, dass der Stop-Loss plötzlich um 1 Punkt falsch war... Und dann erklären Sie ihnen die Absurdität der Funktion NormalizeDouble(), ich frage mich, wie es für Sie funktionieren wird=)
 
VBAG:
Und es stellt sich heraus, dass sogar der Preis, der vom Server von Ihrer Bestellung genommen wird, noch normalisiert werden muss!!!
Unwahrscheinlich (c). Die MT-Eingeweide sind fast unmöglich zu normalisieren.
Es wurde und wird viel über die unfassbare Performance des EA bei Tests mit unfassbaren historischen Daten gesprochen.
 
Irtron:
Zum Beispiel beim Preis. Gebote, da, fragt, stoppt:
Das ist schon etwas. Es wird immer konkreter ;)
Wenn Sie einen Preisvergleich machen, brauchen Sie nicht so eine überladene Funktion wie ich sie habe.

Und in vereinfachter Form funktioniert es genauso schnell wie 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: Vergleichskurs: 20922, gleich: 20453
 
Integer:

Schreiben Sie zunächst ein paar Expert Advisors auf Ihre eigene Order, spüren Sie den Sturm der Kunden, weil sich der Stop-Loss plötzlich als 1 Pip falsch herausstellt... Und dann erklären Sie ihnen die Absurdität der Funktion NormalizeDouble(), ich frage mich, wie es für Sie funktionieren wird=)

Ich will Ihnen ein Geheimnis verraten.
Ich habe viel mehr benutzerdefinierte Expert Advisors geschrieben, als ich anfangs brauchte. Ich habe nie den Drang verspürt, sie zu kaufen, weil ich nie einen Grund dazu hatte. In meinen Programmen ist der Stoploss garantiert dort, wo er sein soll (und nicht "erscheint"). Dementsprechend muss ich dem Kunden nichts erklären, schon gar nicht eine ganz bestimmte Funktion. Mir scheint, dass der Sinn der Erstellung eines EA darin besteht, dem Kunden solche Fragen und Erklärungen zu ersparen.
123456789...11
Neuer Kommentar