MQL5でiClose/iOpenの時系列アクセスなどを操作した場合の不具合。 - ページ 2

新しいコメント
 
Stanislav Dray:

では、なぜ私の場合はフリーズが起こるのか、教えてください。つまり、M1によるCopyTimeの更新がOnTickの他の処理を開始するトリガーとして機能し、CopyTimeの前には関数やインジケータポーリングはありません。

また、なぜ30日のビルド以前はそのような問題がなく、2017年10月以降はすべて問題なく動作していたのでしょうか？

私がアドバイスしたとおりにしてください。

それ以外の場合は、100％再生するためのフルマテリアルが必要です。
 

なぜ開発者は、（複数のツールにまたがる）データの同期配列を保証する関数を書かないのでしょうか。そうすれば、人々は悩まず、無駄な時間を過ごすことができます。

やはり、MT5はクールで便利なツールという位置づけなのでしょうか？

楽しみだ

 
Vladimir Karputov:

また、他の人のタイムフレームで作業する場合、そのタイムフレームから1分間に1回OHLCを取得することが常に推奨されています（任意のCopyXXXX関数）。これは昔からそうでした。

スラバは2分に1回と言った。探すのが面倒ですが、正確に覚えています。

 
transcendreamer:

なぜ開発者は、人々が悩んだり時間を無駄にしないように、（複数のツールにまたがる）データの同期配列を保証する関数を書かないのでしょうか？

やはり、MT5はクールで便利なツールという位置づけなのでしょうか？

お待ちしております

はい。必要なシンボルと時間枠の数のコンストラクタを計算するOnCalculate。または、OnCalculateに加えて、新しいオブジェクト、例えば、最大255 OnCalculate用の "MainCalculate "を導入し、OnCalculateオブジェクトが住んでいる - それを必要としない人は、古い1 OnCalculateを使用して、mtfと異なるシンボルを必要とする人は "MainCalculate "を使用してください。バーの最初のティックと最後のティックは、すべてのシンボルと一致する時間枠で同じです。OnCalculateはすでに開発され確立されているため、タイムフレームやシンボルを仲介する他の機能を持たず、第三者のシンボルやタイムフレームの呼び出しをすべてOnCalculateのアグリゲーションで出力することが論理的である。

 

インジケータが耐えられないほど遅く、1ティックあたりの受信/レイアウトに数百ミリ秒、あるいは数秒かかる場合、データ（特に保証データ）はどこで利用できるかを考えてみてください。その結果、ティックを処理する時間的に十分なCPUがなく、赤字が累積し、それに伴いチャート履歴が滞ることになります。

ギブ保証」というのは、「何も知りたくない、好きなように書き続けたい、パフォーマンスやロックのことは考えたくない、ただギブしてくれ」という要望である可能性が高いのではないでしょうか？


何百万本ものバーが使えるようになったら、自分や他の人の指標のパフォーマンスを考えてみてください。下手で高価なインジケータは、そのシンボルチャートの更新を簡単に停止させることができます。

まず、OnCalculateの応答時間をマイクロ秒単位で測定 します。次に、1秒を平均ティック応答時間で割ると、1秒あたりのティック数でインジケータの最大ブレークダウンが得られます。

これはすぐに身が引き締まる思いです。

 
Artyom Trishkin:

2分おきに、スラバが言った。探すのが面倒だけど、ちゃんと覚えてるよ。

覚えていますが、いつも1分間隔にしています。その方が信頼性が高いですからね。

 
Farkhat Guzairov:

失礼ですが、今回の場合、M15のタイムフレームでの履歴の深さは120本で、えっ、もうMQL5にとっては致命的なんですか？

再生可能な素材を提供していない。

他人のデータにアクセスする機能が、そのシンボルに リタ-ド表示があるとリタ-ドになる理由を説明しました。チャート上の他の指標の存在を完全に無視して、自分の特殊なケースのコールの話をしている。そして、特に私が明確に書いていることから始めるべきものなのです。

専門家との技術的な証書や指標のリストが全くないデマゴギーや比較発言はやめましょう。

再現するためのコードを教えてください。

 
Farkhat Guzairov:

***

では、どのように再生するのでしょうか。再生用データをください。

 
Farkhat Guzairov:

もちろんここにコード全体を載せることはできませんが、問題が発生する部分はすでに指摘しましたので、もう一度説明します。

全コードか、何も言わないか、どちらかです。フルコードがないと、ただの空気になってしまいます。

 
Renat Fatkhullin:

あなたの指標は耐え難いほど遅い受信/適用ティック、1ティックのためにミリ秒あるいは数秒の数百を費やしているときに、データが（より多くのそれは保証されている）利用可能になる場所を考えてみてください。その結果、どのCPUもティックを処理する時間が足りず、赤字が累積し、チャート履歴が滞ることになる。

ギブ保証」というのは、「何も知りたくない、好きなように書き続けたい、パフォーマンスやロックのことは考えたくない、ただギブしてくれ」という要望である可能性が高いのではないでしょうか？


何百万本ものバーが使えるようになったら、自分や他の人の指標のパフォーマンスを考えてみてください。下手で高価なインジケータは、そのシンボルのチャート更新を簡単に停止させることができます。

まず、OnCalculateの応答時間をマイクロ秒単位で測定します。次に、1秒を平均ティック応答時間で割ると、インジケータの最大ティック処理能力が1秒あたりのティック数で得られます。

これはすぐに身が引き締まる思いです。


超高速は必ずしも必要ではなく、使い勝手が非常に重要です。現在、多通貨のインディケータを 書く作業は、「手で夕日を見る」ようなものです。MT4でも簡単でした。そこはi機能でゆっくりでも、必ず取得できたので。MT5ではデータがあるかないかで、自分で特別なコードを作らないといけないのです。


また、すべてのユーザーがハイクラスなプログラマーという わけではなく、超音速でなくとも便利で信頼できる ツールが必要な人もいること、ポートフォリオシステムには通常そのようなスピードは必要なく、この場合、最大スループットは重要ではなく、大事なのは保証されて簡単に動くこと、実際、これが製品をより普及させる要因でありアクセスしやすくすることだと心に留めておく必要があります。


mt5のi-functionsの登場は状況を多少改善しましたが、問題を解決したわけではありません。複数の楽器の同期した配列を簡単かつシンプルに取得する可能性はありません。


機能名：GetSyncData

入力：シンボル、タイムフレーム、バー範囲および/または日付範囲のリスト

出力：すべてのシンボルのインデックスが同じ時間に対応するように、MqlRatesの要素を持つ配列

12345678910
新しいコメント