助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 5 123456789101112...21 新しいコメント Dmitry Fedoseev 2014.08.18 11:15 #41 探しているものを圧縮し、圧縮された状態で検索することができます。これにより、データ量を削減し、すべてのデータをRAMに保持することができます。(理論的には) Yuriy Zaytsev 2014.08.18 11:17 #42 Integer:探しているものを圧縮し、圧縮された状態で検索することができます。これにより、データ量を削減し、すべてのデータをRAMに保持することができます。(理論的には)imo - 圧縮された形で検索したければ、まず解凍しなければならない - 理論的には、圧縮された形のデータ検索のためのアルゴリズムを書かなければならない - 気合だそして問題は、mt4(32bit)はRAMに多くを保持できないことです。---大量のデータをデータベースに格納し、クエリーで計算されたデータを準備するのは理にかなっている既成のソリューションを適用するには、自分でデータ処理の仕組みを書く以外に方法はないと思っています。 SQLは20ギガでは少ないですが、ビッグデータを保存するのに非常に適しています...。 --独自のメカニズムを作成し、与えられたファイルを分割して読み、読み取った断片に最大量の メモリを割り当てることで高速化を図ることができます。で、1回の計算で20ギガから数個のフラグメントを読み込む必要があります。問題は、データベースにデータをロードしてSQLクエリで処理する方法よりも速いかどうかということです。SQLに入力した方が早いのでは？ Dmitry Fedoseev 2014.08.18 11:19 #43 YuraZ:ichmo - 圧縮されたフォーマットで検索したい場合、まず解凍する必要があります。 必ずしもそうではありません。探しているものを圧縮することができます。ほらね！:) Nikolay Likhovid 2014.08.18 11:29 #44 最も健全な解決策は、もちろんアルゴリズムを変更することでしょう。しかし、未知数なので、ここで提案できる具体的なことは何もありません。一般的な考え方はもちろん全くないかもしれません。 例えば、複数のファイルを読み込む必要があるため、これらの読み込みは内部で「ループ」して行われる可能性があります。外側の「ループ」自体に読みを「転送」してみるという手もある。引用符が使われているのは、一般にこのような「転送」は、まったく新しいアルゴリズムをゼロから作ることになるかもしれないからだ :) 。もう1つの手がかりは、シフトを伴う連続読み出しについて言及したことである。読み出しのみの「シフト」を必要とする反復アルゴリズムが、この問題を解決する可能性がある。しかし、それでは全く別のアルゴリズムを一から作ることになりかねません。というか、全然関係ないんですけどね :) Yuriy Zaytsev 2014.08.18 11:30 #45 Integer: 必要ないのです。探しているものを圧縮することができます。ほらね！:)---情報量が多い（テキストファイルで20GB程度）。情報は同じような配列で構成されており、その数は約100万個。すべての配列を繰り返し見て、計算する必要があります。---20ギガから、アルゴリズムにデータを送り込む必要があります。 見ているのではなく、ファイルの形でデータを持ち、それがアルゴリズムに使われ、計算アルゴリズムに供給されているのです。 Yuriy Zaytsev 2014.08.18 11:32 #46 Candid:最も健全な解決策は、もちろんアルゴリズムを変更することでしょう。しかし、未知数なので、ここで提案できる具体的なことは何もありません。一般的な考え方はもちろん全くないかもしれません。 例えば、複数のファイルを読み込む必要があるため、これらの読み込みは内部で「ループ」して行われる可能性があります。外側の「ループ」自体に読みを「転送」してみるという手もある。引用符が使われているのは、一般にこのような「転送」は、まったく新しいアルゴリズムをゼロから作ることになるかもしれないからだ :) 。もう1つの手がかりは、シフトを伴う連続読み出しについて言及したことである。読み出しのみの「シフト」を必要とする反復アルゴリズムが、この問題を解決する可能性がある。しかし、それでは全く別のアルゴリズムを一から作ることになりかねません。というか、全然関係ないんですけどね :) データ量の多いアルゴリズムをSQLサーバーに入れるのは理にかなっている Dmitry Fedoseev 2014.08.18 11:33 #47 YuraZ:---情報量が多い（テキストファイルで20GB程度）。情報は同じ種類の配列で構成されており、その数は約100万個。すべての配列を繰り返し見て、計算する必要があります。---20ギガバイトのデータから、アルゴリズムにデータを送り込まなければならない。 見ているのではなく、データベースを持っていて、それがアルゴリズムに使われているのです。 ただの陰謀だ。もちろん、何でもいいのですが、見た目でしょうね。とまで推測しています。 Eugeniy Lugovoy 2014.08.18 11:41 #48 Integer: 必要ありません。探しているものを圧縮することができます。ほらね！:)あなたには驚かされますよ))))どのようなアルゴリズムで圧縮するか？ハフマン、レンペル＝ツィブ？まあ、テキストライターとしては4～8倍の圧縮率が得られるでしょう。圧縮アルゴリズムが、ファイルごとに異なる再符号化ツリーを作成することを考える。つまり、ソースファイルには1つのツリーがあり、検索するデータの部分には別のツリーがあることになる。 ただ、面白いのは、理論的にでも、どうやって検索するんだ )))データ圧縮はコーディングに他なりません。暗号に例えると、2つの異なるメッセージ（圧縮データ）を異なる鍵（再符号化木）で暗号化したものです。検索機能はおろか、どうやってもマッチングできない ))) Dmitry Fedoseev 2014.08.18 11:45 #49 elugovoy: あなたには驚かされますよ))))どのようなアルゴリズムで圧縮するか？ハフマン、レンペル＝ツィブ？まあ、テキストライターとしては4〜8倍の圧縮率が得られるでしょう。圧縮アルゴリズムが、ファイルごとに異なる再符号化ツリーを作成することを考える。つまり、ソースファイルには1つのツリーがあり、検索するデータの部分には別のツリーがあることになる。 ただ、面白いのは、理論的にでも、どうやって検索するんだ )))データ圧縮はコーディングに他なりません。暗号に例えると、2つの異なるメッセージ（圧縮データ）を異なる鍵（再符号化木）で暗号化したものです。検索機能はおろか、どう考えても比較にならない )))おっと、ここでいろいろと打ちのめされましたね。子供でも理解できるはずだと思うんです。あるテキストをあるアルゴリズムで圧縮すれば、今日も明日も圧縮された形で全く同じものができる。同じ圧縮アルゴリズムを使って、2つの異なるテキストを圧縮すると、完全に同一のデータ列が2つ得られると言うことですか？ Yuriy Zaytsev 2014.08.18 11:45 #50 Integer: ただの陰謀だ。もちろん、何でもいいのですが、検索を想定しています。とまで推測しています。>>> 何を探しているのかわからない・・・。 >>> すべての配列を繰り返し見て、計算をする必要があります。 まあ～そうですね～、見ていても～、20枚のギガに目を通すと・・・。 基本的には、何かしらの検索や比較があることが前提です。 著者が書いたものを参考にする多分、データを縮小-圧縮-インデックス化できないのでしょう。SQLにデータを入れるのは論理的ですビジネスロジックをサーバーに渡す + データExpert Advisorは、列挙と計算のために短いデータのみをサーバーに送信します。と聞けば、すぐに答えが返ってくる。 123456789101112...21 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
探しているものを圧縮し、圧縮された状態で検索することができます。これにより、データ量を削減し、すべてのデータをRAMに保持することができます。(理論的には)
探しているものを圧縮し、圧縮された状態で検索することができます。これにより、データ量を削減し、すべてのデータをRAMに保持することができます。(理論的には)
imo - 圧縮された形で検索したければ、まず解凍しなければならない - 理論的には、圧縮された形のデータ検索のためのアルゴリズムを書かなければならない - 気合だ
そして問題は、mt4(32bit)はRAMに多くを保持できないことです。
---
大量のデータをデータベースに格納し、クエリーで計算されたデータを準備するのは理にかなっている
既成のソリューションを適用するには、自分でデータ処理の仕組みを書く以外に方法はないと思っています。
SQLは20ギガでは少ないですが、ビッグデータを保存するのに非常に適しています...。
--
独自のメカニズムを作成し、与えられたファイルを分割して読み、読み取った断片に最大量の メモリを割り当てることで高速化を図ることができます。
で、1回の計算で20ギガから数個のフラグメントを読み込む必要があります。
問題は、データベースにデータをロードしてSQLクエリで処理する方法よりも速いかどうかということです。
SQLに入力した方が早いのでは？
ichmo - 圧縮されたフォーマットで検索したい場合、まず解凍する必要があります。
最も健全な解決策は、もちろんアルゴリズムを変更することでしょう。しかし、未知数なので、ここで提案できる具体的なことは何もありません。一般的な考え方はもちろん全くないかもしれません。
例えば、複数のファイルを読み込む必要があるため、これらの読み込みは内部で「ループ」して行われる可能性があります。外側の「ループ」自体に読みを「転送」してみるという手もある。引用符が使われているのは、一般にこのような「転送」は、まったく新しいアルゴリズムをゼロから作ることになるかもしれないからだ :) 。
もう1つの手がかりは、シフトを伴う連続読み出しについて言及したことである。読み出しのみの「シフト」を必要とする反復アルゴリズムが、この問題を解決する可能性がある。しかし、それでは全く別のアルゴリズムを一から作ることになりかねません。
というか、全然関係ないんですけどね :)
必要ないのです。探しているものを圧縮することができます。ほらね！:)
---
情報量が多い（テキストファイルで20GB程度）。
情報は同じような配列で構成されており、その数は約100万個。
すべての配列を繰り返し見て、計算する必要があります。
---
20ギガから、アルゴリズムにデータを送り込む必要があります。
見ているのではなく、ファイルの形でデータを持ち、それがアルゴリズムに使われ、計算アルゴリズムに供給されているのです。
最も健全な解決策は、もちろんアルゴリズムを変更することでしょう。しかし、未知数なので、ここで提案できる具体的なことは何もありません。一般的な考え方はもちろん全くないかもしれません。
例えば、複数のファイルを読み込む必要があるため、これらの読み込みは内部で「ループ」して行われる可能性があります。外側の「ループ」自体に読みを「転送」してみるという手もある。引用符が使われているのは、一般にこのような「転送」は、まったく新しいアルゴリズムをゼロから作ることになるかもしれないからだ :) 。
もう1つの手がかりは、シフトを伴う連続読み出しについて言及したことである。読み出しのみの「シフト」を必要とする反復アルゴリズムが、この問題を解決する可能性がある。しかし、それでは全く別のアルゴリズムを一から作ることになりかねません。
というか、全然関係ないんですけどね :)
---
情報量が多い（テキストファイルで20GB程度）。
情報は同じ種類の配列で構成されており、その数は約100万個。
すべての配列を繰り返し見て、計算する必要があります。
---
20ギガバイトのデータから、アルゴリズムにデータを送り込まなければならない。
見ているのではなく、データベースを持っていて、それがアルゴリズムに使われているのです。
必要ありません。探しているものを圧縮することができます。ほらね！:)
あなたには驚かされますよ))))
どのようなアルゴリズムで圧縮するか？ハフマン、レンペル＝ツィブ？
まあ、テキストライターとしては4～8倍の圧縮率が得られるでしょう。圧縮アルゴリズムが、ファイルごとに異なる再符号化ツリーを作成することを考える。
つまり、ソースファイルには1つのツリーがあり、検索するデータの部分には別のツリーがあることになる。
ただ、面白いのは、理論的にでも、どうやって検索するんだ )))
データ圧縮はコーディングに他なりません。暗号に例えると、2つの異なるメッセージ（圧縮データ）を異なる鍵（再符号化木）で暗号化したものです。
検索機能はおろか、どうやってもマッチングできない )))
あなたには驚かされますよ))))
どのようなアルゴリズムで圧縮するか？ハフマン、レンペル＝ツィブ？
まあ、テキストライターとしては4〜8倍の圧縮率が得られるでしょう。圧縮アルゴリズムが、ファイルごとに異なる再符号化ツリーを作成することを考える。
つまり、ソースファイルには1つのツリーがあり、検索するデータの部分には別のツリーがあることになる。
ただ、面白いのは、理論的にでも、どうやって検索するんだ )))
データ圧縮はコーディングに他なりません。暗号に例えると、2つの異なるメッセージ（圧縮データ）を異なる鍵（再符号化木）で暗号化したものです。
検索機能はおろか、どう考えても比較にならない )))
おっと、ここでいろいろと打ちのめされましたね。
子供でも理解できるはずだと思うんです。あるテキストをあるアルゴリズムで圧縮すれば、今日も明日も圧縮された形で全く同じものができる。
同じ圧縮アルゴリズムを使って、2つの異なるテキストを圧縮すると、完全に同一のデータ列が2つ得られると言うことですか？
ただの陰謀だ。もちろん、何でもいいのですが、検索を想定しています。とまで推測しています。
>>> 何を探しているのかわからない・・・。
>>> すべての配列を繰り返し見て、計算をする必要があります。
まあ～そうですね～、見ていても～、20枚のギガに目を通すと・・・。
基本的には、何かしらの検索や比較があることが前提です。
著者が書いたものを参考にする多分、データを縮小-圧縮-インデックス化できないのでしょう。
SQLにデータを入れるのは論理的です
ビジネスロジックをサーバーに渡す + データ
Expert Advisorは、列挙と計算のために短いデータのみをサーバーに送信します。
と聞けば、すぐに答えが返ってくる。