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

 
-台所の床で寝ないでくださいと、もう2回言ったと思うんですが、昼間はなおさらですか?
-キッチンの空気がきれいになった。

---------------

-「おじさん、気持ち悪いよ」突然、泣き言のような声で男が言った。

---------------

M・ブルガーコフ犬の心。


さて、厨房の住人たち。信号が高調波に分けられることは、もちろんご存じでしょう。そして、逆変換が可能であることもご存じでしょう。

さて、ここからが本題です。最後のケースは、1つのシンボルの多くのExpert Advisorを1つに変換することです。さらに言えば、この変換はDC for 4のサーバーで行われる。

さて、考えてみましょう。4時間足のExpert Advisorと5分足のExpert Advisorを、アシストなしで結果的に1つに統合することはできないのでしょうか?)同時に、それがどのように「聞こえる」のかも明らかになるでしょう。嫌がる人が多いのでは)))。


タクトとプロセッサーについては......ここではやめておこう......枝葉があるんだ。ここでは、レジスターのロードマップを示すだけでは不十分です。と、そんなことはどうでもいいのです。

 
-人間にされたことが不満なのか?と目を細めて聞いてきた。- またゴミ捨て場を走り回る方がいいのか?路地で凍えている方がましだと? もし知っていたら...

-どうしてみんな私を責めるの? -ゴミ箱よ、ゴミ箱。自分でパンを買ってきていました。

----

同じ場所です )))))))))))))))))))))))))))))))))))))))))))))


それだけです。もういいや。


 
timbo >> :

大きな字でプリントアウトして壁に掛け、2万円の預金に足りない分だけ何度も読んでください。これが、すべての「なぜ」の答えです。メタクオーツは成熟して、本物のお金を求めているのであって、無限の厨房ナノデモ口座で永久にうずくまっているわけではないのです。私たちも成長し、本物の市場、本物のお金に触れる機会を得ることができるのです。


エヘン、エヘン...ええ、もちろん、「取引所での」ように見えるように持っていくことは(ちなみに主要な取引所は、新参者が踏み台にし始めるまでは、イノベーションの面で長い間非常に骨が折れ、不器用だった)、確かに成熟の証です、どうでしょう......」。

そして、取引条件の「カスタマイズ」が誰にでもできるようになったのは、「厨二病」からの脱却の表れだと思いました。

1.トレーダーの悩み
2.プログラマーの問題。
正しいアプローチであれば、それらを解決することができるのです。1 - 簡単、2 - 汗をかく必要がある(数日後にやる予定)。

比喩的な言い方をすれば、かつての営業マンは、レジの利点があるにもかかわらず、請求書を手放したがらなかった(今もそうだが)。そして今、彼らは私のレジを取り上げ、請求書を渡し、それは私の問題であり、私はただ「汗をかく」しかないと言ったのです。


そして、かつて私が学び始めたのは、「大人」の条件である交流でした。そして、立法による規制を除けば、何のメリットもないと思っています。他の点では-特にお見合いは-惨憺たるものである(最近動き始めた)-ここでも銀行と同じで、顧客の利便性を考えないものがある。

 
getch >> :

注文のTPとSLレベルは、ほとんどすべてのプラットフォームにあるOCO-orderの存在があれば可能だったはずです。しかし、MT5ではそれらも放棄されてしまった...。

おそらく開発者は、すでにいくつかのプラットフォームで実装されているように、トレードサーバーでの仮想ポジション(およびOCO注文)を拒否した理由を説明することでしょう。そして、この問題の解決策をどのように考えているのかを教えてくれるでしょう。

OCO-注文にTPとSLレベルを実装する必要があることを勘違いしていました。注文のTPとSLレベルの実施状況を表にしています。

限度額・レベル
バイリミット
売り指値
購入停止
売り止まり
テイクプロフィット
売りの逆指値
買いストップリミット
売り指値
売り指値
ストップロス
売り止まり
購入停止
不要
不要

逆指値買い」と「逆指値売り」という2つの注文方法しか導入しなかった開発者の意図がわかります。本当によく考えられている。OCOの注文には必要性がない。

しかし、総ポジション構造のMT5会計上での信頼性のある実装の問題は残っています。

 
getch >> :

OCO-注文にTPとSLレベルを実装する必要性について、私は間違っていました。注文のTPとSLレベルの実施表はこちらです。

ポーズ/レベル
バイリミット
売り指値
購入停止
売り止まり
テイクプロフィット
売りの逆指値
買いストップリミット
売り指値
売り指値
ストップロス
売り止まり
購入停止
不要
不要

買い逆指値と売り逆指値の2種類の注文しか導入しなかったところに、開発者の意図が読み取れます。本当によく考えられている。OCOの注文には必要性がない。

しかし、総ポジション構造のMT5会計のRELIABLEな実装には疑問が残ります。


getchとIntegerの 場合

このスレッドのトピック "MT5で集合ポジション構造のREAL会計を実装することは可能か?" の観点で恐縮です。

TPとSLを保留中の注文に置き換えることは解決策ではありません。

例を挙げて説明します。

1.ご注文を承りました。

2.SLとTPの代わりに保留の注文を出すことは、サーバーとの1回の取引で2つの注文を出すことはできないので、RELIABLEな 操作となります。

とのトランザクションが発生します。ましてや、本命と一緒に2つ保留の3つの注文を出すなんて、もっと無理な話です。

つまり、発注までの間に予期せぬ事態が発生する可能性があります。

注文を間に合わせることができない、または片方の注文を損失させることができない。

またはその両方、例えば通信障害によるもの。

さて、非常に大きなターゲット(>100 pips)があると仮定して、Expert Advisorに多くのチェックを挿入することで対処し、次のように置きます。

それで、このクソみたいな保留命令を設定したんだ。

3.価格が何らかの方向に動き、SLなどの保留注文が発動した場合。

4.注文が締め切られた?そうではありません。TPを担当する不運なペンディングオーダーがまだ残っています。

さて、誰が時間内に削除すべきでしょうか?プーシキン、-いや、それは間違いだ。私たちEAによって削除されるはずです。

これはSUPER HATEの 操作だけでなく、プログラマーの恐ろしさでもある。

(トレーダーはもちろんのこと、彼らは何も気にせず、あらゆる場面で1つのオーダーしか持っていません)。

なぜなら、この時点で通信が途絶えると、Expert Advisorとアカウントの制御が完全に失われるからです。

 
kegor >> :

そして、そのやりとりの中で、「大人」の条件を知るようになったのです。そして、法規制以外のメリットは見当たりません。それ以外では-特にお見合いの場合-惨めなものです(最近動き始めました)-ここでは銀行のようなもので、顧客の利便性を考えないもう一つのものです。

"ここの銀行も、顧客の都合でくしゃみをしているに過ぎない。小さくてもいいから、誇りを持って、自分の進出を賞賛し、100のマイクロロットの顧客を持つ200のキッチンDCにサービスを提供するという選択肢もあるのです。あるいは、他の人の憲章を学んで、1万円からの預金で何百万人もの顧客を持つ20の大手ブローカーに自分のサービスを提供することです。進化を遂げながら、徐々にシェアを拡大。前者は行き詰まり、後者は無限の成長を約束する。

それらのほとんどはあってもminilots、デモですべての詳細を取引しないため、遠吠えロケーターとそれらに参加した人々は、methaquotesに少し興味があります。この残酷な世界では、お金がすべてを決めてしまうのです。大金はネットのプラットフォームで生きている。そう、多くの場合、ただ嫌な品質のプラットフォームで、私自身は毎日唾を吐いていますが、お金はそこにあります。そして、ここではほとんどニョロニョロだけ...。

 
MT5は、1つの商品に複数のポジションを置くようには設計されていません。

MT5は複数のEAを扱えるようには設計されていない

MT5は、単一商品のポジションをヘッジするようには設計されていません。

MT5はExpert Advisorとマニュアル取引を 一緒に行うようには設計されていません。

MT5はMT4コードに対応していません。

MT5はMT4のプログラムロジックをサポートしていません。

...

じゃあ、何が楽しいんだ。もう一つの新しいプログラムでは

むしろWindows 7が欲しいくらいです。同じスローガンを掲げても、少なくとも素敵なんです。

PS.英語のフォーラムを読むといい。半数はMT5をインストールすることもできない。

単なるトレーディングロボットの詰め合わせではなく、トレーディングロボットの品質に関心を持っているのだと思います。

 
timbo >> :

"他人の家にお邪魔するのは... "っていうのが、わかるんですよね。小さくても誇りを持ち、自分の進出を賞賛し、それぞれ100のマイクロロットの顧客を持つ200のキッチンDCにサービスを提供するという選択肢もある。あるいは、他の人の憲章を学んで、1万ドルからの預金で何百万人もの顧客を持つ20の大手ブローカーに自分のサービスを提供することです。進化を遂げながら、徐々にシェアを拡大。前者は行き詰まり、後者は無限の成長を約束する。

それらのほとんどはあってもminilots、デモですべての詳細を取引しないため、遠吠えロケーターとそれらに参加した人々は、methaquotesに少し興味があります。この残酷な世界では、お金がすべてを決めてしまうのです。大金はネットのプラットフォームで生きている。そう、多くの場合、ただ嫌な品質のプラットフォームで、私自身は毎日唾を吐いていますが、お金はそこにあります。そして、ここではほとんどニョロニョロだけ...。



だから、ポストソビエトの空間でのテストは必要なかった。

それ以外は、端末は英語、ヘルプはロシア語というのが面白いですね。

メーカーが報告する相手が誰であっても、それが明確であることを望みます。

サポートサービスも、ベータテスターもない。

(掲示板に時々登場する、あの残念な3人のことではありません。

と記事を書いたり、ソフトを盗んだりする)

どんな世界征服なんだ?

 
thecore >> :


このスレッドのトピック "MT5でポジション構造の集計をRELIABLEに実装することは可能か?"という観点で恐縮なのですが。

TPとSLをペンディングオーダーに置き換えることは、解決策ではありません。

どちらを見るかは人それぞれです。必ずプラスとマイナスがあります。

100%信頼できる方法、きっと見つからない。

No.2 同意

4 -- いいえ。ポイントは、Expert Advisorが状態を復元する可能性があるということです。しかし、この間に両方の保留注文が発動する可能性があり、それはもう最悪だとしよう。

でも、TPを露出させなければ解決可能なんです。この場合、2でも誤差が少なくなっています。

SUPER FUCKINGな 操作性だけでなく、まさにプログラマーの悪夢と言えるでしょう。

いや、いいんです。さらに、OnTradeという素敵なものがあります。

 
thecore >> :


getchとIntegerの 場合

このスレッドのトピックである「MT5でポジションの集計構造の信頼できる会計を実装することは可能か」という観点で恐縮です。

TPとSLを保留中の注文に置き換えることは解決策ではありません。

例を挙げて説明します。

1.ご注文を承りました。

2.SLとTPの代わりに保留の注文を出すことは、サーバーとの1回の取引で2つの注文を出すことはできないので、RELIABLEな 操作となります。

とのトランザクションが発生します。さらに言えば、本命の注文と合わせて2つの保留の3つの注文を出すことは不可能である。

つまり、発注までの間に予期せぬ事態が発生する可能性があります。

注文を間に合わせることができない、または片方の注文を損失させることができない。

またはその両方が、通信障害などの理由で発生した場合。

OK、非常に大きなターゲット(>100 pips)があると仮定して、Expert Advisorに多くのチェックを挿入することで何とか修正し、次のように置きます。

それで、このクソみたいな保留命令を設定したんだ。

3.価格が何らかの方向に動き、SLなどの保留注文が発動した場合。

4.注文が締め切られた?そうではありません。TPを担当する不運なペンディングオーダーがまだ残っています。

さて、誰が時間内に削除すべきでしょうか?プーシキン、-いや、それは間違いだ。私たちEAによって削除されるはずです。

これはSUPER HATEの 操作だけでなく、プログラマーの恐ろしさでもある。

(トレーダーはもちろんのこと、彼らは何も気にせず、あらゆる場面で1つのオーダーしか持っていません)。

なぜなら、この時点で通信が途絶えると、Expert Advisorとアカウントの制御が完全に失われるからです。


2.マーケットに同時に複数の注文を出すことはできません。これは、「市場ではない」プラットフォームでしかできないことだった。すべての注文は、Executionサーバーを通じてキューイングされます。例えばデューカスコピーでは、TPとSLを指定し、保留または成行注文を出すと、同時に3/2の条件を出したように見えますが、実際には次々と条件が変わっていきます。それが技術であり、論理である。また、成行指値注文は、約定が保証されている注文であるため、約定に支障をきたすことはないため、証拠金が必要とされます。TPレベルも同様です。しかしデューカスコピーでは、TPはスタックに含まれず、マーケット・エントリーとして実行されます。

4.MT5で別のTP/SLレベルのトリガー後にSL/TPレベルを削除する問題は、トレーダーの肩にあります。デューカスコピーでは、これはExecutionサーバーの肩代わりをすることになります。SLトリガー時にTPを確実に削除するためには、TPがピック・ウィンドウ内になければならない(MUST)、さもなければSLトリガー後に実行される可能性がある(Not)。

ニュアンスの違いもありますし、SLやTPレベルはマーケット実装で確実に実装できるのであれば、MT5開発者の選択肢はDukascopyの道を歩むことになります。あるいは、(上記のように)テーブルを通して独自にTPを実装することができ、開発者はSLとTPレベルなしで仮想ポジションを追加するだけでよい。