PROFIからSUPER PROFIへの質問-1. - ページ 8

 
C-4:

Adler32のハッシュ関数の動作 例を示します。

関数の基本的なコードはwikipediaから引用し、MQL5用に少し修正したものです。以下はスクリプトの結果である。

このように、この関数が返す値はすべて全く異なるものですが、文字列そのものには大きな違いはありません。

なぜuintでなくulongなのか?

また、この関数での配列の操作は極めて非効率的です。コードを修正し、ユニコードを2つの独立したシンボルに分割する方が簡単で、50倍速くなります。

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);
  }
300万回の実行で3681ms vs 13822ms...。4倍しか違わないのに......変換ロスなし
 

そうです、32ビットはlongではなくintegerですから。でも、正直なところ、64bit版ではハッシュ関数を変更しますよ。やはり、衝突確率が低いので、マジックエキスパートの調整がしやすいのです。一方、現在の実装はMQL4と完全な互換性を持っていますが(long型を 持たないため)

追伸:ループする前に文字列をuchar配列に変換しておいて、ループの中で配列の値を一つずつ見ていった方が早くないですか?しかし、ループの中で毎回StringGetCharacter(buf, n)を呼び出すのは高すぎると思う。

 
C-4:

そうです、32ビットはlongではなくintegerですから。 とはいえ、正直なところ、やはり64bit版ではハッシュ関数を変更することになるでしょう。やはり、衝突確率が低いので、マジックエキスパートの調整がしやすいのです。しかし一方で、現在の実装はMQL4と完全に互換性があります(long型を持たないため)。

追伸:ループの前に文字列をuchar配列に変換しておいて、ループの中で配列の値を一つずつ見ていく方が早くないですか?それにしても、ループの中で毎回StringGetCharacter(buf, n)を呼び出すのは、かなりコストがかかると思うのですが。

この アルゴリズムは32ビットしか 使えないと理解しています。

また、ループの前の変換については、どのように?その際、配列が必要になります...ダイナミックアロケーション...はい、変換時に情報の損失があります。

 
AlexSTAL:

この アルゴリズムは32ビットしか 使えないと理解しています。

より正確には、各ブロック長に対して、「良い」ハッシュ特性を持つ、つまり入力集合を多かれ少なかれ一様に ハッシュ集合にマッピングする特性多項式を具体的に 選択する必要があるのだ。
 
AlexSTAL:
300万回の実行で3681ms vs 13822ms...。4倍しか違わないのに......変換ロスなし

は、dat % 256 の 演算をdat & 0xFF に置き換え、s = (...)%65521; で分解し、s = (...); if(s>=65521) s-=65521 とすると、さらに高速になります。


 

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

これがサイクルの前の正規の変換なんですね。

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

しかし、やはりこの機能はMQL5でしか使えません。情報の損失は、私の理解では、Unicode-->ASCIIで発生し、これはかなり許容範囲内です。

 
C-4:

これがサイクルの前の正規の変換なんですね。

しかし、やはりこの機能はMQL5でしか使えません。情報の損失は、私の理解では、Unicode-->ASCIIで発生し、これはかなり許容範囲内 です。

まあ、そうなんですが...。それは、あなたの特定のタスクにおいてのみ許容されるものであり、一方、アルゴリズムにおいては許容されないものです。

64ビットのMaHash8v64(ulong)アルゴリズムを詳しく見てみましょう、いや、両方を一緒に見てみましょう(少なくとも、私の場合はそうします)。

MQL4にはUnicodeがないので、どちらかというと問題はありません。

追伸:StringGetCharacterは非常に高速な関数ですが、必要な位置からWORD(MQL5ではushort)を返すだけで、つまり文字列では全く動作しません。

 

C++のWindows VSアプリケーションのプロジェクトを お持ちの方がいらっしゃいましたら、できればバージョン10に対応したものをお願いします。プロジェクトでは、業務でDLLを使用する必要があります。テンプレートとして活用させていただきます。

このDLLはMLP2HL.DLLという名前であることが望まれます。

ありがとうございました。

 
joo:

C++のWindows VSアプリケーションのプロジェクトをお持ちの方がいらっしゃいましたら、できればバージョン10に対応したものをお願いします。プロジェクトでは、業務でDLLを使用する必要があります。テンプレートとして活用させていただきます。

このDLLはMLP2HL.DLLという名前であることが望まれます。

よろしくお願いします。

Template is here: ...MetaTrader 4

VS 2010では、自動的に変換されます。名称を変更することができます。
 
Zhunko:

Template is here: ...MetaTrader 4 Types.

VS 2010では、自動的に変換されます。名称を変更することができます。

いや、DLLのテンプレートは知ってるんだけどね。:)

私は、デバッグできるように、DLLのソースを含むexeプロジェクトの テンプレートが必要です。dllは実行可能ではないので、誰かが呼び出す必要があります。インテル Parallel Studio 2011 for VS を勉強することにしました。