リーグ・オブ・トレーディング・システムズこれからもよろしくお願いします。 - ページ 152 1...145146147148149150151152153154155156157158159...360 新しいコメント Eduard_D 2019.07.01 10:13 #1511 Vladimir Baskakov:テストモードと オープニングポジションのアルゴリズムを混同してはいけません。バーの開閉に基づくアルゴリズムであれば、テストと最適化は大きな楽しみです。 私が見る限り、アルゴリズムは直前のバーを閉じることに基づいています。オープニングでは、すべてのロジックが壊れてしまうので、うまくいかないでしょう。 削除済み 2019.07.01 10:21 #1512 Eduard_D: 私が見る限り、アルゴリズムは直前のバーを閉じることに基づいています。オープニングでは、すべてのロジックが壊れるので、うまくいきません。 悪いロジックとは、コドベースの例を参照してください。 //--- we work only at the time of the birth of new bar datetime time_0=iTime(m_symbol.Name(),Period(),0); if(time_0==ExtPrevBars) return; ExtPrevBars=time_0; Georgiy Merts 2019.07.01 11:13 #1513 Eduard_D: ゲオルギー、脱帽です...!あなた(とインド人)は、リーグを最適化しすぎてタイヘンなことになってるんですね。 特に、2時間の過剰最適化を信じない否定的な人たちに。 しかも、それは1 足のTCだけ。 まあ、私のハードウェアはあなたより悪いのですが、たとえあなたが半分の時間を費やしたとしても、あなたのコンピュータはノンストップで過剰最適化されているはずです。 だから、TCを常に完全な形で用意するためには、デモ口座で継続的に作業する必要がある、という結論に達したのです。そして、「コントロールショットを見せた」人だけを再最適化する必要があります。1日に3個から10個くらいは出ますね。平均して-5人。最適化には1システムあたり15分〜2時間、さらに5〜20の部門を異動させる(ただし、異動はコード内の部門記号の変更と再コンパイルだけなので、非常に短時間で完了する)。 Georgiy Merts 2019.07.01 11:16 #1514 Vladimir Baskakov: バー・オープニングでアルゴリズムを作れば、すべてがうまくいく。ダフ屋がいるわけでもないのに、なぜ1ティックごとに 拷問するんだ、機械が惜しい。 飛ばないよ。私のコードは、今のままでも十分に最適化されています。それに、バーの開店のアルゴリズムは、どちらかというと不正確です。 私のティック処理は必要な時だけ(タイムフレームごとに1回)実行されますが、それでも、かなり多くの小さな事前チェックが各ティックで実行され、これは必要ではありません。 その結果、1M OHLCモードが最も合理的なものとして、とっくに定着しているのです。 Georgiy Merts 2019.07.01 11:19 #1515 Roman Shiredchenko: そのためのものです。そうなんです。 私のアカウントは2599118 です。 200640, 642750, 642342, 642350, 642422. モニタリングでもいいのでは? それでいいんです。 口座番号:2599118 マジック:200640 レジストリコード:2107362309 ----------------------------------- 口座番号:2599118 マジック: 642750 RegCode: 3877358909 ----------------------------------- 口座番号:2599118 マジック: 642342 RegCode: 3030109576 ----------------------------------- 口座番号:2599118 マジック: 642350 RegCode: 2963000471 ----------------------------------- 口座番号:2599118 マジック:642422 RegCode: 2359020562 ----------------------------------- Georgiy Merts 2019.07.01 11:20 #1516 Eduard_D: Georgeさん、現在の640150の設定を掲載してください。 一般的には、あまり実感がわかないですね。しかし、例外的に、初期化関数がある。 m_didData.m_etWorkTimeFrame = PERIOD_H4; m_dtBuildMoment = D'2018.07.23'; m_iH6WorkIdx = -1; m_uiEMAPeriod = 169; m_dFilterDATRLevel = 0.00; m_dTPvsDATR = 2.95; m_esEnterSignal = ES_LONGSTRIKE_BAR_3; m_bInverseSignal = false; m_dUnlossTriggerVsDATR = 0.20; m_dUnlossDistanceVsDATR = 0.17; m_dSLvsDATR = 4.90; m_cfpControlParams.m_dStability = 0.358; m_lcEALeagueClass = LC_HIGH; ここで注目すべきは - すでに計算されたSL、TP、トルクとブレイクイーブンレベル(DATRとの関係で) 削除済み 2019.07.01 11:23 #1517 Georgiy Merts: 飛ばないよ。私のコードは、今のままでも十分に最適化されています。それに、バーの開店のアルゴリズムは、どちらかというと不正確です。 私のティックは必要な瞬間(タイムフレームごとに1回)にのみ処理されますが、それにもかかわらず、かなり多くの小さな事前チェックが各ティックで実行されます - これは必要ではありません。 その結果、1MのOHLCモードが最も合理的であると判断して、ずっと前から決めています。 つまり、テストモードと オープニングアルゴリズムの違いも理解できていないのですね。カナシミ Eduard_D 2019.07.01 12:19 #1518 Georgiy Merts: 一般的には、あまり実感がわかないですね。しかし、例外として、初期化関数があります。 ここで注目すべきは - すでに計算されたSL、TP、トルクとブレイクイーブンレベル(DATRとの関係で) uilMaxTPC4Enterの値を教えてください。 Georgiy Merts 2019.07.01 12:43 #1519 Eduard_D: uilMaxTPC4Enterの値を教えてください。 ゼロです。この機能は非常に古く、当時はまだこのようなパラメータは存在しなかった。 Georgiy Merts 2019.07.01 12:45 #1520 Vladimir Baskakov: つまり、テストモードと オープニングアルゴリズムの違いも理解していないのです。悲しい はい、全く理解できません、ウラジミールさん。 上で述べたように、解析は時間枠期間ごとに1回行われます。しかし、いくつかの事前チェックは、すべてのティックで行います。 オープンプライス」モードでは、1つのタイムフレームにつき1ティックを使用します。それは非常にラフですね。1M OHLC」モードでは、1分間に4ティックです。その方がずっといいし、ノンスキャルパーには十分です。 つまり、1時間に1ティックだとすると、TSは数時間分の非常に大まかな価格を受け取り、それ以上の小さな時間枠は全く見ません。 私たちの経験の違いを考えると、あなたの非難は非常に興味深いものです。 1...145146147148149150151152153154155156157158159...360 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
テストモードと オープニングポジションのアルゴリズムを混同してはいけません。バーの開閉に基づくアルゴリズムであれば、テストと最適化は大きな楽しみです。
私が見る限り、アルゴリズムは直前のバーを閉じることに基づいています。オープニングでは、すべてのロジックが壊れてしまうので、うまくいかないでしょう。
私が見る限り、アルゴリズムは直前のバーを閉じることに基づいています。オープニングでは、すべてのロジックが壊れるので、うまくいきません。
悪いロジックとは、コドベースの例を参照してください。
ゲオルギー、脱帽です...!あなた(とインド人)は、リーグを最適化しすぎてタイヘンなことになってるんですね。
特に、2時間の過剰最適化を信じない否定的な人たちに。
しかも、それは1 足のTCだけ。
まあ、私のハードウェアはあなたより悪いのですが、たとえあなたが半分の時間を費やしたとしても、あなたのコンピュータはノンストップで過剰最適化されているはずです。
だから、TCを常に完全な形で用意するためには、デモ口座で継続的に作業する必要がある、という結論に達したのです。そして、「コントロールショットを見せた」人だけを再最適化する必要があります。1日に3個から10個くらいは出ますね。平均して-5人。最適化には1システムあたり15分〜2時間、さらに5〜20の部門を異動させる(ただし、異動はコード内の部門記号の変更と再コンパイルだけなので、非常に短時間で完了する)。
バー・オープニングでアルゴリズムを作れば、すべてがうまくいく。ダフ屋がいるわけでもないのに、なぜ1ティックごとに 拷問するんだ、機械が惜しい。
飛ばないよ。私のコードは、今のままでも十分に最適化されています。それに、バーの開店のアルゴリズムは、どちらかというと不正確です。
私のティック処理は必要な時だけ(タイムフレームごとに1回)実行されますが、それでも、かなり多くの小さな事前チェックが各ティックで実行され、これは必要ではありません。
その結果、1M OHLCモードが最も合理的なものとして、とっくに定着しているのです。
そのためのものです。そうなんです。
私のアカウントは2599118 です。
200640, 642750, 642342, 642350, 642422.
モニタリングでもいいのでは?
それでいいんです。
口座番号:2599118
マジック:200640
レジストリコード:2107362309
-----------------------------------
口座番号:2599118
マジック: 642750
RegCode: 3877358909
-----------------------------------
口座番号:2599118
マジック: 642342
RegCode: 3030109576
-----------------------------------
口座番号:2599118
マジック: 642350
RegCode: 2963000471
-----------------------------------
口座番号:2599118
マジック:642422
RegCode: 2359020562
-----------------------------------
Georgeさん、現在の640150の設定を掲載してください。
一般的には、あまり実感がわかないですね。しかし、例外的に、初期化関数がある。
ここで注目すべきは - すでに計算されたSL、TP、トルクとブレイクイーブンレベル(DATRとの関係で)飛ばないよ。私のコードは、今のままでも十分に最適化されています。それに、バーの開店のアルゴリズムは、どちらかというと不正確です。
私のティックは必要な瞬間(タイムフレームごとに1回)にのみ処理されますが、それにもかかわらず、かなり多くの小さな事前チェックが各ティックで実行されます - これは必要ではありません。
その結果、1MのOHLCモードが最も合理的であると判断して、ずっと前から決めています。
一般的には、あまり実感がわかないですね。しかし、例外として、初期化関数があります。
ここで注目すべきは - すでに計算されたSL、TP、トルクとブレイクイーブンレベル(DATRとの関係で)uilMaxTPC4Enterの値を教えてください。
uilMaxTPC4Enterの値を教えてください。
ゼロです。この機能は非常に古く、当時はまだこのようなパラメータは存在しなかった。
つまり、テストモードと オープニングアルゴリズムの違いも理解していないのです。悲しい
はい、全く理解できません、ウラジミールさん。
上で述べたように、解析は時間枠期間ごとに1回行われます。しかし、いくつかの事前チェックは、すべてのティックで行います。
オープンプライス」モードでは、1つのタイムフレームにつき1ティックを使用します。それは非常にラフですね。1M OHLC」モードでは、1分間に4ティックです。その方がずっといいし、ノンスキャルパーには十分です。
つまり、1時間に1ティックだとすると、TSは数時間分の非常に大まかな価格を受け取り、それ以上の小さな時間枠は全く見ません。
私たちの経験の違いを考えると、あなたの非難は非常に興味深いものです。