多くの人にとって興味深いトピック：MetaTrader 4とMQL4の新機能 - 大きな変更が控えています。 - ページ 50

新しいコメント
 
MetaDriver:
そんな文字があるのです。しかし，ギャップ（引用符の不連続なジャンプ）は，バーの始まりだけでなく，いつでも起こりうる。 どんな「間引き」フォーマットも，定義上，罪がないわけではない。 ティックでだけフルフィード。 そして，カップの履歴ではさらにフルになりうる。 私は，自分自身のために分フォーマットを作ろうとしているが，今のところ，その妥協点は見つかっている。私は上記のように（Openなし、{Hi-Lo-Close}のみ）残すかもしれません、私はすべての欠点を理解し、それは私のテスターのための私のコーディングの一つのバージョンです。 私は生のティックを使用して、任意のメソッド（保存ティック形式{bid -ask-time} で）で人為的にそれをカットします。
そう、バーはもともと日数に合わせて作られているのです。彼らにとっては、閉じたり開いたりすることが重要であり、ギャップは頻繁に発生します。小さければ、それ自体は重要ではありません。セッションのオープニングとクロージングはまだ役割があるかもしれませんが、確かに議事録ではありません）イムハ
 
MetaDriver:

判断せずに理解しようとすることは、私の最も重大な罪であるとは思いません。;)

考えること--もちろん、罪の重さという点では、より大きなものである。私もそう思います。
 
hrenfx:
罪の重さで言えば、もちろん考える方が強い。私もそう思います。

よくぞ言ってくれた！じゃあ、俺の隣に大鍋を用意してくれ。 雑談の時間がたっぷり取れるぞ。仮釈放はない。

;)

 
MetaDriver:

MQバーM1がアンパックで保管されているのは確かですか？

では、なぜ履歴の取得には（わずかですが）遅延が発生するのに、再適用（キャッシュへの再適用など）は速いのでしょうか。

どうやら履歴ファイルでは、バーはシンクロバーからの変更として保存され、それらは圧縮された形で保存されているようです。

つまり、52バイトというカウントは、解凍された履歴のカウントということになります。

 
Urain:

MQバーM1がアンパックで保管されているのは確かですか？

では、なぜ履歴の取得に遅れが出るのに（少ないがある）、再適用（キャッシュへの再適用など）は早いのだろう。

どうやら履歴ファイルでは、バーはシンクロバーからの変更として保存され、それらは圧縮された形で保存されているようです。

つまり、52バイトについての計算は、アンパックドヒストリーの計算ということになります。

それだけでなく、私は何も言っていないのですが......きっとパッケージがあるのでしょう。フォーマットは公開されていませんし、"クラック "しようともしていません。

というわけで、すべて正しく、解凍されたフォーマットのみを記述しました。ドキュメントから引用しています。

 
MetaDriver:

そんなことは言っていない、そればかりか、きっとパックされているのだろう。フォーマットは公表されていないので、「パクろう」と思ったわけではありません。

そうなんです、記述されている解凍されたフォーマットしかないんです。ドキュメントから引用しています。

その通りなのですが、解凍した現行フォーマットと部分的にパッケージ化した新フォーマットを比較しながら、新フォーマットが経済的になることを示そうとしているのですね。
 
Urain:
その通りなのですが、現在のパックされていないフォーマットと、部分的にパックされた新フォーマットを比較しながら、新フォーマットが倹約につながることを示そうとしているのですね。
私は経済を比較していない、あなたはそれを想像している、ちょうど情報です。 経済はありません、私のアンパックされたフォーマットはより大きい== 88バイト{オープン、ハイ、ロー、クローズ}と== 72バイト{ハイ、ロー、クローズ}である。
 
MetaDriver:
私は経済を比較していない、あなたが想像した、唯一の情報性。 いいえ経済は、私のアンパックされたフォーマットは、より== 88バイト{オープン、ハイ、ロー、クローズ}と== 72バイト{ハイ、ロー、クローズ}です。

まあ、石で癌になっちゃダメなんだけどね。52バイト88ではなく、情報量を2倍にするだけでも良かったのでは？

hrenfxが 提案した最初から同じです。

 

なぜ、これだけのデータ量を持つフォーマットが全く存在しないのでしょうか？つまり、純粋なティックヒストリーと 結果が変わらない場合、このティックフィルタ（このフォーマット）の制限を定義する必要があるのです。

一見すると、単純なティックフィルタHighBid+LowAskの方がスマートなものよりも（データ量に応じた）悪いとは言えません。

Close-dataは、多通貨の同期にのみ有効です。

もしかしたら、そんなことをするよりも、もっと小さな時間軸に切り替えた方が楽なのかもしれませんね。例えば、S20ではHighBid+LowAskのフォーマットで同じ分量なら48バイトで済みます（1価格あたり4バイトならもっと少ないかもしれません）。私のテスターでは、すべてをlong intで行っています（非常に高速です）。また、精度の面でも、100％なら88バイトでミニッツフィルターに勝てるでしょう。

追伸：関数Error(Freq, DataSize) = Full - Freq * DataSize は、Freq を 増加させるとゼロになる傾向があります。

ここで、Errorは 情報の損失である。

Full- 完全なマーケット情報。

Freq * DataSize は「掛け算」関数で、Freq 量子化周波数で復元できる情報量と、各量子化項に対する情報量（DataSize）である。

 
hrenfx:

なぜ、これだけのデータ量を持つフォーマットが全く存在しないのでしょうか？つまり、純粋なティックヒストリーと 結果が変わらない場合、このティックフィルター（このフォーマット）の制限を定義する必要があります。

一見すると、単純なティックフィルタHighBid+LowAskの方がスマートなものよりも（データ量に応じた）悪いとは言えません。

Close-dataは、多通貨の同期にのみ有効です。

もしかしたら、そんなことをするよりも、もっと小さな時間軸に切り替えた方が楽なのかもしれませんね。例えば、S20ではHighBid+LowAskのフォーマットで同じ分量なら48バイトで済みます（1価格あたり4バイトならもっと少ないかもしれません）。私のテスターでは、すべてをlong intで行っています（非常に高速です）。精度の面では、88バイトのミニッツフィルターに100％勝てるでしょう。

トレーディング、自動売買システム、ストラテジーテストに関するフォーラム

多くの人にとって興味深いトピック：MetaTrader 4とMQL4の新機能 - 大きな変化がやってくる

アヴァルス さん 2013.08.11 15:43

これをどうしたらいいのかわからないと、中途半端な対策であることを忘れてしまうかもしれません。ちゃんとしたティックテスターが必要だ。

p.s.チップスに普及するのであれば、それはそれでよいのですが)


1...434445464748495051525354555657...75
新しいコメント