Toute question d'un PROFI à un SUPER PROFI - 1. - page 8

Nouveau commentaire
 
C-4:

Voici un exemple fonctionnel de la fonction de hachage Adler32 :

Le code de base de la fonction est tiré de wikipedia et légèrement modifié pour MQL5. Voici le résultat du script :

Comme vous pouvez le constater, toutes les valeurs renvoyées par cette fonction sont absolument différentes, bien que les chaînes de caractères elles-mêmes ne diffèrent pas beaucoup.

Pourquoi ulong et non uint ?

Et les opérations avec les tableaux dans cette fonction sont extrêmement inefficaces. Il est plus facile de modifier le code et de diviser l'unicode en deux symboles indépendants - ce sera 50 fois plus rapide.

uint adler32__(string buf)
  {
     uint s1 = 1;
     uint s2 = 0;
     uint buflength=StringLen(buf);
     ushort dat;
     for (uint n=0; n<buflength; n++)
     {
        dat = StringGetCharacter(buf, n);
        s1 = (s1 + (dat % 256)) % 65521;
        s2 = (s2 + s1)     % 65521;
        s1 = (s1 + (dat>>8)) % 65521;
        s2 = (s2 + s1)     % 65521;
     }
     return ((s2 << 16) + s1);
  }
3681 ms contre 13822 ms à 3 millions d'exécutions.... seulement 4 fois différent...... mais pas de perte de conversion
 

Oui, c'est exact, car 32 bits est un entier, pas un long. Bien que, pour être honnête, je changerais quand même la fonction de hachage pour la version 64 bits. Après tout, la probabilité de collision est moindre, et il est facile de l'ajuster pour l'expert en magie. Bien que, d'autre part, l'implémentation actuelle soit entièrement compatible avec MQL4 (car elle n'a pas de type long)

P.S. Ne serait-il pas plus rapide de convertir la chaîne de caractères en tableau uchar avant de boucler, et déjà dans la boucle, de passer une à une les valeurs du tableau ? Mais je pense qu'appeler StringGetCharacter(buf, n) à chaque fois dans la boucle est trop coûteux.

 
C-4:

Oui, c'est exact, car 32 bits est un entier, pas un long. Bien que, pour être honnête, je changerais quand même la fonction de hachage pour la version 64 bits. Après tout, la probabilité de collision est moindre, et il est facile de l'ajuster pour l'expert en magie. Cependant, d'un autre côté, l'implémentation actuelle est entièrement compatible avec MQL4 (car elle n'a pas de type long).

P.S. Ne serait-il pas plus rapide de convertir la chaîne de caractères en tableau uchar avant la boucle, et ensuite, dans la boucle, de parcourir les valeurs du tableau une par une ? Pourtant, je pense qu'appeler StringGetCharacter(buf, n) à chaque fois dans la boucle est assez coûteux.

Je comprends que cet algorithme ne peut être que 32 bits.

Et qu'en est-il de la conversion avant la boucle - comment ? Vous auriez alors besoin d'un tableau... allocation dynamique... Oui, et il y a une perte d'informations lors de la conversion.

 
AlexSTAL:

Je comprends que cet algorithme ne peut être que 32 bits.

Plus précisément, pour chaque longueur de bloc, nous devons sélectionner spécifiquement un polynôme caractéristique qui aura de "bonnes" propriétés de hachage, c'est-à-dire qui fera correspondre plus ou moins uniformément l'ensemble d'entrée à l'ensemble de hachage.
 
AlexSTAL:
3681 ms vs 13822 ms à 3 millions d'exécutions.... seulement 4 fois différent...... mais pas de perte de conversion

serait encore plus rapide si l'opération dat % 256 est remplacée par dat & 0xFF, et s = (...)%65521 ; décomposer en s = (...) ; if(s>=65521) s-=65521 ;


 

А по поводу конвертации перед циклом - это как? Вам массив тогда понадобится... динамическое распределение... Да и при конвертации происходит потеря информации

C'est donc la conversion régulière avant le cycle :

uchar array[];
ArrayResize(array, buflength,0);
StringToCharArray(buf, array, 0, -1, CP_ACP);
// Дальше идет цикл

Mais là encore, cette fonction n'est disponible que dans MQL5. La perte d'information, telle que je la comprends, se produit dans Unicode-->ASCII, ce qui est tout à fait acceptable.

 
C-4:

C'est donc la conversion régulière avant le cycle :

Mais là encore, cette fonction n'est disponible que dans MQL5. La perte d'information, telle que je la comprends, se produit dans Unicode-->ASCII, ce qui est tout à fait acceptable.

Eh bien, oui... C'est seulement acceptable pour vous dans votre tâche particulière, mais pas pour l'algorithme.

Examinez de plus près l'algorithme 64 bits MaHash8v64 (ulong), ou peut-être les deux ensemble (du moins, je le ferai pour moi).

Il n'y a pas d'Unicode dans MQL4, il n'y a donc pas de problème non plus.

P.S. StringGetCharacter est une fonction assez rapide, elle ne renvoie que des MOTS(ushort pour MQL5) à partir de la position requise, c'est-à-dire qu'elle ne fonctionne pas du tout avec les chaînes de caractères.

 

Si quelqu'un a un projet d' application VS C++ pour Windows, de préférence pour la version 10. Le projet doit utiliser une dll dans son travail. Je vais l'utiliser comme modèle.

Il est préférable que la dll s'appelle MLP2HL.dll.

Merci d'avance.

 
joo:

Si quelqu'un a un projet d'application VS C++ pour Windows, de préférence pour la version 10. Le projet doit utiliser une dll dans son travail. Je vais l'utiliser comme modèle.

Il est préférable que la dll s'appelle MLP2HL.dll.

Merci d'avance.

Le modèle est ici : ...MetaTrader 4\experts\samples\DLLSample

VS 2010 le convertira automatiquement. Le nom peut être modifié.
 
Zhunko:

Le modèle est ici : ...MetaTrader 4\experts\samples\DLLSample

VS 2010 le convertit automatiquement. Le nom peut être modifié.

Nan, je sais pour le modèle de dll. :)

J'ai besoin d'un modèle de projet exe qui contienne les sources de la dll, afin que je puisse la déboguer. Une dll n'est pas exécutable et doit être appelée par quelqu'un. J'ai décidé d'étudier Intel Parallel Studio 2011 pour VS.

123456789101112131415...45
Nouveau commentaire