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

Nouveau commentaire
 
Integer:
VBAG jette un coup d'œil à ce script
Et vous travaillez de nuit aussi, merci pour le soutien, maintenant je dois digérer tout ça.
 
Integer:

prix = 1,1111

ma = 1.11110001

Lorsqu'il est normalisé à 8 chiffres, le prix est correct. La normalisation à moins de chiffres donnera un résultat égal - incorrect. C'est ainsi que l'on obtient une précision maximale.

C'est une blague, n'est-ce pas ? :)
En général, sans normaliser ma > prix est aussi la bonne chose à faire. Pourquoi rechercher une précision maximale alors qu'elle existe déjà et qu'on sait déjà qu'elle est supérieure à ce qui est réalisable ?

La normalisation à 9 chiffres ne fonctionne pas. L'impression est que le prix est en quelque sorte à 9 chiffres et l'indicateur en a 8 ou vice versa (je ne me souviens pas), bref il est couvert par le mystère de l'inconnu.


Oui, très probablement, c'est dans NormalizeDouble lui-même qui ne compte que jusqu'à 8 chiffres. Je vous le dis, c'est une fonction ridicule, peu importe comment vous la présentez.
 
komposter:

Et sous une forme simplifiée, il fonctionne aussi rapidement que ComparePrice :
2007.09.10 03:19:24 CheckCompareDoubleSpeed GBPUSD,Daily : ComparePrice : 20922, equal : 20453
Et dans sa forme originale, c'est juste une chanson :)
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, égal : 178704
Eh, mais Komposter a une meilleure voiture !
 
Irtron:
Et dans sa forme originale, c'est juste une chanson :)
Eh bien oui, vous devez payer pour la polyvalence.
Ou bien ComparePrice est-il également adapté à la comparaison de n'importe quels nombres avec une précision donnée ?
 
komposter:

Ou bien ComparePrice est-il également adapté à la comparaison de n'importe quels nombres avec une précision donnée ?
.
Bien sûr que oui ! Si la précision est connue, ce qui est le cas lorsqu'on travaille avec des valeurs commerciales. Point fixe.
 
Irtron:
Bien sûr ! Si la précision est connue, ce qui est le cas pour les valeurs commerciales. Point fixe.
Je suis d'accord.
Il faut seulement l'expliquer à de nombreux auteurs de sujets "sur la comparaison des doubles".
C'est pourquoi j'ai proposé une méthode de comparaison _universelle_ (mais loin d'être optimale).
Et ça marche. Lentement mais sûrement. Et dans tous les cas.

Et quand un sujet "Sur l'optimisation de la comparaison des doubles" apparaîtra, nous pourrons le développer ;)
 

La normalisation des prix est-elle nécessaire quelque part ?

Il est écrit dans la documentation que les prix dans les demandes commerciales doivent être normalisés.

Dans la branche "Historique non normalisé et positions d'ouverture", il est indiqué ce qui suit :

Renat 16.02.2007 10:01
Nous avons délibérément ajouté le prix normalisé aux demandes de transaction afin d'éviter d'envoyer par inadvertance des prix erronés au serveur.
 
J'aimerais remercier tous les professionnels pour leurs conseils !

Irtron, j'ai choisi votre variante, elle m'a beaucoup plu. Je l'ai corrigé un peu pour les cas généraux et je l'ai vérifié :

int ComparePrice(double a, double b, double chiffre)
{
a -= b ;
b = chiffre ;
si (a > b)
retour (1) ;
si (a < -b)
retour (-1) ;
retour (0) ;
}
Merci.
 
Avec digit=0, il y aura des problèmes. La fonction est également plus lente qu'un simple appel à NormalizeDouble().
 
Integer:
Le chiffre=0 causera des problèmes.

Tout chiffre posera des problèmes. Je ne comprends pas ce qu'est le chiffre et quel est l'intérêt de la modification.

Entier:
La fonction est également plus lente qu'un simple appel àNormalizeDouble().
Il sera également plus lent que MathAbs, 2+3, etc. :)

Quel est le sujet de la comparaison de fonctions ayant des fonctionnalités différentes ? Une fois simplifiée (mais inapplicable), maintenant c'est NormalizeDouble.
Que voulez-vous prouver et à qui voulez-vous prouver avec une telle flagrante... (insérez votre propre mot) ?
1234567891011
Nouveau commentaire