エラー、バグ、質問 - ページ 681

[x572intraday]

Renat:
考えがまとまってないようですね。ごく稀なケース（0％に近いケース）のバー特性の追加計算には自分の時間を割くことを恐れ、100％のケースにはたくさんのデータを用意し、何倍もの速度とメモリを消費することを嬉々として要求している。害虫の話をするときが来たという壁に向かって自分を殺すために、そんな素敵なアドバイスを整然とする人もいます。この種の軍師はすぐに目につきます。

もしあなたが、この記事といくつかの過去の記事に関する私のすべての記事を注意深く分析し、そしてフラクタル上のグラフィックTAマークアップの多時間指標で 遊ぶならば、あなたはもはや氷水のバケツの後のように、この話題で私と議論したいとは思わないでしょう。しかし、問題は、インジケータが完全に最適化されていないこと（このトピックには関係ない）、機能的に完全ではないことです。だから、完成させてリリースすることではなく、無意味なことにリソースを浪費してしまうのです。

グラフィカルなオブジェクトが多いですね。しかも、まだ掃除が残っている...。問題は十分にある。

[Renat Fatkhullin]

これは特殊なケースです。

[x572intraday]

Renat:
特に、このようなケースを想定しています。

ライブオートトラックは、手持ちで取引する人全員よりやや少ない人数に望まれています。オシレーターやスライダーなどでMTS/ATSを書く人、やらせましょう。 私はこのインジケータを「あそこのラインから」というオートトレードに使いたいのですが、MQLは自分ではラインを見ることができません。そうすれば、16GiGさえもあざやかに見えるようになり、資源とはまったくおさらばできるのです。

[Andrey F. Zelinsky]

Yedelkin:

投票がありそうな予感がします :)

あるいは壁際で誰かを殺す :)

[x572intraday]

発明家・パイオニアの頭の中にある最初のアイデアも、プライベートなものとして彼一人の中に巣くっていたのだ。その後、人気が出て広まった...そして、システムツールとしてデフォルトで組み込まれるようにまでなりました。見慣れた光景でしょう？

そうでなければ、何も発展しないのですから......。

[削除済み]

abolk:
あるいは壁際で誰かを殺すこと :)

その方が可能性が高いですからね。

そして、私の質問には答えてもらえず、BODに手紙を書く羽目になりそうな予感が...。:(

[Renat Fatkhullin]

MetaDriver:

2.見たことがあるそれで？ミスバーが多い？私もそのことに幻想を抱いているわけではありません。問い合わせがあります。全くオリジナルではなく、決して「私物化」しているわけではありません。すなわち、端末メーカーが自動的に（！！）サポートする気配値（低流動性のものも含む）へのアクセス（と表示）モードで、気配値のセッション中の穴はすべて{Volume=0, Open=High=Low=Close=[ previous barclose price]} というパラメータでかわされます。 このモード、需要があると思いますか？ それとも私が大元なのでしょうか？素直になれよ、レナト。右手を左の心臓に当てる。

私の経験では、空白を埋めることはナンセンスで自己欺瞞であり、その埋められた物語を手に入れたらすぐに解けることがはっきりわかっています。

この問題は、この10年間、何度も指摘されてきた。

[Renat Fatkhullin]

x100intraday:
ライブオートプロッティングは、手を動かす人全員より少し少ない人しか望んでいません。オシレーターやスライダーなどのMTS/ATSを書く人は、彼らに任せて、私はこのインディケータを「あそこの線から」オートトレードに使いたいのですが、MQL自身は線を見ないので、平行法に入って、斜辺の根を探して、Gann Scale square matrixに記入して、そのインディケータにEAを適用しなければならないのです。そうすれば、リソースとは全くおさらばです。16ギガはここでコケるでしょう。

つまり、あなたは、自分の解のための重い事前計算を私たちに押し付けて、その結果、幸福がもたらされると考えているのです。

つまり、結果として端末のパフォーマンスを100％台無しにし、さらに大量のメモリを浪費することになることを、評価すらしないのです。それは悪意のあるアドバイスです。

複雑な解法を開発する場合は、問題を直接解こうとするのではなく、その 都度、計算量を減らすアルゴリズム的な方法を用いる。必要なデータが入ったキャッシュをバックグラウンドで準備する。

[x572intraday]

Renat:

つまり、あなたは、自分の解のための重い事前計算を私たちに押し付けて、その結果、幸福がもたらされると考えているのです。

つまり、結果として端末のパフォーマンスを100％台無しにし、さらに大量のメモリを浪費することになることを、評価すらしないのです。これは悪意のあるアドバイスです。

複雑な解を作る場合は、正面から問題を解決しようとするのではなく、特定の ケースごとに計算量を減らすアルゴリズム的な方法を使う。必要なデータのキャッシュをバックグラウンドで準備する。

キャッシュはもちろんディスク上にあるべきで、どこかにあるわけではありません...。をRAMに保存しますか？ファイルの読み書きの操作のことですか？しかし、まず、端末を犠牲にしてまでデータベースにexact_times[]の値を積み上げているのであれば、これほど便利なことはない。優れた開発環境は、すべてのユーザーにすぐに使えるツールを提供し、各ユーザーが自分で工夫できるものであるべきですが、すべてのユーザーに同じ作業を孤独に強いることは非情なことです。それは、具体的な内容についての話です。特別なものなんてないし、期待してもしょうがない、錯覚だ。私自身がフォーラムに参加しているのは、むしろ提案や新しいアイデアをもたらすためで、あとはすでに組み込まれている機能についての質問だけです（望むなら、ヘルプを勉強することもできますよ）。そして第二に、MQL-coderによる解析の不条理さを思い知らされます。それは、ある特定のファイルのためにアーカイブ全体を引っ張ること、そして正確に選択された一つのファイルを引っ張らないことを思い知らされるのです。極値の正確な時刻を事前計算すれば、間違いなく時間とマシンリソースがかかりますが、それに劣らず自分たちの分析にリソースが使われることになります。なんか、Cの方がMQLより少し早く動くような気がするんだけど...。憶測か事実か？そして最悪なのは、表示されているオブジェクトの現在の状態を定期的にチェックしなければならないこと、つまり部分的な再計算が必要になることです。それらを回避するためには、以前に計算したデータをキャッシュから取り出す必要がありますが、それは前回の「最初」のものです。

[x572intraday]

結局、これは端末に機能として組み込まれており、端末が正確なバータイムを計算するかどうかを任意に選択できるようになっている。これは標準的な方法で、精度とタイミングのどちらかをユーザーに選択させます。しかし、MQLプログラマーが、端末開発者がバーの追加属性を事前に計算するべきだと考えている可能性は、奇妙であり不真面目である。もちろん、私たちにもできることはたくさんありますが、客観的に見ようとする端末開発者とMQLプログラマーとの役割分担を明確にする必要があります。