Alle Fragen von einem PROFI an einen SUPER PROFI - 1. - Seite 8

Neuer Kommentar
 
C-4:

Hier ist ein funktionierendes Beispiel für die Adler32-Hash-Funktion:

Der Grundcode der Funktion ist aus Wikipedia entnommen und für MQL5 leicht modifiziert. Hier ist das Ergebnis des Skripts:

Wie Sie sehen können, sind alle von dieser Funktion zurückgegebenen Werte völlig unterschiedlich, obwohl sich die Zeichenketten selbst nicht sehr unterscheiden.

Warum ulong und nicht uint?

Und die Operationen mit Arrays in dieser Funktion sind extrem ineffizient. Es ist einfacher, den Code zu ändern und Unicode in zwei unabhängige Symbole aufzuteilen - das ist 50 Mal schneller.

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 gegenüber 13822 ms bei 3 Millionen Läufen.... nur 4 Mal anders...... aber kein Umsatzverlust
 

Ja, das ist richtig, denn 32 Bit sind eine ganze Zahl und kein Long. Ehrlich gesagt, würde ich die Hash-Funktion für die 64-Bit-Version jedoch ändern. Schließlich ist die Kollisionswahrscheinlichkeit geringer, und es ist leicht, sich auf den Magieexperten einzustellen. Andererseits ist die derzeitige Implementierung vollständig kompatibel mit MQL4 (da sie keinen langen Typ hat).

P.S. Wäre es nicht schneller, wenn ich String in uchar-Array vor der Schleife konvertieren, und bereits in der Schleife einer nach dem anderen durch Array-Werte gehen? Aber ich denke, der Aufruf von StringGetCharacter(buf, n) jedes Mal in der Schleife ist zu teuer.

 
C-4:

Ja, das ist richtig, denn 32 Bit sind eine ganze Zahl und kein Long. Aber um ehrlich zu sein, würde ich die Hash-Funktion für die 64-Bit-Version trotzdem ändern. Schließlich ist die Kollisionswahrscheinlichkeit geringer, und es ist leicht, sich auf den Magieexperten einzustellen. Andererseits ist die derzeitige Implementierung vollständig kompatibel mit MQL4 (da sie keinen langen Typ hat)

P.S. Wäre es nicht schneller, wenn ich String vor der Schleife in ein uchar-Array konvertiere und dann in der Schleife die Array-Werte einzeln durchgehen muss? Dennoch denke ich, dass der Aufruf von StringGetCharacter(buf, n) jedes Mal in der Schleife ziemlich teuer ist.

Ich weiß, dass dieser Algorithmus nur 32-Bit sein kann.

Und was ist mit der Umwandlung vor der Schleife - wie? Sie bräuchten dann ein Array... dynamische Zuweisung... Ja, und bei der Konvertierung gehen Informationen verloren.

 
AlexSTAL:

Ich habe verstanden, dass dieser Algorithmus nur 32-Bit sein kann.

Genauer gesagt, müssen wir für jede Blocklänge ein charakteristisches Polynom auswählen , das "gute" Hash-Eigenschaften hat, d. h. die Eingabemenge mehr oder weniger gleichmäßig auf die Hash-Menge abbildet.
 
AlexSTAL:
3681 ms gegenüber 13822 ms bei 3 Millionen Läufen.... nur 4 Mal anders...... aber kein Umsatzverlust

wäre noch schneller, wenn die Operation dat % 256 durch dat & 0xFF ersetzt wird und s = (...)%65521; zu s = (...); if(s>=65521) s-=65521 zerlegt wird ;


 

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

Dies ist also die reguläre Umwandlung vor dem Zyklus:

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

Aber auch diese Funktion ist nur in MQL5 verfügbar. Der Informationsverlust tritt meines Erachtens bei Unicode-->ASCII auf, was durchaus akzeptabel ist.

 
C-4:

Dies ist also die reguläre Umwandlung vor dem Zyklus:

Aber auch diese Funktion ist nur in MQL5 verfügbar. Der Informationsverlust tritt meines Erachtens bei Unicode-->ASCII auf, was durchaus akzeptabel ist.

Nun, ja... Das ist nur für Sie bei Ihrer speziellen Aufgabe akzeptabel, nicht aber für den Algorithmus.

Schauen Sie sich den 64-Bit-Algorithmus MaHash8v64 (ulong) genauer an, oder vielleicht auch beide zusammen (zumindest werde ich das für mich tun).

In MQL4 gibt es keinen Unicode, also gibt es auch kein Problem.

P.S. StringGetCharacter ist ziemlich schnell Funktion, es gibt nur WORD(ushort für MQL5) von der gewünschten Position, d.h. es funktioniert nicht mit String überhaupt

 

Wenn jemand ein C++ Windows VS Anwendungsprojekt hat, vorzugsweise für Version 10. Das Projekt muss bei seiner Arbeit eine DLL verwenden. Ich werde sie als Vorlage verwenden.

Vorzugsweise sollte die dll den Namen MLP2HL.dll tragen.

Vielen Dank im Voraus.

 
joo:

Wenn jemand ein C++ Windows VS Anwendungsprojekt hat, vorzugsweise für Version 10. Das Projekt muss bei seiner Arbeit eine DLL verwenden. Ich werde sie als Vorlage verwenden.

Vorzugsweise sollte die dll den Namen MLP2HL.dll tragen.

Ich danke Ihnen im Voraus.

Vorlage ist hier: ...MetaTrader 4\experts\samples\DLLSample

VS 2010 konvertiert es automatisch. Der Name kann geändert werden.
 
Zhunko:

Die Vorlage befindet sich hier: ...MetaTrader 4\experts\samples\DLLSample

VS 2010 konvertiert sie automatisch. Der Name kann geändert werden.

Nein, ich weiß über die dll-Vorlage Bescheid. :)

Ich brauche eine exe-Projektvorlage, die die Quellen der DLL enthält, damit ich sie debuggen kann. Eine DLL ist nicht ausführbar und muss von jemandem aufgerufen werden. Ich beschloss, Intel Parallel Studio 2011 für VS.

123456789101112131415...45
Neuer Kommentar