OnTradeTransaction処理 - ページ 6

新しいコメント
 

こんにちは。

誰にも臆することはない。

prostotrader:

switch(trans.type)がないじゃないか。

まあ、もちろん、与えられたケースはswitch(trans.type)の中にあるのですが。別のケースもあったので、不要な情報で負荷をかけないように、すべてのコードを表示しないようにしました。

fxsaber さん、例の件、ありがとうございました

アレクセイ、まったく同じです。2種類のロボットを使って、同じシンボルでネッティングモードで取引しています。引用された2つの記事は互いに補完し合っています。

主要な変更トリガーであるonTradeTransactionから 問題を解決するのは興味深いことです。

現在遭遇している問題の合計。

1.deal_addのトリガーはあるが、ポーズはない。今のところ感想なし。

2. deal_add がトリガーされたが、オーダーが3次元にある。スリップを貼る、ここ2、3日は効果があるようです。オーダーは1秒で履歴を残すことに成功する。私は高頻度取引ロボットを持たず、成行注文も使わないので、このソリューションが適切だと思います。

3. deal_addが2回発生する、つまり、1つの同じdeal_addが2回発生する。これは、過去のトランザクションのチケットを確認し、今回のチケットと比較することで解決することができます。

まだ、ポイント1があります。

昨日、sell_limitを設定したところ、うまくいき、deal_addが来たのですが、ポジションが表示されず、無駄に逆指値注文を開けてしまったのです。取引の説明を見始めたら、取引の種類はDEAL_TYPE_SELLなのに、注文の種類はORDER_TYPE_BUYになっているんです。同時に、オーダーチケットは私たちのものです。なかなか論理的でないように思えた。OnTradeTransactionで、注文タイプと取引タイプが同じになるはずだ、と確認することにしたのです。

ロボットをデモに置いて、また同じような取引をしましたが、今度はポジションが変わりました。しかし、私たちのチェックにより、ストップオーダーは実行されませんでした。どうしたんですか？

2019.02.08 16:05:14 [INFO]: ( FrTrend_2_Si-3.19_33) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: Si-3.19
Deal ticket: 12677775
Deal type: DEAL_TYPE_SELL
Order ticket: 82675535
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 66287
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82675534
Position by: 0

さっそくですが、これが端末に入ってきたものです。私が作ったものではありません。

 
Илья Ребенок:

昨日、sell_limitを置いたところ、トリガーがかかり、deal_addが来たのですが、ポジションが現れず、無駄にストップオーダーを開けてしまいました。取引の説明を見始めたところ、取引タイプがDEAL_TYPE_SELLで、注文タイプがORDER_TYPE_BUYであることがわかりました。同時に、オーダーチケットは私たちのものです。なかなか論理的でないように思えた。deal_add 取引の OnTradeTransaction で、注文タイプと取引タイプが一致することを確認することにしました。

しかし、ここで「取引構造」のヘルプを再読する価値があります - deal_addタイプにどのフィールドが記入されるかという点でです。

また、注文のプロパティをトランザクションからではなく、注文自体から取得する（ここで、それらは記入されないが、ゼロはenum-typeのいくつかの値にも対応する）、もしそれが現時点（そして注文から履歴への移行過程でない）で利用可能であるなら。

 

その ため、状況を分析しやすくなっています。


ポジションの状態、現在の注文、取引履歴を取引と一緒に記録することができることを追加することができます。そうすれば、全体像が見えてくるはずです。

 
JRandomTrader:

ここで、「貿易取引の構造」のヘルプを再読しておくと、deal_addタイプでどのようなフィールドが埋められるかがわかります。

また、オーダープロパティをトランザクションからではなく（ここで、それらは記入されないが、ゼロはenum-typeのいくつかの値にも対応する）、オーダー自体から、それが現在利用可能であれば（そしてオーダーから履歴への移行過程でない）、取得すること。

そうですね、意識はしていたのですが、気にしていませんでした。思い出させてくれてありがとう。

しかし、あるケースでは出てこないポジションが、別のケースでは出てくるという問題は残っており、不明確です。

 

Илья Ребенок:

しかし、一方のケースで表示されず、他方のケースで表示される位置の問題は残っており、不明確である。

deal_add トランザクションでポジションが発券されましたが、以前はポジションが存在せず、表示されなかったのでしょうか？これを整理しなければならない。

 
JRandomTrader:

deal_add トランザクションでポジションが発券されましたが、以前はポジションがなかったのに、表示されないのでしょうか？これを整理する必要がある。

以前はなかった位置

 
Илья Ребенок:

以前はなかった位置

取引にポジションチケットはあったのでしょうか？

 
JRandomTrader:

取引にポジションチケットはあったのでしょうか？

上の投稿で、私は少し誤解をしていたようです。ポジションがあり、その後ストップオーダーで クローズされた。つまり、ポジション数が0になり、その後、取引がトリガーされましたが、ポジションは表示されませんでした。

ということなのでしょう。トランザクションにはポジションのチケットの情報が含まれていましたが、このチケット＝前回のオーダーのチケットでした。私の理解が正しければ、網タイツモードであるべきです。

Position: 82675534
 
Илья Ребенок:

上の投稿で、私は少し誤解をしていたようです。ポジションがあり、その後ストップオーダーで クローズされた。つまり、ポジション数が0になり、その後、取引がトリガーされましたが、ポジションは表示されませんでした。

ということなのでしょう。トランザクションにはポジションのチケットの情報が含まれていましたが、このチケット＝前回のオーダーのチケットでした。私の理解が正しければ、一般的にはネットモードであるべきです。

シンボルのポジション（累積、すべてのロボットと手動取引の合計）が0.0になった場合、次の取引では、新しいチケット（=注文のチケット）で、新しいポジションを開く（DEAL_ENTRY_IN）ことになります。

実際、ネッティングを行う場合、ポジションを見る必要は全くなく、各ロボットは「その」、つまり自分の注文に対する取引の結果を考慮しなければならないように思います。

 

ポジションとDEAL_ENTRYフラグの有無は、いかなる形でもロジックに関与してはならない。

自国/外国を識別するものとして、新規取引と現在の注文のマジックとコメントを見ればいいのです。


動作するコードが表示されました。まったく同じです。

OnTradeTransactionで 解決しようとするのは、落とし穴の数が少ないということです。特定のタスクでは、時にはまだ迂回することができます。しかし、タスクを少し変更すると、OnTradeTransaction-implementationの際にロジック全体が壊れてしまうのです。

開発者はイベントドリブン型の取引モデルを作成しましたが、動作する例を一つも提供していません。コードが何に注ぎ込まれるのか、各例に依存するのか、完全にアホだからです。

そこで、同期取引操作とOnTrade機能に注目することをお勧めします。そのほうが、すべてが簡単ですし、ロジックの変更にも柔軟に対応できます。しかも、より信頼性が高い。


Async+Transactionsへの移行は、高級言語からアセンブラへの移行に匹敵するものである。つまり、TSを作成する最後の段階で、完全に研究され、本番に備え、最後に取引ロジックを変更することなく取引操作をスピードアップするために行われるべきものです。

12345678910
新しいコメント