記事"トレードにおけるOLAPの適用(パート1):多次元データのオンライン分析"についてのディスカッション
ありがとう。わかりやすい使用例がうまくいった。膝の上では、異なるスライスを素早く見る必要がある場合、うまくいった。
抽象度の高さに白い嫉妬を覚える。
ZЫ MarketInfoは、誤って記事のテキストに表示されます。ソースでは - 正常。
記事の正しいタイトルは「トレーディング結果の分析におけるOLAPの応用」であるべきだった。
タイトルが間違っているのは確かだ。
OLAP技術を使ったトレーディングにおける多次元空間での作業」とでもした方がいいのではないだろうか。OLAPとは何か、なぜここにあるのか？
一般的に、私が理解する限り、この記事では、ベクトル（統計的な意味でのベクトル：多次元空間内の点を特徴づける値の集合）を便利に格納する、あるコンテナ・クラスとそれに対応するインフラストラクチャを提案している。原理的には、このコンテナがなくても、必要に応じてデータをグループ化することは可能である。しかし、多次元空間を視覚化するのはずっと難しい。しかし、残念ながら記事には書かれていないが、OLAPには視覚化ツールがあるはずだ。
名前が間違っているのは確かだ。
OLAPテクノロジーを使ったトレーディングにおける多次元空間での作業」とでも呼んだ方がいいだろう。OLAPとは何なのか？
トレーディングに関する記事がもっとあればいいのに。
そして、プログラマーが他の分野から開発を投げかけていることがわかった。なぜなのか、誰に向かってなのかはわからない。
多くの人が口にしていたことだと思う。）
トレードに関する記事がもっとあればもっといい。
というわけで、プログラマーは他の分野から開発を投げ出していることが判明した。なぜなのか、誰に対してなのかは不明だ。
多くの人が口にしていたことだと思う。）
どうだろう、「長期トレーディング戦略の基礎としてのマーチンゲール」みたいな記事より、OLAPの記事の方が読みたい。
この記事では、トレーディングに関連するあらゆる数値データを分析するために使用できる普遍的なクラスが紹介されている（言及されている）。
私は、このツールはトレーディングに非常に有用であり、必需品の部類に入ると考えている。もし誰かがもっと「トレーダーらしい」ものを欲しがっているのであれば-どんな基準で欲しがっているのか分かりませんが-、フォーラムの該当スレッドに具体的な要望を残してください。
以下は記事の冒頭からの引用である：
//----------------------------
「取引報告書では、シンボル別、曜日別、売買別の利益の内訳を得ることが興味深い。あるいは、例えば、複数の取引ロボットのパフォーマンスを比較する（つまり、マジックナンバーごとに別々に）。
引用終了。
//----------------------------
これは実用的な問題であり、その解決策は本文のさらに下に書かれている。引用終わり：
//---------------------------
"抽象的なソース（将来的には、取引口座の履歴、CSV ファイル、HTML レポート、WebRequest を 使用して取得したインターネットからのデータなど）からレコードを読み取るには、別のクラス、つまり DataAdapter が必要です。"
引用終わり。
//---------------------------
つまり、データはさまざまなソースから取得されることになっている（それらのフォーマットはあらかじめわかっている？）しかし、分析されたデータレコードのフォーマットは、すべてのレポートで同じだとしましょう。この場合、複雑なOOPやOLAPの構成を必要としない別のソリューションを提案します。
レポートは取引口座の履歴を記述する。どの取引レポートも1つのセマンティック・センター（TRADE）を持っています。このオブジェクトのプロパティは、シンボル、日付、ロット、その他無限のものです。各プロパティは、不確定な深さの値の履歴を持つパラメータです。 私たちの仕事は、自由な構成基準に基づいて素早くデータを見つけることです。 その可視化は二の次です。もちろん、データ検索の効率はその保存方法に依存しますが、ここで疑問が生じます。レポートの主な対象であるトランザクションのプロパティは無限に多様であり、各プロパティの状態（パラメータの現在値）は、他のパラメータの値の履歴の類似性を検索するためのフィルタとなり得るからです。言い換えれば、データ集計の選択肢は無限にあり、あらかじめ用意され構造化された複合体に履歴を分散して保存しようとしても、抽出効率や集計速度の低下にはつながらないということか。もちろん、そうなる。
私が考えられる唯一の普遍的なデータの記録・保存方法は、それぞれがパラメータ値の履歴を含む並列ベクトル（リソースなど）を作成することです。トランザクションは特定の時間に結びついているので、通し番号があり、したがって、各トランザクションは任意の数のプロパティを組み合わせ、その値の履歴はn個のベクターに記録される。これが、私が提案するレポートデータの整理と保存方法の本質である。これ以上普遍的なものはないだろう。
さて、データ集計について。もちろん、可能な限りベクトルの並列性を使うべきだし、タスクが複雑になれば通常の検索サイクルを使うべきだ。このために複雑な構造化システムは必要ない。普遍的な解決策は、データ・フィルタリングのさまざまな方法を用いてメインの集計関数を作ることだ。つまり、-補充可能なフィルターセットを持つ1つの作業ブロック。すべて。
//---------------------------
OLAPは間違いなく良い手法だ。
しかし私の率直な意見では、OLAPの最大の特徴は統合にある。ストレージや他のデータソースと。そうすれば、分析の可能性は劇的に広がる。そして、独自のデータセットを持つ1つのアプリケーションの内部では、あまり滑稽ではありません。
次の記事で、対応する例があることを期待しています。
あーだこーだ！この記事は素晴らしいし、コードも素晴らしい。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 トレードにおけるOLAPの適用(パート1):多次元データのオンライン分析 はパブリッシュされました:
この記事では、多次元データ(OLAP)のオンライン分析のフレームワークを作成する方法、およびMQLで実装する方法、およびトレード口座ヒストリー処理の例を使用してMetaTrader環境でそのような分析を適用する方法について説明します。
トレーダーは、多くの場合、膨大な量のデータを分析する必要があります。 多くの場合、数字、相場、インジケータ値、トレードレポートです。 数値が依存するパラメータと条件の数が多いため、それを部分的に考慮し、プロセス全体をさまざまな角度から表示します。 情報の全体量は仮想ハイパーキューブの一種で、各パラメータが独自のディメンションを定義します。 このようなハイパーキューブは、一般的なOLAP( オンライン分析処理)技術を使用して処理および分析することができます。
アプローチ名の "online(オンライン)" はインターネットを参照するのではなく、結果の迅速性を意味します。 操作原理はハイパーキューブ セルの予備的な計算を意味し、その後、キューブの断面を視覚的な形式ですばやく抽出して表示できます。 これは、MetaTraderの最適化プロセスと比較することができます。つまり、テスターは最初にトレード亜種を計算し(長い時間がかかる可能性があり、プロンプトではない)、インプットパラメータにリンクされた結果を特徴とするレポートを出力します。 ビルド1860以降、MetaTrader5プラットフォームは、さまざまな最適化基準を切り替えることで、表示された最適化結果の動的な変更をサポートします。 これは、OLAPの考えに近いです。 しかし、完全な分析には、ハイパーキューブの他の多くのスライスを選択する可能性が必要です。
ここでは、メタトレーダーにOLAPアプローチを適用し、MQLツールを用いた多次元解析の実装を試みます。 実装に進む前に、分析するデータを決定する必要があります。 これらには、トレードレポート、最適化結果、またはインジケータ値が含まれます。 この段階での選択は、あらゆるデータに適用可能なユニバーサルオブジェクト指向エンジンの開発を目指しているため、重要ではありません。 しかし、特定の結果にエンジンを適用する必要があります。 最も一般的なタスクの一つは、トレードレポートの分析です。 このタスクを検討します。
作者: Stanislav Korotky