記事"OpenCL を使用したローソク足パターンのテスト"についてのディスカッション - ページ 3

 

とても興味深い記事だ。主な利点は、OpenCLコードの実際の動作例を見ることができることです。このような例があると、OpenCLを自分で使い始めるときにとても便利です。ありがとう。

しかし、この比較でGPUを使った大きな利益が期待できることが確認できましたが、これは非常に特殊な戦略で、トレード間にはまったく関係がありません。実際の取引でこのような戦略を目にすることは稀でしょう。取引間の関係(最大オープン取引、一度に1つの取引のみ、勝者/敗者の後のロットの増減など)を導入し始めると、OpenCLコードの複雑さによって、すぐにスピードアップのメリットが失われるのではないかと心配しています。(自分で試したわけではないので、間違っているかもしれません)。

あまり重要ではありませんが、適切な比較のためには、GPUで使用した「仮想」アルゴリズムをGPUなしでも使用すべきです。記事のアプローチのように、CPUとGPU(シリアルとパラレル)だけでなく、「ストラテジー・テスター」と「仮想」も比較することになります。

 
こんにちは、
AMDはもうOpenCLをサポートしていないようですが、OpenCLはまだあるのでしょうか?

回避策はあるのでしょうか?Linuxが必要なのでしょうか?あるいは、並列コンピューティングの ための他のGPUスケジューリング手法で、ある程度簡単にアクセスできるものはあるのでしょうか?

よろしくお願いします。
 

こんにちは。

あなたのコードで、買いと売りの取引を一度に1つだけオープンするおおよその方法を教えてください。

 
Sergey Seriy:

こんにちは。

あなたのコードで、買いと売りの取引を一度に1つだけオープンするおおよその方法を教えてください。

まず、tester_step カーネルに、__global double *Res 結果バッファのように、インデックスを使用して取引終了時刻(取引が終了したM1バーのインデックス、またはM1バーの数で 表されるポジション保有時刻)を取得できるようにする引数を1つ追加する必要があります。

次に、質問が単一のテストに関するものか、最適化に関するものかによります:

1. テスト。総利益が要約されるループの中で、終値を使ってオープンポジションの重複を除外する条件を追加する必要があります(これは、確定したtester_stepによって 返されます)。

2. 最適化。ここでは、利益を要約する find_patterns_opt カーネルの代わりに、単にエントリー・ポイントを返す find_patterns を使用する必要がある。一度に複数の取引を開始することが許されないという条件を考慮すると、mql5 コードで利益を要約する必要がある。ただし、この場合、並列実行されたものが順次実行される(最適化パスの数に最適化の深さが乗じられる)ので、時間がかかるかもしれません(試してみてください)。もう一つの妥協案として、(同時にオープンしたポジション数の条件を考慮して)1パス分の利益をカウントするカーネルを追加することもできますが、私自身の実践から言えるのは、「重い」カーネルを実行するのは良くないということです。理想的には、カーネルのコードをできるだけシンプルに保ち、できるだけ多くのカーネルを実行するように努めるべきである。

 
Serhii Shevchuk:

まず、tester_step カーネルに、__global double *Res 結果バッファのように、インデックスを使用して取引を終了した時間(取引が終了したバー M1 のインデックス、または M1のバー数で 表されるポジションを保持している時間)を取得できるようにする引数を 1 つ追加する必要があります。

さらに、ご質問の内容が単一テストなのか最適化なのかによって異なります:

1. テスト。総利益が要約されるループでは、終値を使ってオープンポジションの重なりを除外する条件を追加する必要があります(これは最終的にtester_stepによって 返されます)。

2. 最適化。ここでは、利益を要約する find_patterns_opt カーネルの代わりに、単にエントリー・ポイントを返す find_patterns を使用する必要がある。一度に複数の取引を開始することが許されないという条件を考慮すると、mql5 コードで利益を要約する必要がある。ただし、この場合、並列実行されたものが順次実行される(最適化パスの数に最適化の深さが乗じられる)ので、時間がかかるかもしれません(試してみてください)。もう一つの妥協案として、(同時にオープンしたポジション数の条件を考慮して)1パス分の利益をカウントするカーネルを追加することもできますが、私自身の実践から言えるのは、「重い」カーネルを実行するのは良くないということです。理想的には、カーネルのコードをできるだけシンプルに保ち、できるだけ多くのカーネルを実行するように努めるべきである。

こんにちは。

早速のお返事ありがとうございます。最適化についての回答は、コードを実際に適用するためのアイデアとして、まず最初に興味を持ちました。このような記事は他にないので、ありがとうございました!また、tester_step (およびtester_step_opt)を少し修正して、p>open to buyという時間条件を追加してみます。if(j>=maxbar || (TimeM1[j]>=tclose && p>open))、売りの場合は if(j>=maxbar || (TimeM1[j]>=tclose && p<open)))を追加すれば、オプション取引用のストラテジーができあがります。

 

...オプション戦略に関する前回のコメントにも少し補足します。ここでは、Option Expiration Time変数を追加する必要があるので(同時に、StopLossとTakeProfitは最適化中のオプションには必要ありません)、tester_opt_stepのコードを以下のように修正します:

ulong tcloseDEATH=TimeM1[iO]+240*60*60;//有効期限変数を追加, например 240 часов (т.е. 10 дней)



//...TPとSLはオプションには必要ないので、さらにコメントする。

/*if(p<=sl)
 {
 Res[idx]=sl-open;
 return;
 }
 else if(p>=tp)
 {
 Res[idx]=tp-open;
 return;
 }*/
// そして、有効期限のチェックを追加する(VEの有効期限には、オプションが失敗したため、大きな損失が発生するはずである)。
              if(TimeM1[j]>=tcloseDEATH)
              {
               Res[idx]=sl*10-open; //大きなヘラジカがいる! (для примера в 10 раз больше установленного при оптимизации стоп-лосса)
               return;
              }

 
こんにちは。あなたの記事に従ってUSDRUBのOpenCL最適化を実行したところ、そのような問題に遭遇しました。最適化の結果は 常にプラスで、常に利益があります。つまり、結果が生成されるint型の変数にオーバーフローがあるようです。一方、EURUSDでは最適化は正しく機能します。おそらくUSDRUBの5桁の問題でもあるのでしょう。この問題を解決する方法を教えてください。
 
Sergey Seriy:
こんにちは。あなたの記事に従ってUSDRUBのOpenCL最適化を実行したところ、そのような問題に遭遇しました。最適化の結果は 常にプラスで、常に利益です。つまり、結果が生成されるint型の変数にオーバーフローがあるようです。一方、EURUSDの最適化は正しく機能します。おそらくUSDRUBの5桁の問題でもあるのでしょう。この問題を解決する方法を教えてください。
...スクリーンショットも添付します。
ファイル:
 

記事の中であなたはこう書いています:

В нашем случае функция atomic_inc()  для начала запрещает доступ другим задачам к ячейке Count[0], затем увеличивает её значение на единицу, а предыдущее возвращает в виде результата.

私の理解では、この関数はint型の 配列に対してのみ機能しますが、異なる型の配列、例えばushort型の配列がある場合、どうすればよいのでしょうか?