リーグ・オブ・トレーディング・システムズこれからもよろしくお願いします。 - ページ 152

新しいコメント
 
Vladimir Baskakov:
テストモードと オープニングポジションのアルゴリズムを混同してはいけません。バーの開閉に基づくアルゴリズムであれば、テストと最適化は大きな楽しみです。

私が見る限り、アルゴリズムは直前のバーを閉じることに基づいています。オープニングでは、すべてのロジックが壊れてしまうので、うまくいかないでしょう。

 
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;
 
Eduard_D:

ゲオルギー、脱帽です...！あなた（とインド人）は、リーグを最適化しすぎてタイヘンなことになってるんですね。

特に、2時間の過剰最適化を信じない否定的な人たちに。

しかも、それは1 足のTCだけ。

まあ、私のハードウェアはあなたより悪いのですが、たとえあなたが半分の時間を費やしたとしても、あなたのコンピュータはノンストップで過剰最適化されているはずです。

だから、TCを常に完全な形で用意するためには、デモ口座で継続的に作業する必要がある、という結論に達したのです。そして、「コントロールショットを見せた」人だけを再最適化する必要があります。1日に3個から10個くらいは出ますね。平均して-5人。最適化には1システムあたり15分〜2時間、さらに5〜20の部門を異動させる（ただし、異動はコード内の部門記号の変更と再コンパイルだけなので、非常に短時間で完了する）。

 
Vladimir Baskakov:
バー・オープニングでアルゴリズムを作れば、すべてがうまくいく。ダフ屋がいるわけでもないのに、なぜ1ティックごとに 拷問するんだ、機械が惜しい。

飛ばないよ。私のコードは、今のままでも十分に最適化されています。それに、バーの開店のアルゴリズムは、どちらかというと不正確です。

私のティック処理は必要な時だけ（タイムフレームごとに1回）実行されますが、それでも、かなり多くの小さな事前チェックが各ティックで実行され、これは必要ではありません。

その結果、1M OHLCモードが最も合理的なものとして、とっくに定着しているのです。

 
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

-----------------------------------

 
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との関係で）
 
Georgiy Merts:

飛ばないよ。私のコードは、今のままでも十分に最適化されています。それに、バーの開店のアルゴリズムは、どちらかというと不正確です。

私のティックは必要な瞬間（タイムフレームごとに1回）にのみ処理されますが、それにもかかわらず、かなり多くの小さな事前チェックが各ティックで実行されます - これは必要ではありません。

その結果、1MのOHLCモードが最も合理的であると判断して、ずっと前から決めています。

つまり、テストモードと オープニングアルゴリズムの違いも理解できていないのですね。カナシミ
 
Georgiy Merts:

一般的には、あまり実感がわかないですね。しかし、例外として、初期化関数があります。

ここで注目すべきは - すでに計算されたSL、TP、トルクとブレイクイーブンレベル（DATRとの関係で）

uilMaxTPC4Enterの値を教えてください。

 
Eduard_D:

uilMaxTPC4Enterの値を教えてください。

ゼロです。この機能は非常に古く、当時はまだこのようなパラメータは存在しなかった。

 
Vladimir Baskakov:
つまり、テストモードと オープニングアルゴリズムの違いも理解していないのです。悲しい

はい、全く理解できません、ウラジミールさん。

上で述べたように、解析は時間枠期間ごとに1回行われます。しかし、いくつかの事前チェックは、すべてのティックで行います。

オープンプライス」モードでは、1つのタイムフレームにつき1ティックを使用します。それは非常にラフですね。1M OHLC」モードでは、1分間に4ティックです。その方がずっといいし、ノンスキャルパーには十分です。

つまり、1時間に1ティックだとすると、TSは数時間分の非常に大まかな価格を受け取り、それ以上の小さな時間枠は全く見ません。

私たちの経験の違いを考えると、あなたの非難は非常に興味深いものです。

1...145146147148149150151152153154155156157158159...360
新しいコメント