Domanda ai maestri di MQL4. Di nuovo a proposito di Double Compare. - pagina 2

Nuovo commento
 
Ancora una volta.

Prezzi, lotti, soldi - precisione fissa.
Gli indicatori sono fluttuanti.

Questa differenza è in sostanza, anche se il doppio è usato per rappresentare entrambi. In realtà determina quello che voi chiamate "stile di programmazione".
Di nuovo, il criterio di "correttezza" di ognuno è diverso. Per quanto ne so, per esempio, NormalizeDouble() è una funzione ridicolmente inefficiente e, di conseguenza, assolutamente inutile.
 
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 ) );
}
Il codice è chiaro, e il tuo esempio è molto illustrativo! E questo è un blip.
nd( MathPow( 0.1, precision ), precision )
non sarebbe meglio sostituirlo con
//--- Если 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 );
}
O è sbagliato?
 
Irtron:
Il problema di confrontare i numeri a doppia precisione è inverosimile e viene dall'ignoranza di base della matematica.
Ma con una persistenza invidiabile viene fuori sul forum.
O dai istruzioni chiare su come risolvere questo "problema", o uno dei due =)

Irtron:
Ma ci saranno problemi di prestazioni.
Qualche suggerimento (livello utente, non livello sviluppatore MT)?
 
komposter:
Qualche suggerimento (a livello di utente, non di sviluppatore MT)?
Per il prezzo, per esempio. Offre, c'è, chiede, si ferma:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Spesso è meglio fare tutti i calcoli di lotto e di livello in numeri interi. Molte volte più veloce e senza errori di campionamento in linea di principio.
 
Irtron:
Ancora una volta.

Prezzi, lotti, soldi - precisione fissa.
Gli indicatori sono fluttuanti.

Questa differenza è in sostanza, anche se il doppio è usato per rappresentare entrambi. In realtà determina quello che voi chiamate "stile di programmazione".
Di nuovo, il criterio di "correttezza" di ognuno è diverso. Per quanto ne so, per esempio, NormalizeDouble() è una funzione ridicolmente inefficiente e, di conseguenza, assolutamente inutile.
Recentemente, in qualche thread (non ricordo esattamente), una persona si lamentava dello strano funzionamento dell'Expert Advisor. E si è scoperto che anche il prezzo preso dal server per il suo ordine deve ancora essere normalizzato!
Dopo di che, ho semplicemente adottato NormalizeDouble() come procedura obbligatoria. In realtà non ho ancora una buona comprensione di come funziona il codice a volte, ecco perché sono interessato a come dovrebbe essere fatto.
E quale approccio suggerisci invece di NormalizeDouble()?
 
Irtron:
komposter:
Qualche suggerimento (a livello di utente, non di sviluppatore MT)?
Per il prezzo, per esempio. Offre, c'è, chiede, si ferma:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Spesso è meglio fare tutti i calcoli di lotto e di livello in numeri interi. Molte volte più veloce e senza errori di campionamento in linea di principio.
Sono d'accordo, in Omega tutto era in INT. Stai suggerendo di convertire tutto in MT in INT prima, e poi calcolare?
P.S. E il tuo ComparePrice è una soluzione molto interessante, non l'ho nemmeno capito subito.
ComparePriceComparePrice
 
Irtron:
Ancora una volta.

Prezzi, lotti, soldi - precisione fissa.
Gli indicatori sono fluttuanti.

Questa differenza è in sostanza, anche se il doppio è usato per rappresentare entrambi. In realtà determina quello che voi chiamate "stile di programmazione".
Di nuovo, il criterio di "correttezza" di ognuno è diverso. Per quanto ne so, per esempio, NormalizeDouble() è una funzione ridicolmente inefficiente e, di conseguenza, assolutamente inutile.

Prima, scrivi diversi Expert Advisors sul tuo ordine e senti la tempesta dei tuoi clienti perché lo stop loss si è rivelato improvvisamente sbagliato di 1 punto... E poi spiegare loro l'assurdità della funzione NormalizeDouble(), mi chiedo come funzionerà per voi=)
 
VBAG:
E si scopre che anche il prezzo preso dal server dal tuo ordine deve ancora essere normalizzato!!!
Poco probabile (c). Le budella MT sono quasi impossibili da normalizzare.
Si è parlato e si parla molto di prestazioni incomprensibili dell'EA quando viene testato su dati storici incomprensibili.
 
Irtron:
Per il prezzo, per esempio. Offre, c'è, chiede, si ferma:
È già qualcosa. Sta diventando più specifico ;)
Se prendete il confronto dei prezzi, non avete bisogno di una funzione così sovraccarica come la mia.

E in forma semplificata funziona velocemente come 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:

Per prima cosa, scrivi qualche Expert Advisors sul tuo ordine, senti la tempesta dei clienti perché lo stop-loss si è rivelato improvvisamente 1 pip sbagliato... E poi spiegare loro l'assurdità della funzione NormalizeDouble(), mi chiedo come funzionerà per voi=)

Lasciate che vi dica un segreto.
Ho scritto molti più Expert Advisor personalizzati di quelli necessari per iniziare e non ho mai sentito il bisogno di comprarli perché non ho mai dato motivo di farlo. Lo stoploss nei miei programmi è garantito per essere (e non "appare") dove dovrebbe essere. Di conseguenza, non devo spiegare niente del genere al cliente, specialmente su qualche funzione molto specifica. Mi sembra che l'intero scopo di scrivere un EA sia quello di sbarazzarsi di tali domande e spiegazioni per il cliente.
123456789...11
Nuovo commento