1ヶ月前に出した質問はこれですか?https://www.mql5.com/ru/forum/1111/page878#comment_344461
フィフティースターズ
...ストーリーはそのまんまです。深い分量の歴史があるわけではありません。便宜上、より深い履歴を日足バーで表現しています。
不便な場合は、この履歴の利用を手動で 制限して ください。
その答えの骨子は、当時すでに知られていた(https://www.mql5.com/ru/forum/1111/page878#comment_344518)。
しかし、それ(答え)は、「プログラマー自身が境界日を計算し、要求された履歴の深さを制限することができる」というようなものになるのではないかと思っています。
低いTFのチャートに履歴がない場合、高いローソク足が添付される問題があり、サービスデスクに連絡しました。M1チャートで歴史の始まりに行くと、M1ではなくD1、あるいはW1からのローソク足が見えるということです。このアクセのため、SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) 関数は、M1 ヒストリーの終了日ではなく、タイムフレーム外の最初のバーの日付を返す、つまり、指定タイムフレームが結果に影響することはない。
...
SERIES_BARS_COUNT は、特定のシンボルと時間枠に属するローソク足(バー)の本数を返します。
SERIES_FIRSTDATE関数は、特定のシンボルとタイムフレームに属する、最初に開かれたローソク足(バー)の日付を返します。
詳細はこちら
...
機能は正常に動作します。
あなたが見るものは、あなたの以前の履歴品質要求の結果です。
歴史がそうさせるのだ。深い分量の歴史があるわけではありません。便宜上、より深い履歴を日足バーで表現しています。
不便な場合は、この履歴の利用を手動で制限してください。
これは率直な言い訳で、プログラマは履歴の噛み合わせの全てのオプションを予見できないので、TFの最初の日付を検索する機能を規定することができないのです。今日はああいう感じだけど、明日はまた新しい紆余曲折があって、MQの知らないところで、例えばディーリングが何かをやらかしたりするんですよ。
また、標準機能があるのになぜ必要なのかというと、一昨日の天気を出すというのがもうあからさまにバグなんです。
ここにプログラマーの問題の核心がある。
このバーを選択したTFの最初のバーとみなし、それ以前のバーを古いTFからの追加とみなす基準のバリエーションを検索する必要があります。小節の欠落(これはMQが選択した小節記録形式の直接的な結果です)、または週末/休日などの小節のギャップがある可能性があります。そして、このように看板が乱立する中で、このバーが正しいバーであると判断する方法が不明である。
MQにとっての問題の本質とは何か:(解決するという意味でなら)
履歴は、ステッチのポイント(TFの数で最大21、多くはない、実際には、2〜3がある)のデータを暗号化してファイルに縫い付けると、問題が解決します。次に、この保護された情報を読み込んで、リクエストでユーザーに出力する関数を書きます。
ありがとうございます、トレーダーは決めないでください。
金曜日の後にこのような動きをしたのは、どんな新鮮な頭だったのでしょうか。M1 タイムフレームに古いバーを挿入 することです。
長年にわたって確立された原則を覆す権利を、誰があなたに与えたのでしょうか。
不快な場合は、このストーリーの使用を手動で制限して ください。
ありがとうございます、トレーダーは決めないでください。
金曜日の後、M1 タイムフレームにシニアバーを挿入する、そんな動きをしたのは、どんな新鮮な頭脳 だったのでしょうか。
長年にわたって確立された原則を覆す権利を、誰があなたに与えたのでしょうか?
アレックス 大げさに言わないでください。TFの接着は、M1からすべてのTFを計算することを決めた後、他のすべてのTFを正しく計算するために必要でした。
覚えていれば、21個ものTF(非標準のものを含む)を計算させることができました。
それについては、何度も言われたことはありません。TFを個別に保存する旧来のシステムには戻りませんよ。
しかし、実装によってプログラマーの手間が増えることは事実です。そして、この問題は解決するのが簡単なのですが、いや、我々はあなたが何を必要としているのかをよく知っているのです :(
というのが気になるところです。
Если вам это не удобно - ограничивайте использование этой истории вручную.
アレックスは大げさではなく、M1からすべてのTFを計算することが決定された後、他のすべてのTFを正しく計算するためにTFの接着が必要となったのです。
履歴に識別子を設定し、読み出し時にバーのデータがM1に属さない場合はM1に出力しない、M5に属さない場合はM5に出力しないようにすることで解決します。そうですね...現在の期間のバーとそれより高い期間のバーを結合する日付をFirstDateに記述して、ユーザーはどの日付から処理を開始すれば古いバーを捕捉しないかを実際に知ることができます。
確かにこの状況はモロいですね。
このようなグラフは描けないし、関数からこのような値を返すこともできない。
M1から作りたいなら作ればいい。M1が足りない-抜け出す方法を考えよ、ただし我々を犠牲にするな。
(勿論、MQ宛)

- www.mql5.com
そうですね、ゴミです。
そして、ピリオドの区切りがあれば、それは美しさです。
そして、それをコードでひねり出すのです((。

- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
低いTFのチャートに履歴がない場合、高いローソク足が添付される問題があり、サービスデスクに連絡しました。つまり、M1チャートで歴史の始まりに行くと、M1ではなく、D1、あるいはW1からローソクが見えるのです。このアクセのため、SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) 関数は、M1 ヒストリーの終了日ではなく、タイムフレーム外の最初のバーの日付を返す、つまり、指定タイムフレームが結果に影響することはない。と聞くと、「ユーザーの利便性を考えて、各シンボルの時間枠ごとの締切日を手動で設定すべき」という言い訳が返ってきました。失礼ですが、この関数は関数 SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) で行うべきで、結果が同じなら、指定したTF M1のSERIES_FIRSTDATEとは どう違うのですか?
何をバカなことを言ってるんだ。誰が、なぜ、便利なのか?M1チャートでW1ローソクを見たい人はいないでしょう。まあ、マゾヒストは別として.
私の結論は、開発者が自閉的か(上と下が当たり前、むしろ当たり前でなく、仕事は5+という彼らの世界で生きている)、直すのが面倒くさいか、「どうして私たちは間違えない、みんないい子」の原則か、です。まあ、ふざけている、直し方がわからないというバリエーションもありますが。
このスクリーンショットを見ると、異なるTFの履歴の結合線がはっきりとわかると思います。
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
クエリ 1:
端末のバージョンとビットレート
ビルド712 x86
問題の説明
小さい時間軸のヒストリカルデータは、大きい時間軸のヒストリカルデータに引き継がれます。例えば、M1のEURUSDの履歴は1999年04月01日までで、M1チャートの左側には1999年04月01日以前の期間のD1チャートが添付されていることを意味します。
添付のスクリーンショットでご確認いただけます。このため、SERIES_FIRSTDATEパラメータを持つSeriesInfoInteger関数は正しく動作しません。この関数は、シンボル期間の最初の日付の代わりに、履歴全体(タイムフレームD1、W1、MN1を含む)の最初の日付を返します。
一連の動作
グラフをスクロールして歴史の始まりへ
得られた結果
より大きな時間枠のヒストリカルデータを用いたチャートの続き。
期待される結果
指定されたタイムフレームのヒストリーデータ終了時にチャートを制限する。
追加情報
要望2.
端末のバージョンとビットレート
ビルド712 x86
問題の内容
ドキュメントに記載。
series_bars_count.
現時点での1シンボル期間あたりのバー数
長
シリーズ名
現在のシンボル期間の最初の日付
時分
下位TFの履歴が入るため、下位TFに特定期間の履歴がなく、上位TFに同期間の履歴がある場合、例えばM1のチャートでは、D1のチャートからローソク足が表示されることになります。
この問題の解決策は準備されているのでしょうか?現時点では、手動で制限する以外に、この問題の解決策はあるのでしょうか?
アクションの流れ
これらの機能を利用する
得られた結果
低タイムフレーム(D1まで)のSERIES_BARS_COUNTは、シンボルとタイムフレームに属するキャンドル(バー)の数、および履歴データが利用可能である最も近い大きなタイムフレームからキャンドルの数を返します。
SERIES_FIRSTDATE関数は、低い時間枠(D1まで)の場合、履歴の中の最初のローソク足(バー)の開始日を返します。
期待される結果
SERIES_BARS_COUNT は、特定のシンボルとタイムフレームに属するローソク足(バー)の本数を返します。
SERIES_FIRSTDATE関数は、指定されたシンボルと時間枠に属する、最初に開かれたローソク足(バー)の日付を返します。
詳細はこちら
...
機能は正常に動作します。
あなたが見るものは、あなたの以前の履歴品質要求の結果です。
歴史がそうさせるのだ。深い分量の歴史があるわけではありません。便宜上、より深い履歴を日足バーで表現しています。
不便な場合は、この履歴の利用を手動で制限してください。