MT5でポジションの集計構造のRELIABLEな会計を実装することは可能でしょうか? - ページ 31

 
kombat >> :

何人...

ロシア連邦の銀行は、ソ連の銀行システムの後継者であり、ソ連の銀行システムは、ツァーリズム・ロシアの銀行の後継者であり、CRの銀行は、...

計算してみてください...

;)

おそらく、周りの人にそう信じてもらいたいのでしょう。しかし、実際には歴史もなく、名前もなく、評判もないヌーボー・リッチな存在である。

 
Avals >> :

ポイントは、MT4ではマルチエキスパート取引に代表されるこのルーチンの一部が自動化され、アーキテクチャに組み込まれていたことですが、MT5ではそうはいかないということです。もちろん致命的なものではありませんが、誰にとっても便利なものではありません。

誰にとっても便利で快適なものではない、とさえ言えるでしょう

私もそうだ

しかし、ほとんどの場合、それは単なる習慣の問題です。


MT5でアグリゲートポジションの構造を信頼性の高い会計処理で実装することは可能でしょうか?


もしかしたら

ロットシステムからネッティングシステムに切り替えたときに失われる情報をファイルに保存します。

これにより、EAのパフォーマンスが低下することはありません。

-----

一般論として、開発者の話を聞くのも面白いかもしれません。

両システム同時導入に反対する理由

これによって、配信の規模が本格的に拡大すると思うのですが

となり、システム全体の速度も低下してしまいます。

が、それは聞いてみないとわからない。

 
knt-kmrd >> :

MT5でポジションの集計構造のRELIABLEな会計を実装することは可能でしょうか?


可能

ロットシステムからネッティングシステムに切り替えたときに失われる情報をファイルに保存しておく

これにより、Expert Advisorの動作が遅くなることはありません。

問題は、実装の複雑さではなく、ソリューションの信頼性である。このような方法については、すでに議論され、その信頼性の低さを示す例が示されている。

 

これらの例や「信頼性」という概念そのものが、多くの人を納得させるものではないことに留意する必要があります。あなたは日常的に概念を置き換えており、「信頼性」とは別のものを意味しているのです。


ビンゴ - 1000個目のフラバー

 
getch >> :

問題は、実装の複雑さではなく、ソリューションの信頼性です。このような方法は、すでに議論され、その信頼性の低さを示す例が示されている。


だから教えて、ダミー(事前に申し訳ありません、最初にトピックを読んでいない、テキストがたくさんある)

ファイルからの読み込みは、ヒストリーからの読み込みや標準的なμl4-functionの呼び出しとどう違うのですか?

には、何でも入れることができます。

オープン時間、オープン価格、チケット番号の設定が可能です...

お好きにどうぞ :)

 
knt-kmrd писал(а)>>

だから教えて、ダミー(事前に申し訳ありません、最初にトピックを読んでいない、テキストがたくさんある)

ファイルからの読み込みは、ヒストリーからの読み込みや標準的なµl4-functionの呼び出しとどう違うのですか?

には、何でも入れることができます。

とか、開場時間とか、開場価格とか、チケット番号とか...。

お好きにどうぞ :)

ファイルを紛失してしまったら? あるいは、ファイルへの記録中に障害が発生し、内容や注文がサーバーと一致しなくなったら? あるいは、ファイルを持たずに他社からログインしなければならなくなったら?この情報が失われる選択肢はたくさんあり、もしこの損失がアルゴリズム的に意図しないものであった場合、深刻な経済的影響をもたらす可能性があるのです。つまり、システム全体の信頼性を低下させる可能性のある新しいリンクが追加されているのです。

 
knt-kmrd >> :


だから教えて、ダミー(事前に申し訳ありません、最初にトピックを読んでいない、テキストがたくさんある)

ファイルからの読み込みは、ヒストリーからの読み込みや標準的なμl4-functionの呼び出しとどう違うのですか?

には、何でも入れることができます。

オープン時間、オープン価格、チケット番号の設定が可能です...

お好きにどうぞ :)


という質問には、先ほどの「2つの会計システムの導入と複雑さ」についてもそうですが、どう違うのでしょうか。

合併症もなく、確かに配分が増えることもない...。

会計の問題は、サーバーのデータベースへの単純なクエリであるほとんどの平面にあります。

繰り返すが、サーバーのデータベースに、つまりどこにいても、どんな端末からでも、だ。

当社のファイルを削除してもしなくても、正常な動作が保証されます。セルフビルドとは対照的に...。

 
実際には、ファイルが復活する可能性なしに殺すことができるのは、たった1つのケースだけです。

もし「邪悪なハッカー」がハードディスクにハンマーを叩き込んだら

で、ファイルが減圧され、中のデータが消えてしまう。
しかし、この場合、EAが死んでいるので、MT4でも救われません。

また、突然の停電などの場合もあります。
ディスク上のデータ(つまりファイル内のデータ)が保存されます。

---

ただし、いたずらなプログラム(例えば、他の専門家など)が

が入ってしまい、うっかりデータを消してしまうことがあります。

しかし、それは端末の質ではなく、プログラマーの質の問題です :)

 
 
knt-kmrd писал(а)>>
実際には、ファイルが復活する可能性なしに消滅するのは、たった1つのケースだけです。

もし「邪悪なハッカー」がハードディスクにハンマーを打ち込んだら

その1台が減圧され、保存されていたデータが完全に失われたこと。
しかし、この場合、Expert Advisorが死んでいるので、MT4はあなたを救うことはできません。

また、突然の停電などの場合もあります。
>> ディスク上の(つまりファイル内の)データが保存されます。

---

ただし、いたずらなプログラム(例えば、他の専門家など)が

がそのファイルに入り、不注意でデータを消してしまう。

しかし、これは端末の品質ではなく、プログラマーの品質の問題です :)

ファイルを強制終了する必要もなく、例えば障害発生時に一部の情報を上書きしない程度で十分です。

位置の維持はユーザーに委ねられており、さらなるエラーの原因になりかねない。このブロックを実装する際も、純粋にロジカルに。