MetaEditor build 1490 - ページ 6

 
いつの頃からか、ポジションを反転させると、そのポジションIDが変化するようになりました。これはヘルプに表示されています(そこにも記述されています)。それゆえ、矛盾が生じるのです。
 
Andrey Barinov:
以前から、ポジションを反転させると、そのポジションIDが変更されます。これはヘルプに表示されています。それゆえ、矛盾が生じるのです。

問題はそこではない。

サービスデスクは、今日のビルドで修正版を提供する予定だと言っています。

 
Andrey Dik:

サービスデスクより、本日のビルドで修正版を提供する予定であるとの回答がありました。

1491 - 修正なし。
 
fxsaber:
1491 - は修正されていません。

残念ながら、そうではありません。

ところで、現在のポジション会計制度では、前のポジションを閉じた部分と新しいポジションの残りの部分をどのように分けるのかが全く不明です(この区分は現時点では存在しません)。一見すると、問題は深いようです。

 
Andrey Dik:

残念ながら、そうではありません。

ところで、現在のポジション会計制度では、前のポジションを閉じた部分と新しいポジションの残りの部分をどのように分けるのかが全く不明です(この区分は現在では存在しません)。一見すると、問題は深いようです。

そういうこと

トレーディング、自動売買システム、ストラテジーテストに関するフォーラム

MetaEditor build 1490

fxsaber さん 2016.12.05 11:32

はい、DEAL_ENTRY_INOUTが ポジションの取引回数に含まれていても、ENUM_DEAL_PROPERTY_*を拡張しない限り、役に立ちません。
 
fxsaber:
ほぼ同じ

私は逆に、列挙を拡大するのではなく、短縮するべきだと考えています。つまり、DEAL_ENTRY_INOUTは 何もしない不要な存在なのです。

現在、どのように見えるかの例を示します。

IN; +1.0; ID 0

IN; +0.2; ID 0

IN/OUT; -2.0; ID 1 // 新しいIDのポジションが作成されましたが、その中に取引はありません; すべての取引は前のポジションを参照しています; 従って手数料とスワップは0.0です

IN; +0.2; ID 1 // 最初のトレードがリストに表示され、それが唯一のものである。

従って、ポジションID1(青と緑の対応する取引リスト)のこの部分の数量については、スワップと手数料は考慮されません。


今、私がどう見ているか、論理的・歴史的にどうあるべきか(MQがどういう判断を下すかは誰にもわからない)。

IN; +1.0; ID 0

IN; +0.2; ID 0

OUT; -1.2; ID 0 // 取引量のうち、決済されるポジションに回った部分

IN; -0.8; ID 1 // 新しいIDで新しいポジションが出現し、そのトレードは残りとして存在し、そのトレードはリストの中にあり、最初のものである。

IN; +0.2; ID 1 // リストの2番目の取引

したがって、取引IN/Outの種類は全く必要ありません。このようにして、すべてが正しく考慮され、案件のリストが完成すれば、該当する案件の手数料やスワップの値を適切に求めることができる。また、どの取引(一方は決済、他方は新規ポジション)が1つの注文に含まれるかを判断する必要がある場合、非常に簡単に判断することができます - OUTとINの取引が同時に行われます(太字でマーク)。

 
Andrey Dik:

私は逆に、列挙を拡大するのではなく、短縮するべきだと考えています。つまり、DEAL_ENTRY_INOUTは 何もしない余計な存在なのです。

トランザクションは、プラットフォームに依存しない実行主体である。そしてENTRYフラッグはMQの戯言です。

市場で1つの取引があったとして、それを2つと表現することは、便利ではあってもできない。

MQは、わざわざ仮想化-Hedgeモードを追加しています。取引所のために簡単な仮想化までやってしまうのは、悪い判断だ。

しかし、トランザクションのプロパティを拡張することで、潜在的な支障をきたすことなく利便性を高めることができます。

 
fxsaber:

トランザクションは、プラットフォームに依存しない実行エンティティである。そしてENTRYフラグはMQのコントラクトです。

市場で1つの取引があったとして、それを2つと表現することは、便利ではあってもできない。

MQは、わざわざ仮想化-Hedgeモードを追加しています。取引所のために簡単な仮想化までやってしまうのは、悪い判断だ。

しかし、トランザクションのプロパティを拡張することで、潜在的な支障をきたすことなく利便性を得ることができます。

そうですね......私は自分の意見を言っただけです。

そして、どんな拡張機能がその場を救ってくれるのか。それでも、トランザクションのどの部分が古いポジションに関係し、どの部分が新しいポジションに関係するかを、何らかの方法で判断する必要があります。

 
Andrey Dik:

そして、どのような展開がこの状況を救うのでしょうか。どの部分が旧職のための取引で、どの部分が新職のための取引なのか、まだ判断がつかないところがある。

開発者の判断次第です。私はあなたの提案が一番好きです。しかし、それには仮想化が必要であることは理解しており、それは受け入れられません。
 

1491 - Alpari-MT5-デモ。スクリーンショットは同じ場所を示しています

ターミナル

リアルティクテスター

ローソク足が互いに対応していない - テスターでは、それらがあいまいである。また、テスターと端末の履歴時間は1時間ずつ異なる。

ターミナルでのCopyTicksは、テスターと同じデータを返します - 1時間の差です。そのため、ティックがバーと完全に一致することはありません。

では、完全な自己否定が ある場合、テスターであるMT5をどのように信用すればよいのでしょうか。なぜ開発者は、テスターで動かすベンチマークEAを用意し、明確に動作することを確認しないのでしょうか?まったくもって、困ったものです。

理由: