取引環境に対応する際の典型的な間違いとその対処法 - ページ 6 12345678910 新しいコメント Artyom Trishkin 2018.02.24 15:37 #51 Комбинатор: ある人にはあるものが必要で、別の人には別のものが必要なので、万能ではないでしょう。 現実に立ち戻ることを求めます。また、成行注文という形で不確実性がある場合は、その結果を待ってすでに起こったことを出力するか、プログラムにその処理を任せるか、どちらかにします。しかし、確かに適当に量を返すのはダメですね。 fxsaber 2018.02.24 15:39 #52 Artyom Trishkin: 現実に立ち戻ることを求めます。また、成行注文という形で不確実性がある場合は、その結果を待って既に起こったことを返すか、プログラムに処理方法を決めさせるかのどちらかです。しかし、確かに偶発的に量を返すことはない。見返りではなく、ありのままの姿。完全に変更 可能なポジションが 2つ、凍結（変更不可）が1つあります。全部で3つのポジションがあります。これは、参考にしたMT4のロジックとよく合致していますね。 TheXpert 2018.02.24 15:46 #53 Artyom Trishkin:もし、三菱商事が通常の同期運転を行っていれば、そのような疑問は全くなかったはずだ。 さらに、fxsaber氏は、なぜそのようにするのか、なぜ私の論理に納得がいかないのかを説明してくれました。 fxsaber 2018.02.24 15:53 #54 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム 取引環境での作業における典型的なミスとその修正方法 fxsaber さん 2018.02.24 16:25 そのようなキャンセルされた成行注文がどのようなものであるかもお見せします。 ただ、エラーはありません。この例は、よりクールであることがわかった。ブローカー自身が置いたTPがコード化された!そして、再注文が終了した後、ほとんどすぐに（115ミリ秒待っていました -MT5のバグだったよう です）、ブローカーは別のTPを設定し、それが実行されたのです。注文へのコメントがスクリーンショットに表示されませんでした。緑色はORDER_REASON_TP です。従って、拒絶されたオーダーはORDER_POSITION_IDまで持っている。 fxsaber 2018.02.24 16:04 #55 Комбинатор:MCが普通に同期運転をして いれば、このような疑問は全く生じないはずだ。このようなOrderSendは、コーダー自身が書くことができる。synchronous OrderSendを使うときは、このような解決策をとっています。 MCが自分で書くとタイムアウトになる可能性があることは理解しておく必要がある。論理的には、第三者のシステムに送られた成行注文について、三菱商事は責任を負いません。 一生懸命やっても、2 + 1 != 3の どこが重要なのかがわからない。 ZZZ 非同期型のバリエーションもあるんですよ。そして、そこで成行注文に出くわすことも十分にあり得ます。つまり、このような位置 カウント機能は、たとえMCが「正常な同期動作」をしたとしても、関係することになる。 Artyom Trishkin 2018.02.24 16:09 #56 fxsaber:このOrderSendは、コーダー自身が書くことができる。私がOrderSendのsynchronous variantを使用するときは、このソリューションを使用します。 ただし、MCが自分でそのような解答を書くとタイムアウトになる可能性があることは理解しておく必要がある。論理的には、第三者のシステムに送られた成行注文について、三菱商事は責任を負いません。 一生懸命やっても、2 + 1 != 3の どこが重要なのかがわからない。 なーんだ、そうなんだ。あなたの場合2 + 1 - 1 = 3 fxsaber 2018.02.24 16:14 #57 Artyom Trishkin: いや、そういうわけでもない。あなたの場合2 + 1 - 1 = 3私たちは算術が違うことに気づきました。おそらく続けるべきではありません。しかし、バイモアに影響を与え、バグのあるコードの投稿をやめさせることは、その価値があると思います。 Artyom Trishkin 2018.02.24 16:24 #58 fxsaber:私たちは算術が違うことに気づきました。おそらく続けるべきではありません。しかし、QBにバグのあるコードを投稿するのをやめさせるには価値があるかもしれません。 そして、彼らに影響を与えるためには、私を理解し、この欠陥を修正するための可能な手段を議論する必要があるのです。しかし、あなたは自分の提案するアプローチに起こりうる欠点に頑なに気づかないのです。どうしたらいいのでしょうか？自分のやり方を大事にするのではなく、聞くように説得する？だから、あなたは聞いていないのです。 TheXpert 2018.02.24 16:26 #59 fxsaber:一生懸命やってみたが、2＋1 !=3という のがどこで重要なのか、まだわからない。ストラテジーがオープンポジションに 即座に反応することを意味する場合。この場合、正規表現はロジックを壊すことができる。 大半の場合、どのような会計処理（ポジションとしてのオーダーと、中間的な働かない状態としてのオーダーの両方）でも、問題は解消される。 fxsaber: このようなOrderSendは、コーダー自身が書くことができる。変な理屈で、ターミナルもそのように書けるのですが、mt4になってから、コーダーの頭の中に問題が移ったような気がします。 fxsaber 2018.02.24 16:30 #60 Комбинатор:ストラテジーがオープンポジションに 即座に反応することを意味している場合。この場合、リダイレクトはロジックを壊すことができる。 それは曲がった論理だと思うんです。でも、もちろん間違っているかもしれません。その論理を聞いてみたいものです。 変な理屈で、ターミナルもそのように書けるのですが、mt4以降はコーダーの頭の中に問題を転嫁しているように見えます。やはり、不勉強というか、Documentationが弱いということでしょうか。そこですべてがきちんと説明されていれば、間違いやそのような会話も少なくなると思うのです。でも、そのためにこのフォーラムがあるのでしょう。なぜなら、文書ですべてを考慮することは不可能であることは明らかだからです。 ZZY 私が作った既成のソリューションのソースコードがパブリックドメインで公開されていました。 12345678910 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ある人にはあるものが必要で、別の人には別のものが必要なので、万能ではないでしょう。
現実に立ち戻ることを求めます。また、成行注文という形で不確実性がある場合は、その結果を待って既に起こったことを返すか、プログラムに処理方法を決めさせるかのどちらかです。しかし、確かに偶発的に量を返すことはない。
見返りではなく、ありのままの姿。完全に変更 可能なポジションが 2つ、凍結（変更不可）が1つあります。全部で3つのポジションがあります。これは、参考にしたMT4のロジックとよく合致していますね。
もし、三菱商事が通常の同期運転を行っていれば、そのような疑問は全くなかったはずだ。
さらに、fxsaber氏は、なぜそのようにするのか、なぜ私の論理に納得がいかないのかを説明してくれました。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
取引環境での作業における典型的なミスとその修正方法
fxsaber さん 2018.02.24 16:25
そのようなキャンセルされた成行注文がどのようなものであるかもお見せします。
ただ、エラーはありません。
この例は、よりクールであることがわかった。ブローカー自身が置いたTPがコード化された!そして、再注文が終了した後、ほとんどすぐに（115ミリ秒待っていました -MT5のバグだったよう です）、ブローカーは別のTPを設定し、それが実行されたのです。注文へのコメントがスクリーンショットに表示されませんでした。緑色はORDER_REASON_TP です。従って、拒絶されたオーダーはORDER_POSITION_IDまで持っている。
MCが普通に同期運転をして いれば、このような疑問は全く生じないはずだ。
このようなOrderSendは、コーダー自身が書くことができる。synchronous OrderSendを使うときは、このような解決策をとっています。
MCが自分で書くとタイムアウトになる可能性があることは理解しておく必要がある。論理的には、第三者のシステムに送られた成行注文について、三菱商事は責任を負いません。
一生懸命やっても、2 + 1 != 3の どこが重要なのかがわからない。
ZZZ 非同期型のバリエーションもあるんですよ。そして、そこで成行注文に出くわすことも十分にあり得ます。つまり、このような位置 カウント機能は、たとえMCが「正常な同期動作」をしたとしても、関係することになる。
このOrderSendは、コーダー自身が書くことができる。私がOrderSendのsynchronous variantを使用するときは、このソリューションを使用します。
ただし、MCが自分でそのような解答を書くとタイムアウトになる可能性があることは理解しておく必要がある。論理的には、第三者のシステムに送られた成行注文について、三菱商事は責任を負いません。
一生懸命やっても、2 + 1 != 3の どこが重要なのかがわからない。
いや、そういうわけでもない。あなたの場合2 + 1 - 1 = 3
私たちは算術が違うことに気づきました。おそらく続けるべきではありません。しかし、バイモアに影響を与え、バグのあるコードの投稿をやめさせることは、その価値があると思います。
私たちは算術が違うことに気づきました。おそらく続けるべきではありません。しかし、QBにバグのあるコードを投稿するのをやめさせるには価値があるかもしれません。
一生懸命やってみたが、2＋1 !=3という のがどこで重要なのか、まだわからない。
ストラテジーがオープンポジションに 即座に反応することを意味する場合。この場合、正規表現はロジックを壊すことができる。
大半の場合、どのような会計処理（ポジションとしてのオーダーと、中間的な働かない状態としてのオーダーの両方）でも、問題は解消される。
このようなOrderSendは、コーダー自身が書くことができる。
変な理屈で、ターミナルもそのように書けるのですが、mt4になってから、コーダーの頭の中に問題が移ったような気がします。
ストラテジーがオープンポジションに 即座に反応することを意味している場合。この場合、リダイレクトはロジックを壊すことができる。
それは曲がった論理だと思うんです。でも、もちろん間違っているかもしれません。その論理を聞いてみたいものです。
変な理屈で、ターミナルもそのように書けるのですが、mt4以降はコーダーの頭の中に問題を転嫁しているように見えます。
やはり、不勉強というか、Documentationが弱いということでしょうか。そこですべてがきちんと説明されていれば、間違いやそのような会話も少なくなると思うのです。でも、そのためにこのフォーラムがあるのでしょう。なぜなら、文書ですべてを考慮することは不可能であることは明らかだからです。
ZZY 私が作った既成のソリューションのソースコードがパブリックドメインで公開されていました。