Question aux maîtres du MQL4. Encore une fois à propos de Double Comparaison. - page 2

Nouveau commentaire
 
Encore une fois.

Prix, lots, argent - précision fixe.
Les indicateurs sont flottants.

Cette différence est essentielle, bien que le double soit utilisé pour représenter les deux. Il détermine en fait ce que vous appelez le "style de programmation".
Encore une fois, le critère de "justesse" est différent pour chacun. À ma connaissance, par exemple, NormalizeDouble() est une fonction ridiculement inefficace et, par conséquent, absolument 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 ) );
}
Le code est clair, et votre exemple est très illustratif ! Et celui-ci est une anomalie.
nd( MathPow( 0.1, precision ), precision )
ne serait-il pas préférable de le remplacer par
//--- Если 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 );
}
Ou c'est faux ?
 
Irtron:
Le problème de la comparaison des chiffres en double précision est tiré par les cheveux et provient d'une ignorance fondamentale des mathématiques.
Mais avec une persistance enviable, il apparaît sur le forum.
Soit vous donnez des instructions claires sur la façon de résoudre ce "problème", soit l'un des deux =)

Irtron:
Mais il y aura des problèmes de performance.
Des suggestions (au niveau de l'utilisateur, pas du développeur MT) ?
 
komposter:
Des suggestions (au niveau de l'utilisateur, pas du développeur MT) ?
Pour le prix, par exemple. Enchérit, là, demande, arrête :
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Il est souvent préférable de faire tous les calculs de lots et de niveaux en nombres entiers. Beaucoup plus rapide et sans erreur d'échantillonnage en principe.
 
Irtron:
Encore une fois.

Prix, lots, argent - précision fixe.
Les indicateurs sont flottants.

Cette différence est essentielle, bien que le double soit utilisé pour représenter les deux. Il détermine en fait ce que vous appelez le "style de programmation".
Encore une fois, le critère de "justesse" est différent pour chacun. À ma connaissance, par exemple, NormalizeDouble() est une fonction ridiculement inefficace et, par conséquent, absolument inutile.
Récemment, dans un fil de discussion (je ne me souviens pas exactement), une personne s'est plainte du fonctionnement étrange de l'Expert Advisor. Et il s'est avéré que même le prix relevé par le serveur pour sa commande doit encore être normalisé !
Après cela, j'ai simplement adopté NormalizeDouble() comme procédure obligatoire. Je n'ai pas encore bien compris comment le code fonctionne parfois, c'est pourquoi je m'intéresse à la façon dont cela devrait être fait.
Et quelle approche suggérez-vous à la place de NormalizeDouble() ?
 
Irtron:
komposter:
Des suggestions (au niveau de l'utilisateur, pas du développeur MT) ?
Pour le prix, par exemple. Enchérit, là, demande, arrête :
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Il est souvent préférable de faire tous les calculs de lots et de niveaux en nombres entiers. Beaucoup plus rapide et sans erreur d'échantillonnage en principe.
Je suis d'accord, dans Omega tout était en INT. Suggérez-vous de convertir d'abord tout ce qui est en MT en INT, puis de calculer ?
P.S. Et votre ComparePrice est une solution très intéressante, je ne l'ai même pas compris tout de suite.
ComparePriceComparePrice
 
Irtron:
Encore une fois.

Prix, lots, argent - précision fixe.
Les indicateurs sont flottants.

Cette différence est essentielle, bien que le double soit utilisé pour représenter les deux. Il détermine en fait ce que vous appelez le "style de programmation".
Encore une fois, le critère de "justesse" est différent pour chacun. À ma connaissance, par exemple, NormalizeDouble() est une fonction ridiculement inefficace et, par conséquent, absolument inutile.

Tout d'abord, écrivez plusieurs Expert Advisors sur votre propre ordre et sentez la tempête de vos clients parce que le stop loss s'est soudainement avéré être faux d'un point... Et ensuite, expliquez-leur l'absurdité de la fonction NormalizeDouble(), je me demande comment cela va se passer pour vous=)
 
VBAG:
Et il s'avère que même le prix extrait du serveur de votre commande doit encore être normalisé ! !!
Peu probable (c). Les boyaux de MT sont presque impossibles à normaliser.
Il y a eu et il y a encore beaucoup de discussions sur les performances incompréhensibles de l'EA lorsqu'il est testé sur des données historiques incompréhensibles.
 
Irtron:
Pour le prix, par exemple. Enchérit, là, demande, arrête :
C'est déjà quelque chose. C'est de plus en plus précis ;)
Si vous comparez les prix, vous n'avez pas besoin d'une fonction aussi surchargée que la mienne.

Et sous une forme simplifiée, il fonctionne aussi rapidement que 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:

Tout d'abord, écrivez quelques Expert Advisors sur votre propre ordre, sentez la tempête des clients parce que le stop-loss s'est soudainement avéré être 1 pip faux.... Et ensuite, expliquez-leur l'absurdité de la fonction NormalizeDouble(), je me demande comment cela va se passer pour vous=)

Laissez-moi vous dire un secret.
J'ai écrit beaucoup plus de conseillers-experts personnalisés que nécessaire pour commencer. Je n'ai jamais ressenti le besoin de les acheter car je n'ai jamais eu de raison de le faire. Dans mes programmes, le stoploss est garanti (et non pas "semble") là où il devrait être. Par conséquent, je n'ai pas à expliquer quoi que ce soit de ce genre au client, surtout en ce qui concerne une fonction très spécifique. Il me semble que le but de l'écriture d'une EE est de se débarrasser de ces questions et explications pour le client.
123456789...11
Nouveau commentaire