Mt4 サポート終了。 - ページ 29

新しいコメント
 
Реter Konow:

主な欠点：OOPは、コードを多くの関数に断片化する道を歩まざるを得ない。

人間は断片化されたコードを受け入れやすいのですが、断片化はどんな仕組みにも禁忌なのです。

なるほど、でもデメリットは？

これが最大のメリットです！まさに、断片化されたコードを認識しやすいからです

コンピュータが人間に合わせるのではなく、人間がコンピュータに合わせなければならないのです。

 
George Merts:

その通りですが、デメリットは？

それが最大の利点です！まさに、断片化されたコードを人間が理解しやすいからです。

コンピュータが人に合わせるのではなく、人がコンピュータに合わせるのです。

開発者は、自分の快適さよりも、まず自分の作った機構の効率を考えるべきですね)) 。

そうしないと、メカが "ぐにゃぐにゃ "になってしまいます。

開発者はコンピュータに合わせる必要があります。

 
Реter Konow:

引用元が同じサーバーであれば、どの楽器でもかまいません。結局のところ、それぞれの楽器でバーが同時に開くのです。

引用元が世界各地にある場合は別です。分単位の場合は問題ありませんが、それ以上の時間軸の場合は問題があるかもしれません。おそらく、時間関数をもっと詳しく研究し、正確な時間補正を行う必要があるのでしょう。しかし、それはこのソリューションの次のステージの話であって......。

この機能にはキャリブレーションが必要なのですが...。

最初は、すでに質疑応答があった場合に備えて、私以外の書き込みをすべて読みたかったのですが、後で引用が必要な書き込みを探すのが大変そうです。

誰もが知っているように、新しいバーは 新しい時間間隔の最初のティックまで表示されません。したがって、ミリ秒単位でバーがあるはずなのに、それがない場合、間違ったバーからインジケーターの読み取りをすることができます。

2つ目の質問は、アルテムさんからの質問なので、答えが見つかるといいのですが。

 
Alexey Viktorov:

最初は、すでに質疑応答があった場合を想定して、私以外の書き込みをすべて読みたかったのですが、引用が必要な書き込みを探すのが大変そうなので、このようにさせていただきました。

誰もが知っているように、新しいバーは 新しい時間間隔の最初のティックまで表示されません。そのため、ミリ秒単位でバーがあるはずなのに、それがない場合、間違ったバーから指標値を取得することができるのです。

2つ目の質問は、アルテムさんからの質問なので、答えが見つかるといいのですが。

はい、昨日も議論しました。

私は以前、別のプラットフォームを扱っていましたが、そこでは気配値の到着に関係なく時間でバーが形成されていました（TWSを見てください）。

MTの場合はそうではないと言われました。

新しいバー出現のイベントを確認するために、見積もり到着チェックを追加する予定です。

 
Реter Konow:

バーというのは、見積もりの到着に関係なく開くものだと、すでにお答えしています。引用符がない場合、新しいバーの価格は前のバーの終値と なります。新しいバーの事実は、クォートの到着に関係なく、タイマーで動作するカウンタ自体によって確定されます。

カウンタがその値に達すると、そのタイムフレームの新しいバーのイベントが設定されるだけなので、特定のタイムフレームは重要ではありません。これは、異なる時間枠の新しいバーの出現に同期させるための単なる方法です。の同期をとることができます。

楽器も関係ない。1つのサーバーからの引用であれば、新しいバーが出現する時間が同じであることを意味します。したがって、地球上のある地点の機器であれば、どの機器でも構わないのです。


言ったことを終わらせて、他のことをする。ちょっといいもの)。

そして、金曜日の終値、任意の期間の前のバーが1.20333に等しく、任意の期間の月曜日のオープンが1.20142に等しいという事実をどのように説明することができますか？

もちろんこれはあるブローカーの見積もりで、他のブローカーはもう少し違うかもしれませんが、すべてにおいて違いがあります。

 
Alexey Viktorov:

また、金曜日の終値、任意の期間の前のバーが1.20333、月曜日の任意の期間のオープンも1.20142であることをどのように説明しますか？

これはもちろん、あるブローカーの相場であって、他は少し違うかもしれませんが、どれも違いがあります。

ギャップによって説明される。それは、セッションのオープニングで起こります。

私は取引の専門家ではないので、私の意見をあまり厳しく判断しないでください）。


ましてや外為市場で何が起こっているかなんて、もっとわからない)

 
Реter Konow:

残念なことに、設計者は自分の快適さではなく、機構の効率を第一に考えなければならないのだ)。

そうしないと、メカが "ぐにゃぐにゃ "になってしまいます。

開発者はコンピュータに合わせなければならない。

いいえ。

コンピューターが私に合わせてくれるように。他にも十分問題がある。開発者が調整できるのは、コンピュータが「引き出せない」ところ、例えば性能やメモリが足りない「ボトルネック」の部分だけです。それなら、そう、開発者が調整する番です。しかし、今のところ、OOPがコンピュータに大きな負荷をかけ、それを何とか減らさなければならないような場所には出会っていません。

 
Nikolai Semko:

そんな感じです（MQL5のコード）。

でも、繰り返しますが、私はOOP支持者です。
手続き型プログラミングでは不可能 なことを示す、実に残念な例といえるでしょう。

これを始めたときは、何でもできる／できないを示すつもりはなく、今後、自分でコードを書くときに便利だからという理由でした。

でも、V.S.が言ったように、ベストを尽くしたいと思っていたのに、いつも通りの結果になってしまったんだ。

 
George Merts:

あ、いや。

私に合わせてくれるのは、コンピューターです。他にも十分問題がある。開発者が調整できるのは、コンピュータが「対応できない」ところ、例えば性能やメモリが足りない「ボトルネック」の部分だけです。それなら、そう、開発者が調整する番です。しかし、今のところ、OOPがコンピュータに大きな負荷を与え、それを何とか減らさなければならないような場所には出会っていません。

コンピュータに負荷がかかるのは、開発者が機構の一貫性という問題に無頓着なことが原因です。システムを改善するために、エネルギーを節約する気持ち。仕事を楽にするという名目で、コンピュータのリソースを無理に浪費していること。

非効率に書かれたコードにコンピュータがうまく対処する限り、開発者は処理能力に「寄生」し続けることになる。これは行き止まりの道です。

遅かれ早かれ、効果のない機構は発達を止め、より良い対応策に取って代わられるでしょう。

人間の時間と労力は無駄になり、彼の発案したものはゴミ箱行きになる。

競争の世界では、このリスクは常に存在する。

機械を設計するときは、まず性能のことを考え、次に働く時間の快適さや利便性を考えるべきです)。

 
Реter Konow:

その負担は、開発者が機構の一貫性に対して怠慢な態度をとることによって、コンピュータにかかるものである。システムを改善するエネルギーを節約したいという思い。仕事をしやすくするという名目で、コンピュータの資源を不当に消費していること。

非効率に書かれたコードにコンピュータがうまく対処する限り、開発者は処理能力に「寄生」し続けることになる。これは行き止まりの道です。

遅かれ早かれ、効果のない機構は発達を止め、より良い対応策に取って代わられるでしょう。

人間の時間と労力は無駄になり、彼の発案したものはゴミ箱行きになる。

競争の世界では、このリスクは常に存在する。

機構を開発する際には、第一に性能を考え、第二に作業時間の快適性・利便性を考える必要があります))。


プログラムを書き 終えるまでピンポイントに見つけることは不可能です。ですから、まず正しく動作する（他の開発者が読める）コードを書き、そこに最適化するものがある場合にのみ最適化すべきなのです。

1...222324252627282930313233343536...47
新しいコメント