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

[TheXpert]

Renat:
脳をOFFにしてブロブフラム？

いや、新たに発見した残酷な松葉杖を回避する方法を見つけようとしているのだ。

バグだからいいとか言うなよ。

[削除済み]

Renat:
コンポスターは、過去10～12年以内の議事録で仕事をし、1999年より古い議事録が重要であるかのように装うのはやめましょう。

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

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

パラメータ SERIES_FIRSTDATE とパラメータ - 必要なタイムフレームとシンボルを持つ関数 SeriesInfoInteger がある場合、なぜ手動で制限するのですか？そして論理的には、これはTFのステッチ時間を返すはずです。

[Renat Fatkhullin]

IgorM:

穴の制御は難しくないのですが、分足ではなく他のTFが 使われていることをプログラムで判断するにはどうしたらよいでしょうか。

ミニッツバーではなく、別のものがあるかもしれない」と意図的にヒステリーを起こしている人がいることは理解できます。

事実はこうだ。

1. 1999年より古い 分単位データのみの 日数は、深い歴史を埋めるために意図的に、わざわざ入れて いる。
2. 1999年以降、分単位の代わりに他の時間軸を使用することはありません。つまり、分履歴の中に ミックスがないことです。
3. 古い分足でのデイバーのインポートに 技術的な間違いはありません。日足OHLCで「素直な」分量があります。
   
4. 1980年のミニュチュアのデイバーが 私のミニュチュア分析を台無しにしている」と言うのは、本気ではない。この話題で炎上する必要はありませんし、正論 的な怒りもありません。

市販されている製品は妥協の集合体であることを念頭に置いてください。

一つの理論の純粋性を守るための最大公約数は、必然的に他の十数個の立場と対立することになるのだ。結局は、それぞれが何かを犠牲にしなければならないような、妥協の積み重ねが勝利することが多いのです。

[TheXpert]

Renat:

事実はこうだ。

1. 1999年より古い 分単位データのみの 日数は、深い歴史を埋めるために意図的に、わざわざ 入れたものです。

これがあるじゃないですか。これは どうでしょう？それとも、ブローカーは自分には関係ないと否定するのでしょうか？

[A100]

バウンダリーデートは何ですか？1999年01月01日、1999年04月01日、または...?

とか、キャラクターによって違うことができるのでしょうか？

[Renat Fatkhullin]

TheXpert:

あなたのものです。これは どうでしょう？それとも、ブローカーは自分には関係ないと否定するのでしょうか？

"具体的な内容 "がないんです。

現実と照らし合わせることなく、純粋に理論的に反応しているのですね。何が起こっているのかわからないし、理解もできない。

[Renat Fatkhullin]

A100:

バウンダリーデートは何ですか？1999年01月01日、1999年04月01日、または...?

とか、キャラクターによって違うことができるのでしょうか？

もちろん、違うんです。

分単位の配列から目的の開始インデックスを検出する5行の関数を書くのは、開発者にとって難しいということでしょうか？それも1000人に1人という例外的なケースで。

もちろん、難しいことではありません。しかし、システムの全体像には目もくれず、世間の破壊者を演じるのはとても面白いことです。

[TheXpert]

Renat:

"具体的な内容 "がないんです。

あなたも、現実とは関係なく、純粋に理論だけで反応したのですね。本質を理解することなく、理解することなく

そりゃあ、全部覚えてるよ、このスレに偶然迷い込んだ無能なナベツネなんだから。

具体的な内容が現れたら、どうするのですか？

[Renat Fatkhullin]

TheXpert:

そりゃあ全部覚えてるよ、偶然このスレに迷い込んだ無能なオタクなんだから。

具体的な話が出たら、どうするんですか？

私が書いたものを読み直すように送ります。

指導の具体性のなさを認めていただき、ありがとうございます。

[---]

Renat:

レナート 技術的な実践という観点でアプローチしてみましょう。

今、私たちが持っているもの
- このバーが1分間の履歴に基づいているのは、ちょっとした利点です。
- しかし、同じプラスでも歴史保存モデルは大きなマイナスを露呈した。分量のない古事記をどこに置くのか？
- 2、3日考えた末、履歴を数分で保存することにしたのですね。他に選択肢がなかったのです！「何でも数分」というモデルは、より美味しく感じられますね :)

つまり、妥協点を得たように見えても、片方の松葉杖を離れることで、もう片方に躓いてしまう......。

分のない古代の歴史が、あなたのサーバーにあることは明らかです。他のブローカーのサーバーでは、そのような履歴がない場合があります（この行はFiftyStarsの ものです）。

とにかく、これらを踏まえた上で
- 誰も分モデルを変えようとはしない。これは事実です。
- また、MQLに「1分」「1日」のパターンを分析する機能を追加する人はいない。どうすればいいのかがわからない。

ブローカーが自分のサーバーに「非分」の履歴を持たせるかどうかで、すべてが決まると思うのですが......。そして、これは三菱商事への質問ではありません。

分単位」モデルは、大量の情報を保存・転送する際にその利便性を発揮しています。
その一方で、分履歴に日足バーが存在するという、実は野暮ったいサプライズも司会者から頂きました。

ですから、分履歴から日足バーを削除したい人は、ブローカーに連絡してください。
問題意識を持って説明することができるかもしれません。MCのためにやる意味がない、ここにはプロジェクターがある。