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

[hrenfx]

心配しなくても、社内にCloudを用意しつつ、M1に限りなく近い精度のMT5テスターが（皆無ではない）あるはずです。

MT5の開発者がこのようなシナリオを悪化させることはあり得ません。

[Vladimir Gomonov]

Urain:

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

hrenfxが 最初から提案していたのと同じことです。

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

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

メタドライバー さん 2013.08.11 17:04

--

実は、このフォーマットは今、私自身の目的のために開発しているもので、ここに公開するのはその副産物です。 誰かが役に立つかもしれません。

ps. "Mql_6_PackedRates" と "Mql_6_Rates" という名称は、実際には何も対応していないので、純粋に偶然（芸術的気まぐれ）と考えるべきでしょう。 私のプロジェクトでは別の名称にしています。

pps. "著者の意見が必ずしも一致するとは限らない"。(c) ペレヴィン

[Vladimir Gomonov]

hrenfx:

心配しなくても、クラウドオプションを社内で利用できるM1に限りなく精度の高いMT5テスターが（皆無ではない）あるに違いない。

MT5の開発者が、そんなシナリオを悪化させるわけがない。

私たちは待っています。

;)

[Anatoli Kazharski]

MetaDriver:

待機中...

;)

何でも待つのはいいが、自分でやったほうがいい。待たなくても、自分の方が良いものができるかもしれません。)))

[Mykola Demko]

tol64:
何でも待つのはいいが、自分でやったほうがいい。そうでないと、待てないかもしれないし、自分の方がいい結果になるかもしれない。)))

より良いものについてはわかりませんが、確かに待っていると年を取りますね :)

[Vladimir Gomonov]

tol64:
何でも待つのはいいが、自分で作った方がいい。そうでないと、待てないかもしれないし、自分の方がいい結果になるかもしれない。)))

"そして、あなたは正しい！"(c) 人気のあるスーフィーの本

ウラン です。
より良いものについてはわかりませんが、それを待っているうちに歳をとってしまうこともあるのです :)

"-そして、あなたも......"

;)

[Mykola Demko]

MetaDriver:

"そして、あなたは正しい！"(c) 人気のあるスーフィーの本

"-そして、あなたも......"

;)

ティックテスターを書いたほうがいい、ティックがポンポン入ってくる履歴がある（ディリング提供の束）し、テストするものがない。

[Vladimir Gomonov]

Urain:
ティックテスターを書いたほうがいい、ティック履歴はいくらでもダウンロードできる（多くのディーラーが提供している）、しかし、それをテストするものがない。

なぜ、私がフォーマットをいじってると思う？:) テスターの入力を処方しているのですが・・・。

[hrenfx]

Urain:
ティックテスターを書いたほうがいい、ダウンロードするティック履歴がたくさんある（ディリングオファーがたくさんある）、それらをテストするものがない。

MT4、JForex、StockSharp、Forex Connect、...- は、いずれもティックテスターを搭載しています。悪気はないのですが、気持ちとしてはティックテスターが欲しくなってしまうのです。

ティックテスター自体が一番ダサい。現在のオーダーテーブルのストレージを書き込んでいるだけです。つまり、そのデータ構造を 一度書けばいいのです。そして、それがほとんど全てです。

そうですね、毎ティックごとにオーダーテーブルの各要素をチェックし、入力されたティックに応じてステータスが変わったかどうか、2つの価格との比較を行います。

全部で、プログラマーが自分の膝で書くと2時間かかる。難しいことは何もありません。

1日あたり10^6刻み、1シンボルずつ。倍率なら1日10^7刻みかな。ちなみに、10^6分〜27年。

フィルターがないとダメなんです。しかし、フィルターはテスターと間接的に関係しています。要するに、座っているより動いたほうがいいということです。

[Vladimir Gomonov]

Laryx:

個人的には、これらすべてのビジュアルコンストラクタは、大きな展望を持っていないとも思っています。

.......

確かに、WYSIWIGの原理が従来のコードに比べて大きな優位性を持っていれば、きっと一定のファンを持つ安定した製品が目立っていたことでしょう。残念ながら、私の知る限りでは、そのような製品はありません。

ですから、視覚的な環境づくりに力を注ぐのは、個人的には合理的とは思えません。

当たり前のことを無視して。 すべてのGUIは、昔からほとんどWYSIWIGエディターで 作られてきたのです。(c) レナート

どんな大規模なプログラミング環境（VisualStudio、Delphiなど）でも、すでに広範なビジュアルコンポーネントプログラミングツールを提供しており、コンポーネントはまったくビジュアルだけでなく、非ビジュアルのものもたくさんあり、高度なボタンから既製のHTTPサーバやデータベースへのインタフェースまで、大量の第三者コンポーネントライブラリが用意されています。

もうひとつは、「ビジュアルビルダー＋基本プログラミング言語のコード」という組み合わせがそこで使われているので、それが普通で正しいということです。 純粋なビジュアルスキーム「描いて動く」は、まだ現実的ではありません。試みはあったが、この問題は「遊んで忘れる」の域を出ていない。

最も高度なアプローチは「描画＋加算」でしょう。(イムハ)