助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 16 1...9101112131415161718192021 新しいコメント Nikolay Likhovid 2014.08.21 06:29 #151 komposter: このようなファイルを持っていて、シーケンスの最後のXディールの基準を計算するにはどうしたらよいでしょうか？ファイルの断片を記憶しておき、それを調べて、基準を計算するのに必要な長さのサンプルを形成し、同じ配列に属するディールのみを選択します。そして、このサンプルに対して基準値を算出する。ちなみに、選択時に再帰性を利用することは、アイデア次第で可能です。それとも、私が質問を理解していなかったのでしょうか？追伸：もちろん、サンプルを形成する際には、ファイルを逆行させる必要があります。 Sergey Dzyublik 2014.08.21 06:53 #152 Candid:ファイルの断片を記憶しておき、それを調べて、基準を計算するのに必要な長さのサンプルを形成し、同じ配列に属する取引だけを選択します。そして、このサンプルに対して基準値を算出する。ちなみに、選択時に再帰性を利用することは、アイデア次第で可能です。それとも、私が質問を誤解していたのでしょうか？追伸：もちろん、サンプルを形成する際には、ファイルを逆行させる必要があります。新しいデータを挿入する際の問題点を何とか解決してください。白い靴下は一つのカゴに、黒い靴下は別のカゴに放り込んで、誰が何枚いるのか聞いてくる方が簡単なのに、なぜ何度も通って選ぶのでしょう。 TheXpert 2014.08.21 06:57 #153 komposter:チャンクが読み込まれる。チャンクのサイズは、特定のシーケンスにあったSeek Dateまでのトランザクションの数によって決定されます。 ちなみに、各シーケンスの開始点がわかっている場合、取引は時間順に並んでいるので、バイナリサーチで 目的の日付を検索することができます。 Nikolay Likhovid 2014.08.21 07:01 #154 ALXIMIKS:新しいデータを挿入する際の問題点 - 何とかして解決してください。白い靴下を選ぶなら、白を別のかごに入れ、黒を別のかごに入れ、そこに誰がどれだけいるかを聞く方が簡単なのに、なぜ何度も通うのでしょう。データが多すぎるのもよくない :)問題は、ここで選ばれるのが白人や黒人ではなく、局所的に白くなった人たちであることだ。だから、世界的なブラック度を計算しても、保存されない。ところで、私はこのスレッドで、基準の連続計算の提案だけを始めました。追伸：ところで、誰もいくつかのファイルを一緒に処理することを妨げない - 単にそれぞれのキャッシュは、より少ないことをしなければならないでしょう。しかし、キャッシュサイズにリザーブがあるようです。 つまり、新しいデータは別のファイルに蓄積していけばよいのです。P.P.S. ところで、ファイルをいくつかの小さなファイルにスライスすると、ソートの問題が緩和されます。 Eugeniy Lugovoy 2014.08.21 08:11 #155 komposter:1.もし、クライテリオンが静止していたら...。パラメータが変わったらどうする？2.はい、それならトレードがありますね。しかし、再計算が必要になるのは最新のデータだけで、履歴を全部振る必要はない。3.これは一つのツールだ...4.その通りです。1.上記「基準をシーケンスの直近20トレードの平均利益と する」の内容から"利益への期待 "を動かすという、ひとつの基準として理解すべきです。他にどんなものがあるのでしょうか？データベースに、配列識別子とそれに対応する移動平均の テーブルを生成する。条件に合わない配列はすぐに削除してください。これは、ロボットからの要求に応じて、DBMSレベルでコンカレントモードのプロシージャによって行われ、処理状況はロボットに表示される必要があります。ここでは、FilterAvgProfit (pProfitValue, pTrades, pDeviation)とします。 ここで、pProfitValueは目標利益、pTradesは移動平均利益の取引数、pDeviationはpProfitValueからの許容される乖離です。その結果、シーケンスIDと利益の平均値で表が埋め尽くされる。同様に、条件ごとにストアドプロシージャを記述することも可能です。2.データの一部を破棄すれば（1millionではなくfresh dataを使用）、パフォーマンスを上げることができます。3.文面からではよくわからなかった。これでOK。4.ストラテジーの選択を見るのであれば、この操作はあまり頻繁に（例えば、全てのバーや注文を開く直前に）実行すべきではないことは理解しています。この方法は、現在のストラテジーがN回連続で負けトレードを示した場合に有効で、その場合は別のストラテジーを選択することができ、「決断する」のに時間がかかりますが、避けることはできません。または、週に一度（マーケットが閉じている週末）このような選択を行い、現在選択されているストラテジーを確認するか、別のストラテジーに移行します。ある条件下で、そのトレーダーに最適な推奨ストラテジーをリストアップすることができる。そして、マーケットが開き、頭がクリアになった時（月曜日）に、トレーダーは選択を確認する（あるいはもっと早く、マーケットが開く前に...Eメールアラートなど）。こんなところにも。 Sergey Dzyublik 2014.08.21 08:29 #156 Память выделяется однократно для массива структур последовательностей.配列の構造は、No.、配列の全ディールの構造体の配列[X]、基準値、ファイルポインタ位置からなる。次のステップでは、構造体の要素（ディールの配列を含む）を埋めるだけです。配列内のディールはシフトされるため、メモリ上には常に各配列のX個のディールしか存在しない。構造体の配列にメモリを割り当てて、取得するのです。配列番号 配列[X]の全案件の構造体の配列の配列,基準値の配列。 ファイルポインタポジションの配列。なぜCriterion Value配列と FileIndex Position配列が必要なのですか？(クライテリオン1台と最後のトレードの保管を考えたか？)正しく理解できたかな。最初のパス - 0からSeekDateまでの区間を検索します。そして、最適な基準を見つけFindDate = 取引終了時刻 + 1取引終了時刻からSeekingDateまでの 時間帯を検索してください。で、各シーケンスの基準を計算するには、その区間でX回のトレードが必要なのですね。 Renat Fatkhullin 2014.08.21 09:58 #157 komposter:研究成果を共有する7529MBのバイナリキャッシュファイルが読み込まれる。ハードディスクから：212.3秒（35.46MB/秒）RAMディスクから：88.1秒 (85.46 MB/秒)一番多いハードディスクを搭載しているのに、この差はコスパがいいとは言い難い（とはいえ、メモリも速くはないのだが）。結論：RAMディスクから大容量ファイルを読み込んだ場合、約2.5倍高速化。不思議な結果です。これは、私たちのサーバーシステムに負荷がかかっているときのものです。SSD使用時：200Mb/秒、NTFS使用時RAM: 2000-2500 Mb/秒、FAT32、Softperfect RAM Disk 3.4.5で。RAMディスクがないと、プロジェクトの 構築に何倍もの時間がかかってしまうのです。 Sergey Dzyublik 2014.08.21 10:21 #158 Renat:不思議な結果です。これは、当社の本番サーバーシステムに負荷をかけたときのものです。SSD使用時：200Mb/秒、NTFS使用時RAM: 2000-2500 Mb/秒、FAT32、Softperfect RAM Disk 3.4.5で。RAMディスクがないと、プロジェクトの構築に何倍もの時間がかかってしまうのです。 これは私が言いたかったことで、大きなファイルは大きな塊で読まないと、小さなファイルは10倍も時間がかかることがあります。 Eugeniy Lugovoy 2014.08.21 11:44 #159 papaklass:私の考えでは、問題の解決は生データのコーディングにあると思います。生データを何度も読み込むことができない場合は、何度も読み込めるような形式に変換する必要があります。1つの方法として、各レコードを16ビットの数値に変換することが考えられる。オリジナルレコードの各フィールドには、特定のビット数の番号が割り当てられているはずです。例えば、こんな感じです。数値の最上位桁を表します。- "0 "は否定的な取引 結果を意味する。- "1 "はトランザクションの結果が肯定的であることを示す。は、数字の下一桁です。- "0 "は買い取引を意味する。- "1 "は売り案件を意味します。といった具合に。このように、多くのフィールドを持つソースファイルを繰り返し読み込むのではなく、一つの数値フィールドを繰り返し読み込むという作業になり、大幅な高速化が期待できます。ソースファイル内の情報は非ビジュアルな形で表示されますが、大部分はエンコードされた形式ですぐに生成することができます。しかし、「16ビット」ではなく「64ビット」で、Andrewはx64プロセッサを搭載しているので、メモリにアクセスする際の体積の最小単位は64ビットなのです。メモリから1バイト読んでも、プロセッサは8バイト（ダブルワード2個）読むことになる。 Eugeniy Lugovoy 2014.08.21 11:45 #160 komposter:そうです、この形式ではタスクは並列です。SeekDateが変わるたびに、シーケンスセットの異なる部分に対して最適なCriterionを同時に検索 することができるのです。例えば、20個のパーツに分け、20人のExpert Advisorにタスクを与える。そして、ファイルを読み、取引を見つけ、最適なシーケンス（№、Criterion、ファイル位置）だけを送り返すべきである。ありがとうございました。ほら、もう一つ )) 1...9101112131415161718192021 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ファイルの断片を記憶しておき、それを調べて、基準を計算するのに必要な長さのサンプルを形成し、同じ配列に属するディールのみを選択します。そして、このサンプルに対して基準値を算出する。ちなみに、選択時に再帰性を利用することは、アイデア次第で可能です。
それとも、私が質問を理解していなかったのでしょうか？
追伸：もちろん、サンプルを形成する際には、ファイルを逆行させる必要があります。
ファイルの断片を記憶しておき、それを調べて、基準を計算するのに必要な長さのサンプルを形成し、同じ配列に属する取引だけを選択します。そして、このサンプルに対して基準値を算出する。ちなみに、選択時に再帰性を利用することは、アイデア次第で可能です。
それとも、私が質問を誤解していたのでしょうか？
追伸：もちろん、サンプルを形成する際には、ファイルを逆行させる必要があります。
新しいデータを挿入する際の問題点を何とか解決してください。
白い靴下は一つのカゴに、黒い靴下は別のカゴに放り込んで、誰が何枚いるのか聞いてくる方が簡単なのに、なぜ何度も通って選ぶのでしょう。
チャンクが読み込まれる。チャンクのサイズは、特定のシーケンスにあったSeek Dateまでのトランザクションの数によって決定されます。
新しいデータを挿入する際の問題点 - 何とかして解決してください。
白い靴下を選ぶなら、白を別のかごに入れ、黒を別のかごに入れ、そこに誰がどれだけいるかを聞く方が簡単なのに、なぜ何度も通うのでしょう。
データが多すぎるのもよくない :)
問題は、ここで選ばれるのが白人や黒人ではなく、局所的に白くなった人たちであることだ。だから、世界的なブラック度を計算しても、保存されない。ところで、私はこのスレッドで、基準の連続計算の提案だけを始めました。
追伸：ところで、誰もいくつかのファイルを一緒に処理することを妨げない - 単にそれぞれのキャッシュは、より少ないことをしなければならないでしょう。しかし、キャッシュサイズにリザーブがあるようです。
つまり、新しいデータは別のファイルに蓄積していけばよいのです。
P.P.S. ところで、ファイルをいくつかの小さなファイルにスライスすると、ソートの問題が緩和されます。
1.もし、クライテリオンが静止していたら...。パラメータが変わったらどうする？
2.はい、それならトレードがありますね。しかし、再計算が必要になるのは最新のデータだけで、履歴を全部振る必要はない。
3.これは一つのツールだ...
4.その通りです。
1.上記「基準をシーケンスの直近20トレードの平均利益と する」の内容から"利益への期待 "を動かすという、ひとつの基準として理解すべきです。他にどんなものがあるのでしょうか？
データベースに、配列識別子とそれに対応する移動平均の テーブルを生成する。条件に合わない配列はすぐに削除してください。これは、ロボットからの要求に応じて、DBMSレベルでコンカレントモードのプロシージャによって行われ、処理状況はロボットに表示される必要があります。
ここでは、FilterAvgProfit (pProfitValue, pTrades, pDeviation)とします。
ここで、pProfitValueは目標利益、pTradesは移動平均利益の取引数、pDeviationはpProfitValueからの許容される乖離です。
その結果、シーケンスIDと利益の平均値で表が埋め尽くされる。
同様に、条件ごとにストアドプロシージャを記述することも可能です。
2.データの一部を破棄すれば（1millionではなくfresh dataを使用）、パフォーマンスを上げることができます。
3.文面からではよくわからなかった。これでOK。
4.ストラテジーの選択を見るのであれば、この操作はあまり頻繁に（例えば、全てのバーや注文を開く直前に）実行すべきではないことは理解しています。この方法は、現在のストラテジーがN回連続で負けトレードを示した場合に有効で、その場合は別のストラテジーを選択することができ、「決断する」のに時間がかかりますが、避けることはできません。または、週に一度（マーケットが閉じている週末）このような選択を行い、現在選択されているストラテジーを確認するか、別のストラテジーに移行します。ある条件下で、そのトレーダーに最適な推奨ストラテジーをリストアップすることができる。そして、マーケットが開き、頭がクリアになった時（月曜日）に、トレーダーは選択を確認する（あるいはもっと早く、マーケットが開く前に...Eメールアラートなど）。
こんなところにも。
Память выделяется однократно для массива структур последовательностей.
配列の構造は、No.、配列の全ディールの構造体の配列[X]、基準値、ファイルポインタ位置からなる。
次のステップでは、構造体の要素（ディールの配列を含む）を埋めるだけです。配列内のディールはシフトされるため、メモリ上には常に各配列のX個のディールしか存在しない。
構造体の配列にメモリを割り当てて、取得するのです。
配列番号
配列[X]の全案件の構造体の配列の配列,
基準値の配列。
ファイルポインタポジションの配列。
なぜCriterion Value配列と FileIndex Position配列が必要なのですか？(クライテリオン1台と最後のトレードの保管を考えたか？)
正しく理解できたかな。
最初のパス - 0からSeekDateまでの区間を検索します。
そして、最適な基準を見つけFindDate = 取引終了時刻 + 1
取引終了時刻からSeekingDateまでの 時間帯を検索してください。
で、各シーケンスの基準を計算するには、その区間でX回のトレードが必要なのですね。
研究成果を共有する
7529MBのバイナリキャッシュファイルが読み込まれる。
結論：RAMディスクから大容量ファイルを読み込んだ場合、約2.5倍高速化。
不思議な結果です。
これは、私たちのサーバーシステムに負荷がかかっているときのものです。
RAMディスクがないと、プロジェクトの 構築に何倍もの時間がかかってしまうのです。
不思議な結果です。
これは、当社の本番サーバーシステムに負荷をかけたときのものです。
RAMディスクがないと、プロジェクトの構築に何倍もの時間がかかってしまうのです。
私の考えでは、問題の解決は生データのコーディングにあると思います。
生データを何度も読み込むことができない場合は、何度も読み込めるような形式に変換する必要があります。
1つの方法として、各レコードを16ビットの数値に変換することが考えられる。オリジナルレコードの各フィールドには、特定のビット数の番号が割り当てられているはずです。例えば、こんな感じです。
数値の最上位桁を表します。
- "0 "は否定的な取引 結果を意味する。
- "1 "はトランザクションの結果が肯定的であることを示す。
は、数字の下一桁です。
- "0 "は買い取引を意味する。
- "1 "は売り案件を意味します。
といった具合に。
このように、多くのフィールドを持つソースファイルを繰り返し読み込むのではなく、一つの数値フィールドを繰り返し読み込むという作業になり、大幅な高速化が期待できます。
ソースファイル内の情報は非ビジュアルな形で表示されますが、大部分はエンコードされた形式ですぐに生成することができます。
しかし、「16ビット」ではなく「64ビット」で、Andrewはx64プロセッサを搭載しているので、メモリにアクセスする際の体積の最小単位は64ビットなのです。メモリから1バイト読んでも、プロセッサは8バイト（ダブルワード2個）読むことになる。
そうです、この形式ではタスクは並列です。SeekDateが変わるたびに、シーケンスセットの異なる部分に対して最適なCriterionを同時に検索 することができるのです。例えば、20個のパーツに分け、20人のExpert Advisorにタスクを与える。そして、ファイルを読み、取引を見つけ、最適なシーケンス（№、Criterion、ファイル位置）だけを送り返すべきである。
ありがとうございました。
ほら、もう一つ ))