サービスデスク:怠慢、自閉、間違いを認めたくない?ノンネイティブキャンドルでチャートを補完。 - ページ 7

 
220Volt:
どのような根拠で発言しているのですか?あなたは開発者ですか?そうでない場合は、「イミフ」のサインをお願いします。

イマイチではなく、開発者からの情報です。

何の質問ですか?

 
Urain:

問題を知らない人と議論するのは難しい、全ては荒らしになる。

では、バーとバーの間が2分ならどうでしょう?

もし3分だったら......?

そして、もしそれが週末の休みならどうでしょう?

平日だけど休日だったら......どうする?

もう一度、MQの歴史を見てはいけない、現実的になりましょう、ディーリングの歴史は、(MQは理想的ではありませんが、他のディーリングのモデルとして行うだろう)ほど深いと高い品質ではありません。

分の時間枠で> 1分バー間がある場合、これは別の時間枠のバーなので、次のバーに移動し、できるだけ早くあなたが条件== 1分と最初のバーを取得します。
 
pusheax:
分の時間枠でバーとバーの間に> 1分がある場合、これは別の時間枠のバーなので、次のバーに移動し、できるだけ早くあなたが条件== 1分と最初のバーを取得すると、そこから計算を開始することができますすべての見つかったバー。

ブーム、エラー、パソコンからの火花。

もし、バーとバーの間が1分以上であれば、どこかのバーでティックがなかったことを意味し、ミスバーが発生していることになります。

M1の原点として見ることができない。

MQL5でプログラミングを始めて1年以上になります。タイムフレーム上の最初のバーを見つけるアルゴリズムは非常に複雑で非効率的です。100万本のバーを検索して978 853本のバーにあるグルーポイントを見つけるよりも、ヒストリーファイル自体にグルーポイントの情報を保存して、要求に応じて14マイクロ秒以内に出力する方がMQにとっては簡単なのです。

 
Urain:

ブーム、エラー、パソコンからの火花。

もし、バーとバーの間が1分以上であれば、どこかのバーでティックがなかったことを意味し、ミスバーが発生していることになります。

M1の原点として見ることができない。

MQL5でプログラミングを始めて1年以上になります。私を信じれば、時間枠の最初のバーを見つけるためのアルゴリズムは非常に複雑で非効率的です。100万本のバーを検索して978 853本のバーにあるグルーポイントを見つけるよりも、ヒストリーファイル自体にグルーポイントの情報を保存して14マイクロ秒以内に要求に応じて出力する方がMQにとっては簡単なことなのです。

1年も経ってないのに、今までどうやって解決してたんだ?

この問題は2年前に解決したのですが、今は詳細を覚えていませんが、バー間の時間を比較することで何とかできました。

 
pusheax:

1年も経ってないのに、今までどうやって解決してたんだ?

この問題は2年前に解決したのですが、今は詳細を覚えていませんが、バー間の時間を比較することで何とかできました。

パラメーターに日付からの計算開始を入れるだけで、ユーザーがどのような日付を設定するかは自分で考えてねじ込むことができるんです。

みんな勝手に決めているのですが、普通に解決できない状況をMQが作ってしまったので、誰も普通に解決できないのです。

インジケータで作業している時に付箋で処理しようとしたら、本物のインジケータに見えなかったので、実際に計算したバーの 数を保存する偽バッファを作り、別のインジケータに送ろうとしました。

 
sergeev:

これは意見ではなく、開発者からの情報です。

ところで、ご質問は何でしょうか?

質問したわけではないんです。
 
とか、さらにその先とか、どうなんだろう?
Renat: 分ではなく、別のものがあるかもしれない」という発想で、わざとヒステリーを起こしている人がいるのだと受け止めています。

とか、こんな感じ。

Renat:
特に問題はありません。どのストーリーを使うかは、それぞれのブローカーが決めることですから。もし望むなら、少し短いがきれいなM1を放送させることだ。1999年より古いストーリーは使わなくていいんです。

実践してみないとわからない...。

Renat、あなたのMT4はプログラマーとユーザーの両方にとって完全にオープンな環境だったことを理解していますか?つまり、ターミナルから.hstファイルへのアクセスやヒストリデータのエクスポート/インポートができたのに、.hccの記述がないMT5ではヒストリデータを一切インポートする ことができないのです。間違いなく、このやり方では、ユーザーは「何か別のもの」を持っているかもしれません。

歴史の質をコントロールする仕組みを提供する

 
IgorM:
とか、さらにどうなるのかとか。

あるいはこんな感じ。

練習あるのみ...。

レナート MT4はプログラマーとユーザーの両方にとって完全にオープンな環境だったことを理解していますか。つまり、ターミナルから.hstファイルにアクセスし、ヒストリカルデータをエクスポート/インポートすることができましたが、現在のMT5では.hccの記述がなく、ヒストリカルデータをインポートすることができなくなっています。間違いなく、このやり方では、ユーザーは「何か別のもの」を持っているかもしれません。

履歴の品質管理の仕組みを教えてください

履歴の品質管理機構」については同感です。テストの履歴の穴はすべてこのような形で、この期間中、同じバーが何度もコピーされ、時には非常に長い期間にわたってコピーされるからです。
 
komposter:

戦前のどこかの年の相場がどうのこうのという細かい話ではない。誰も戦前のティックを求めているわけではありません。

チャート表示の 実装と、関連する時系列機能の操作についてである。

レナート
コンポスターは、過去10~12年以内の議事録で仕事をし、1999年より古い議事録が自分にとって重要であるかのように装うのはやめましょう。

問題ありませんし、1999年より古い日があることで、より深い歴史を見ることができます。

特に、どのような履歴を使用するかは各ブローカーが決めることなので、問題はありません。もし彼が望むなら、もう少し短く、しかし純粋なM1の放送をさせてあげましょう。1999年以前のストーリーを使用する必要はありません。

読解力、理解力というのは、決してあなたの得意とするところではありません。男は読み手ではなく、書き手である。

セルフリキッド化する

 
sergeev:


- MQLに、何が1分で、何が1日かを分析する機能を追加する人はいないでしょう。どうすればいいのかがわからない。

曖昧?

オプション 1) 履歴ファイルに追加パラメータ Basef - バーが本当に分なら0、分でなく例えば時間ならパラメータ = 60、日中ならパラメータ = 1440。

a) チャート読み込み時にチェックし、それぞれseriesinfointegerの 日付までの非ネイティブバー等の表示を禁止する...。

b) 一度チェックし、すべてのステッチポイントを別々に記録する(履歴はどこにも残らない)。

変形2) ステッチポイントの情報のみを保存 (スペースを節約するため、変形1は最近ハードディスクを占有しないと思いますが)

バリアント 3) 分のバーを追加し(分履歴の開始後 - それは週末と単純な穴です)、例えば、それらを負の値を与え、単に倍数で動作し、例えばiバー時間およびi +1が1分以上の場合は、収束点が検出されます。しかし、これは最も愚かなバリエーションです。なぜなら、すべての指標のアルゴリズムを書き直さなければならず、チャートはZhanna Aguzarovaのように醜くなってしまうからです。

IMHOのバリエーション1が最も受け入れられやすい。 何も変わっていない、ただ少し追加されただけだ。