助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 17

 
一度のデータ読み込みですべてを計算することが可能です。
komposter:

そうです、この形式ではタスクは並列です。SeekDateが変わるたびに、シーケンスセットの異なる部分に対して最適なCriterionを同時に検索することができるのです。例えば、20個のパーツに分け、20人のExpert Advisorにタスクを与える。そして、ファイルを読み、取引を見つけ、最適なシーケンス(№、Criterion、ファイル位置)だけを送り返すべきである。

皆さん、本当にありがとうございました。

このアルゴリズムを複数のEAで実行すると、ディスクからの読み込み速度+部分的+異なる位置からの読み込み速度に制限され、速度不足になる可能性が高い。

 
ALXIMIKS:
一度のデータ読み込みですべてを計算することも可能です。やろうと思えばできる、要は「やる気」なんです。

ディスクからの読み込みはかなり高価な処理です。複数のExpert Advisorでこのアルゴリズムを実行すると、ディスクからの読み込み速度が制限され+部分的に+異なる位置からの読み込みとなり、高速化は望めません。

分散コンピューティングは 1台のワークステーションで行わなければならないと誰が言った? そのような制限はありません))RAM-diskは、上で言われているように、役に立ちます。
 
elugovoy:
分散計算は 1台のワークステーションで行うべきと誰が言ったのでしょうか? そのような制限はありません))RAM-diskも上で言われているように、大きな助けになります。

少し考えて、アルゴリズムを変えてみてはいかがでしょうか。

1. 複数のシーケンスを一度にダウンロードする方法と、その開始と終了を知る方法

2.すべての案件の係数を一度に計算し、どのようなデータ構造に答えを格納するか。

3.前のポイントからの2つの答えをマージして、新しい少し完全な答えを作る方法

4.3の最終回答を必要な間隔に分割する方法(SeekingDate = Trade closing time + 1の ことです。)

SeekingDateの 間隔をいくつに分割するかを選択するために、少し異なるアルゴリズムを得ることができる。

は、最初の著者のアルゴリズムと比較して、異なる誤差を得ることができます。

 
papaklass:

数字の桁数は、システムの桁数ではなく、エントリーコードの一意性で決まります。明らかに1バイトの倍数であるべきです。

64ビットは多すぎるように思います。:)

100万件のレコードがある場合、16ビットではユニークなレコードコードにならない(最大65536件)。それは1つです。

インテル(Itanium)、AMD(OSとは言っていない)の32ビット、64ビットプロセッサーのアーキテクチャを見てください。32/64はアドレスバスの分解能だが、同時に1バイトのメモリにアクセスする場合でも、1マシンサイクルで32/64ビット(4/8バイト)がメモリから読み出される。

したがって、メモリから2バイトを読み込んでも8バイトを読み込んでも、性能的には全く変わらないのです。

原理的には、このようなファイル操作のためのWindowsサービスを書くことができます。

でも、やっぱりDBMSを使いたい気持ちがあるんです。

 
ALXIMIKS:

少し考えて、アルゴリズムを変えてみてはいかがでしょうか。

1. 複数のシーケンスを一度にダウンロードする方法と、その開始と終了を知る方法

2.すべての案件の係数を一度に計算し、どのようなデータ構造に答えを格納するか。

3. 前の項目の2つの答えをマージして、新しい少し完全な答えを作る方法

4.3の最終回答を必要な間隔に分割する方法(SeekingDate = Trade closing time + 1の ことです。)

SeekingDateの 間隔をいくつに分割するかを選択するために、少し異なるアルゴリズムを得ることができる。

の場合、最初の著者のアルゴリズムと比較して、異なるエラーが発生する可能性があります。

4点とも、DBMS側でのデータ処理。

少し違う」アルゴリズムについてですが、意味がよくわかりません。でも。この「少し違う」アルゴリズムと「著者の」アルゴリズムの誤差をどうにかして計算するには、両方のアルゴリズムが実装されている必要があるのです。そして、このスレッドは、まさに「作者」のアルゴリズムを実装するための技術的な問題から生まれたものです。

この事実を踏まえた上で、どのような方法論であなたの言う誤差を算出するつもりなのでしょうか?

 
ALXIMIKS:
一読して、すべてを計算することができます。重要なのは、欲望です。

ディスクからの読み込みはかなり高価な処理です。このアルゴリズムを複数のExpert Advisorで実行すると、ディスクからの読み込み速度+部分的+異なる位置からの読み込みに制限され、このアイデアで速度が出るとは思えません。

HDDが一番遅いデバイスだとしよう、それは事実だ。ただし、これらの計算をすべて使って複数のEAを走らせるという話ではありません。私の見るところ、最も可能性の高い用途は信号の発生です。必要な性能を持ったamazonのクラウドサーバー+MT4+今回の開発=シグナルプロバイダーと言うことになります。

 
elugovoy:

4点とも、データ処理はDBMS側で行っています。

少し違う」アルゴリズムについてですが、どういう意味でしょうか。でも。この「少し違う」アルゴリズムと「著者の」アルゴリズムとの誤差を何とか計算するためには、両方のアルゴリズムを実装する必要があります。そして、このスレッドは、まさに「作者」のアルゴリズムを実装するための技術的な問題から生まれたものです。

この事実を踏まえた上で、どのような方法論であなたの言う誤差を算出するつもりなのでしょうか?

筆者は、与えられた範囲から選ばれた最大係数によって範囲が切り取られると理解している。 私の提案は、各範囲をN個のサブ範囲に分割し、収束時に1つの係数の値しか適合しないようにすることである。つまり、N = 5の場合、その範囲は0.2 0.4 0.6 0.8 1の割合に分けることができるのです。そして、0から1までのどの値も、作者の範囲内で切り捨てられる。つまり、レンジ誤差0.2がN=5での最大値となる。

そして、筆者の書き込みをどれだけ正しく解釈したかというあたりで、まだ完全な解明には至っていないのだから。

 
ALXIMIKS:

私が理解した限りでは(具体的に何が必要なのか明確で完全な説明がないので、また何かが間違っている可能性があります)、範囲はこの範囲から選択された最大の係数で切り取られます。私が提案したバージョンでは、そのような各範囲は、合併に1つの係数値のみが収まるN個のサブ範囲に分割される必要があります。したがって、N = 5の場合、その範囲は0.2 0.4 0.6 0.8 1の割合に分けることができる。そして、0から1までのどの値も、作者の範囲内で切り捨てられる。つまり、レンジ誤差0.2がN=5での最大値となる。

そして、著者の投稿をどのように正しく解釈したかというあたりも、まだ完全な解明には至っていないからだ。

はい、どうやら財務省が発注したプロジェクトの ようで、具体的な情報が十分でないのです。しかし、誰もがこの議論から自分にとって興味深いものを見つけることができます。私は、これを議論のプラス面としてとらえています。

レンジの離散化についてですが、お考えが明確ですね。そして、N=100, 1000なら...。(純粋に数学的に可能です)、この分割は、パフォーマンスとシステムリソースの使用という点で反動を引き起こします。数学の他に物理学もある )

 
Candid:

メモリ内にファイルの断片があり、それを調べて基準値を計算するのに必要な長さのサンプルを形成し、同じ配列に属するディールのみを選択します。そして、このサンプルに対して基準値を算出する。ちなみに、選択範囲に再帰性を利用することも可能です。

だから、他の配列から数百万件の案件をこなす必要があるのですまさにその通りです。

ALXIMIKS

新しいデータを挿入する際の問題点 - 何とか解決してください。

今のところ問題なし、データは固定量です。

TheXpert です。
ちなみに、各シーケンスの起点がわかっていれば、取引は時間順に並んでいるので、バイナリサーチで正しい日付を検索することができます。

+1、アイデアありがとうございます。

エルゴヴォイ

1.上記の「基準をシーケンスの直近20回のトレードの平均利益とする」に基づいて、「基準」を設定します。「というのは、これは一つの基準、つまり利益の移動期待として理解されるべきものです。他にどんなものがあるのでしょうか?

データベースに、配列識別子とそれに対応する移動平均のテーブルを生成する。条件に合わない配列はすぐに削除してください。これは、ロボットからの要求に応じて、DBMSレベルでコンカレントモードのプロシージャによって行われ、処理状況はロボットに表示される必要があります。

ここでは、FilterAvgProfit (pProfitValue, pTrades, pDeviation)とします。

ここで、pProfitValueは目標利益、pTradesは移動平均利益の取引数、pDeviationはpProfitValueからの許容される乖離です。

その結果、シーケンス ID と平均利益値を含むテーブルが生成されます。

1а.他の基準は何なのか......それはどうでもいい。重要なのは、指定された長さの一連の取引によって計算が行われることである。

1б.トレードNのクローズ時に基準値が悪いからと言って、どうしてシーケンスを捨てることができるのでしょうか?その後、より良いものになったらどうでしょう?
完全に失敗し、その基準が利益を示していないシーケンスのみを削除することができます。そして、その数は多くないはずです。

エルゴヴォイ

4.私の見るところ、ストラテジー選択を視野に入れるのであれば、この操作はあまり頻繁に(例えば、全てのバーで、あるいは注文開始直前で)実行されるべきではないと思います。この方法は、現在のストラテジーがN回連続で負けトレードを示した場合に有効で、その場合は別のストラテジーを選択することができ、「決断する」のに時間がかかりますが、避けることはできません。または、週に一度(マーケットが閉じている週末)このような選択を行い、現在選択されているストラテジーを確認するか、別のストラテジーに移行します。ある条件下で、そのトレーダーに最適な推奨ストラテジーをリストアップすることができる。そして、マーケットが開き、頭がすっきりした状態で(月曜日に)、トレーダーは選択を確定する(あるいは、マーケットが開く前に、より早く...電子メールアラートなど)。

まあ、イデオロギーの問題なんですけどね。今は彼についてではない;)

ALXIMIKS

構造体の配列にメモリを割り当てて、取得するのです。

なぜ、Criterion Valueの配列とFile Pointer Positionの配列が必要なのですか?(1つのCriterionと最後のトランザクションは、保存することを考えなかったのですか?)

基準値配列 - (将来のために)いくつかの最適な配列をソートして選択できるようにすること。

ファイルのインデックス位置 - 各シーケンスで正しい位置から検索を続けるため(他に方法は?)

ALXIMIKS

うまくいったかな。

最初のパス - 0からSeekDateまでの区間を検索します。

そして、最適な基準を見つけFindDate = 取引終了時刻 + 1

取引終了時刻からSeekingDateまでの 時間帯を検索してください。

で、各シーケンスの基準を計算するために、その区間X回に収める必要があるのでは?

1.はい、0から最初のSeekingDateまで

2.SeekedDateをシフトさせ、「PreviousTreatedTrade - SeekDate」の間隔でシーケンス処理(配列にトレードを追加)しています。

レナート

これは不思議な結果です。

これは、私たちのサーバーシステムに負荷がかかっているときのものです。

  • SSD:200Mb/秒、NTFS
  • RAM: 2000-2500 Mb/秒、FAT32、Softperfect RAM Disk 3.4.5で。

ディスクフレームがないと、プロジェクトの組み立てに何倍もの時間がかかってしまうのです。

コンプレックスになりつつある

おそらく、テストスクリプトを作成してファイルを添付し、同様の作業で確認してもらう必要があると思います。

私は普通のハードディスク - wdc wd1002FAEX-00Y9A0を持っています、スペックから判断すると、最大速度は126MB/sです。

レビューから 判断すると、それくらいは絞れているのでしょう。もしかして、私のやり方が悪いのか?

それでは、スクリプトを見てみましょう...。

ALXIMIKS
大きなファイルは大きな塊で読まないと、小さなファイルは10倍も時間がかかるかもしれない、ということです。

大きな塊をどう読むか?

papaklass

私の考えでは、問題の解決は生データのコーディングにあると思います。

情報を失うことなく、いかにしてトランザクションの全情報を符号化するか?

 
Renat:

不思議な結果です。

これは、当社の本番サーバーシステムに負荷をかけたときのものです。

  • SSD使用時:200Mb/秒、NTFS使用時
  • RAM: 2000-2500 Mb/秒、FAT32、Softperfect RAM Disk 3.4.5で。

RAMディスクがないと、プロジェクトの構築には何倍もの時間がかかります。

メモリについて書くのを忘れていました。

DDR3、1333MHz。

Softperfect RAM Disk 3.4.5、NTFSにしたけど(何か違いがあるのかな?)

そしてもうひとつ、RAMディスクは12000MBで、空きメモリは1〜2GBしかない(仕事用)。