MT4で取引を開始し、すぐにまた閉じる場合の問題点 - ページ 4 123456 新しいコメント 削除済み 2010.09.11 00:00 #31 一貫したパターンを見つけることが困難なため、厄介な問題です。 この問題は時々起こるだけで、一貫して再現することはできません。 マジックナンバーの提案も検討しましたが、当初はその可能性がありましたが、さらなる観察により、その可能性は低いと思われます。 この問題を見たことがある人がいることを祈っています。 bernd 2010.09.11 00:05 #32 peterc005: マジックナンバーの提案を検討したところ、当初は可能性があったのですが、さらなる観察により、可能性は低いと思われます。 別のEAがそのEAに属さない取引を終了させることを確実に除外するような、詳細な観察結果はどれですか？多くのEAがマジックナンバーの入力を許可していますが、内部的にはそれを使っていませんし、さらに悪いことに、時々使っていますが、常にではなく、特定の終了条件でのみ、何十ものネストしたifと重複した注文の反復ループのいくつかのブランチでのみ使っています。 このグーグル検索 "OrderSymbol() == Symbol()" -OrderMagicNumber で検索するとたくさん出てきます。すでにリストの3番目のものから始まっています（earlybird1、gridmaster_03など、検索結果全体がそうです）彼らはマジックナンバーを使うと言っていますが、内部では単に無視しています。たくさん見つかるはずです。この欠陥コードパターンはフォーラムに溢れ、多くのEAにコピーペーストされることになります。 blogzr3 2010.09.11 00:11 #33 7bit: 販売された製品の欠陥に関するものであり、犯罪の意図に関するものではありません。 確かに、欠陥、問題なし。 "妨害行為 "は別の意味を持ち 技術的な性質とは言い難く "欠陥 "という言葉の代わりにはなりません。 英語が母国語でない方はご容赦ください。 bernd 2010.09.11 00:16 #34 blogzr3: しかし、"Sabotage "は別の意味を持ち、技術的な性質はほとんどなく、"欠陥 "という言葉の代わりにはならない。 欠陥は、一方のロボットが他方のロボットを妨害することで現れます。妨害するのはロボットなので、ロボットに意図があるとは思えません。ロボットに欠陥があり、それが他の取引を妨害する原因となっているのです。それ以外には何も書いていないし、意味もない。そして、売り手は不良品を売って いるのです。 削除済み 2010.09.11 12:56 #35 7bit: この欠陥は、一方のロボットがもう一方のロボットを妨害することで現れます。ロボットが妨害しているのですから、ロボットに意図があるとは思えません。ロボットに欠陥があり、それが他の取引を妨害する原因となっているのです。それ以外には何も書いていないし、意味もない。そして、売り手は不良品を売っているのです。 これらのEAのほとんどはZigZagインジケータを使用しているようで、これが原因である可能性が高いと思われます。 Caliber "と呼ばれるEAで初めて起こったとき、私はコードを見るためにEAを逆コンパイルしました。しょぼいEAでしたが、怪しいところはなく、マジックナンバーのロジックも問題なさそうでした。 90分に1回以上取引されないようなロジックを追加しました。 偶然ですが、EAはしばらくしてSLに到達し、その後同じ方向に新しい取引を行う傾向があったので、これもEA全体のパフォーマンスを向上させました。30pipのSLがあれば安全なEAと思われがちですが、1時間に4回もSLを打つようではダメなんです。 このようにトレードを制限することで、バックテストでEAのパフォーマンスが向上し、ベンダーにコードの変更を送ったところ、後日、私の変更点を含むアップデートがリリースされました。 とにかく、当時私はデモ 口座でキャリバーへの変更をテストしていたのですが、同じことが起こりました。取引が開始され、終了されるのがすぐにわかりました。それはデモ口座だったので、私はただ座ってそれが起こるのを見ていました。 この例では、新しいデモ口座でEAが1つだけ実行されていました。このことから、MQL4の問題ではなく、MT4プラットフォームの問題だと思います。 私はMT4とMQL4をよく知っているので、ほとんどの問題を自分で解決することができます。この問題で私は困り果て、他の人に提案を求めているところです。 zzuegg 2010.09.11 13:03 #36 インジケータや計算の問題でしょう。おそらく、0による除算は、特定のケースでのみ発生します。 テスターでそのエラーを繰り返すことができれば、レンタル料は半額になります。 どのEAでこの問題が発生したか、また、いつ発生したかがわかっているので、再現性があるかどうかを確認 するのは簡単なはずです。 その後、あなたがエラーを繰り返すことができたなら、エラーを引き起こすコードの部分を見つけることはそれほど難しくはないはずです。 //z 削除済み 2010.09.11 13:08 #37 Here is one of the older log files. The problem is obvious from the number of trades opened and closed. ログファイルでは、MT4とブローカーが注文の開始と終了の指示を受け取っていることがわかりますが、なぜでしょうか？ ファイル: gain_20100506_log.txt 380 kb 削除済み 2010.09.11 13:23 #38 peterc005: ある日付のログファイルで気づいたことは、数千のエラーで、次のように書かれていました。 09:36:58 HistoryBase: AddTick() の 'EURCHF1' 用に十分なメモリがありません。 09:36:58 Memory handler: cannot allocate 160308896 bytes of memory ログファイルが10kと言うより、7Mbになりました。 bernd 2010.09.11 14:03 #39 peterc005: 古いログファイルの一つを紹介します。問題は、取引開始と終了の数から明らかです。 ログファイルでは、MT4とブローカーが注文の開始と終了の指示を受けていることがわかりますが、なぜでしょうか？ もう一つのログ（experts/logsフォルダのもの）もお持ちですか？こちらには問題のあるEAの名前が含まれています。 bernd 2010.09.11 14:09 #40 zzuegg:どのEAが原因かわかるので どのEAが原因かはまだ分かっていません。 これまで見てきたのは、症状（複数の異なるEAの取引が開始後すぐに閉じられる）といくつかの理論だけです。どのEAが実際にこれらの取引を閉じて いるのかはまだ分かっていません。これ以上の結論を出すには、experts/logs フォルダにある4 つの端末すべての 同じ時間帯のエキスパートログが必要です。これらのログは、私の理論を支持することも否定することもでき、最終的には誰が すべての決済注文を送信しているのかを示すことになります。 123456 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
一貫したパターンを見つけることが困難なため、厄介な問題です。
この問題は時々起こるだけで、一貫して再現することはできません。
マジックナンバーの提案も検討しましたが、当初はその可能性がありましたが、さらなる観察により、その可能性は低いと思われます。
この問題を見たことがある人がいることを祈っています。
マジックナンバーの提案を検討したところ、当初は可能性があったのですが、さらなる観察により、可能性は低いと思われます。
別のEAがそのEAに属さない取引を終了させることを確実に除外するような、詳細な観察結果はどれですか？多くのEAがマジックナンバーの入力を許可していますが、内部的にはそれを使っていませんし、さらに悪いことに、時々使っていますが、常にではなく、特定の終了条件でのみ、何十ものネストしたifと重複した注文の反復ループのいくつかのブランチでのみ使っています。
このグーグル検索
で検索するとたくさん出てきます。すでにリストの3番目のものから始まっています（earlybird1、gridmaster_03など、検索結果全体がそうです）彼らはマジックナンバーを使うと言っていますが、内部では単に無視しています。たくさん見つかるはずです。この欠陥コードパターンはフォーラムに溢れ、多くのEAにコピーペーストされることになります。
販売された製品の欠陥に関するものであり、犯罪の意図に関するものではありません。
確かに、欠陥、問題なし。
"妨害行為 "は別の意味を持ち 技術的な性質とは言い難く "欠陥 "という言葉の代わりにはなりません。
英語が母国語でない方はご容赦ください。
しかし、"Sabotage "は別の意味を持ち、技術的な性質はほとんどなく、"欠陥 "という言葉の代わりにはならない。
この欠陥は、一方のロボットがもう一方のロボットを妨害することで現れます。ロボットが妨害しているのですから、ロボットに意図があるとは思えません。ロボットに欠陥があり、それが他の取引を妨害する原因となっているのです。それ以外には何も書いていないし、意味もない。そして、売り手は不良品を売っているのです。
Caliber "と呼ばれるEAで初めて起こったとき、私はコードを見るためにEAを逆コンパイルしました。しょぼいEAでしたが、怪しいところはなく、マジックナンバーのロジックも問題なさそうでした。
90分に1回以上取引されないようなロジックを追加しました。
偶然ですが、EAはしばらくしてSLに到達し、その後同じ方向に新しい取引を行う傾向があったので、これもEA全体のパフォーマンスを向上させました。30pipのSLがあれば安全なEAと思われがちですが、1時間に4回もSLを打つようではダメなんです。
このようにトレードを制限することで、バックテストでEAのパフォーマンスが向上し、ベンダーにコードの変更を送ったところ、後日、私の変更点を含むアップデートがリリースされました。
とにかく、当時私はデモ 口座でキャリバーへの変更をテストしていたのですが、同じことが起こりました。取引が開始され、終了されるのがすぐにわかりました。それはデモ口座だったので、私はただ座ってそれが起こるのを見ていました。
この例では、新しいデモ口座でEAが1つだけ実行されていました。このことから、MQL4の問題ではなく、MT4プラットフォームの問題だと思います。
私はMT4とMQL4をよく知っているので、ほとんどの問題を自分で解決することができます。この問題で私は困り果て、他の人に提案を求めているところです。
インジケータや計算の問題でしょう。おそらく、0による除算は、特定のケースでのみ発生します。
テスターでそのエラーを繰り返すことができれば、レンタル料は半額になります。
どのEAでこの問題が発生したか、また、いつ発生したかがわかっているので、再現性があるかどうかを確認 するのは簡単なはずです。
その後、あなたがエラーを繰り返すことができたなら、エラーを引き起こすコードの部分を見つけることはそれほど難しくはないはずです。
//z
Here is one of the older log files. The problem is obvious from the number of trades opened and closed.
ログファイルでは、MT4とブローカーが注文の開始と終了の指示を受け取っていることがわかりますが、なぜでしょうか？
ある日付のログファイルで気づいたことは、数千のエラーで、次のように書かれていました。
09:36:58 HistoryBase: AddTick() の 'EURCHF1' 用に十分なメモリがありません。
09:36:58 Memory handler: cannot allocate 160308896 bytes of memory
ログファイルが10kと言うより、7Mbになりました。
古いログファイルの一つを紹介します。問題は、取引開始と終了の数から明らかです。
ログファイルでは、MT4とブローカーが注文の開始と終了の指示を受けていることがわかりますが、なぜでしょうか？
どのEAが原因かわかるので
どのEAが原因かはまだ分かっていません。
これまで見てきたのは、症状（複数の異なるEAの取引が開始後すぐに閉じられる）といくつかの理論だけです。どのEAが実際にこれらの取引を閉じて いるのかはまだ分かっていません。これ以上の結論を出すには、experts/logs フォルダにある4 つの端末すべての 同じ時間帯のエキスパートログが必要です。これらのログは、私の理論を支持することも否定することもでき、最終的には誰が すべての決済注文を送信しているのかを示すことになります。