"ダミー "からの質問 - ページ 176

[Yedelkin]

Karlson:

3Б.ハーフセルを開けることで一部クローズ-OUT。

残念です :/ OUTプロパティで履歴にいくつかの取引が存在することが判明しましたが、ポジションはまだ存在します。

[Anatoli Kazharski]

Yedelkin:
悪いこと :/。

なぜ悪い？私が正しく理解していれば、それは単純なことです。OUTでポジションがある場合は、音量が小さくなっていました。OUTでポジションがない場合は、ポジションが完全に閉じたことを意味します。

[Yedelkin]

tol64:
なぜ悪いのか？私が正しく理解していれば、すべてがシンプルです。ポジションとOUTがある場合は、数量が減少していました。OUTでポジションがない場合は、ポジションが完全にクローズされたことを意味します。

悪いのは、これだ。お客様のアプローチ「OUTでポジションがある場合、ボリュームが減って いる。OUTがなく、ポジションもない場合、ポジションは完全にクローズ されました」というのは、端末のデータベースにあるポジションの情報を毎回追加で確認する必要があり、面倒に感じる特徴があります。

基幹端末の情報は、実際の状況に対して一定のラグを持って取得されることは周知の通りです。そのため、チェック結果が「ポジションがありOUT」であっても、実際にはポジションが完全にクローズされている場合を排除できない。つまり、不正確な情報を入手し、それをもとに間違った行動をとる可能性がある。 あるいは、追加チェックや遅延など、都合の良い方法を考えなければならない。

しかし、これらの仕掛けはすべてなくても大丈夫です。特に、ポジションの空き状況を確認することなくそのためには、ポジションの決済とDEAL_ENTRY_OUT の プロパティを一対一に対応させ（対応 - 現在 Handbook で示されている）、ポジション量の削減を取引の別のプロパティに割り当て れば十分である。そして、履歴（HistorySelectByPosition）の中から、DEAL_ENTRY_OUTの プロパティを持つ1つの取引を見つけるだけで、ポジションが減少することなく、正確にクローズし、いかなる状況でも逆転さ せることができないことが保証されます。

[Anatoli Kazharski]

Yedelkin:

悪いのは、これだ。お客様のアプローチ「OUTでポジションがある場合、ボリュームが減って いる。OUTがなく、ポジションもない場合、ポジションは完全にクローズ されました」というのは、端末のデータベースにあるポジションの情報を毎回追加で確認する必要があり、面倒に感じる特徴があります。

基幹端末の情報は、実際の状況に対して一定のラグを持って取得されることは周知の通りです。そのため、チェック結果が「ポジションがありOUT」であっても、実際にはポジションが完全にクローズされている場合を排除できない。つまり、不正確な情報を受け取って、それをもとに間違った行動をとることもありうる。 あるいは、追加チェックや遅延など、都合のよい方法を考えなければならない。

しかし、これらの仕掛けはすべてなくても大丈夫です。特に、ポジションの空き状況を確認することなくそのためには、ポジションの決済とDEAL_ENTRY_OUT の プロパティを一対一に対応させ（対応 - 現在 Handbook で示されている）、ポジション量の削減を取引の別のプロパティに割り当て れば十分である。そして、履歴（HistorySelectByPosition）からDEAL_ENTRY_OUTの プロパティを持つ1つの取引を見つけるだけで、ポジションが減少したのではなく、正確にクローズ され、いかなる状況でも元に戻すことができないことを確実に知ることができるのです。

OnTrade()では、サーバーからのレスポンスを受信します。つまり、OnTrade()でイベントを確認すれば、ポジションがあるかないかは、すでに確実にわかるのです。DEAL_ENTRY_FULLOUT（完全終了）やDEAL_ENTRY_PARTOUT（部分終了）などの標準的なオプションで、すべてを完璧にエレガントに することは可能ですが。)))

とりあえず別機能を作れば、いちいち「面倒なチェック」を導入する必要がなくなります。

[Yedelkin]

tol64:

DEAL_ENTRY_FULLOUTやDEAL_ENTRY_PARTOUTの ような標準的なオプションを作れば、すべてを完璧にエレガントに することができるのですが。)))

そういうことなんです。OnTradeで追加のチェックをする必要もなく、提案されたソリューション（FULLOUT / PARTOUT）と比べて面倒に見えるでしょう。

[Anatoli Kazharski]

Yedelkin:
そこがポイントなんですが...。OnTradeで余分なチェックをする必要もなく、提案されているソリューション（FULLOUT / PARTOUT）と比べるとまだ面倒に見えるかもしれません。

サービスデスクに提案してみる。もしかしたら、検討されて、いつか実施されるかもしれません。

[Yedelkin]

tol64:
サービスデスクに提案してみる。もしかしたら、検討されて、いつか実施されるかもしれません。

もうやったよ :)言語エラーとして......うわ、作文に1時間かかっちゃったよ。

[Anatoli Kazharski]

Yedelkin:
もうやったよ :)滑舌として・・・うわ、作文に1時間かかっちゃった。

それでも間違いとは言い切れない。しかし、すでに送られてしまった今、何ができるのでしょう。))

[Yedelkin]

tol64:
それでも間違いとは言い切れない。しかし、送られてきた今、何ができるのでしょう。))

まあ、ここで少し評価項目が登場するわけですが :)Errorsのカテゴリーを正当化しようとした :)

[Валерий]

Yedelkin:

はい、各期間は一定の値に対応しています。数年前に誰かがフォーラムに投稿したものです。下のようなラインを走らせれば、自分で調べることができます。

このスクリプトは、すべてのピリオドのENUM_TIMEFRAMESの値を10進数で表示 します。

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+