voidOnTick()
{
datetime dtBarTime = _OpenBarTime(TimeCurrent());
if(dtBarTime < dtLastProceedTick)
return;
dtLastProceedTick = dtBarTime
/*
Вся обработка тика, весь анализ, все получение данных, все торговые операции
....
*/
}
また、「全ティック」モードと「始値で」モードでの速度はほとんど同じです。
しかし、「始値で」モードを使う場合、バーの影でタッチしたストップのトリガーをどう考えるのだろう？
長い影が「下」にある強気なバーがいくつかあるとします（リーグ・シックスの場合、これは非常によくある出来事です）。オープニング価格について - 保証金の値上げを行いました。1M OHLCと "all ticks "の場合 - ストップロスをいくつも持っています。
でも、なぜか「無視」しないんですよね？
まあ、言ったでしょ、自尊心を満たすためにこのスレッドを運営しているわけではないって...。そして、質問が関連性のあるものであれば、特に他の人も読んでいるのだから、それに答えてはどうだろう。
ウラジーミルが道化を演じているとしたら、まあ...彼はそういうのが好きなんだろうけど...。左様で
スタジオのコードをお願いします。実証してください！1mのOHLCをどこに置くかです。面白いですね。ためらわずに、今すぐ見せてください。
あなたは "プーさん "です。そんなピエロのお忍びで話すのは嫌なんです。
しかし、例外として、Expert AdvisorのOnTick()関数の 入力は以下のとおりです。
また、「全ティック」モードと「始値で」モードでの速度はほとんど同じです。
しかし、「始値で」モードを使う場合、バーの影でタッチしたストップのトリガーをどう考えるのだろう？
長い影が「下」にある強気なバーがいくつかあるとします（リーグ・シックスの場合、これは非常によくある出来事です）。オープニング価格について - 保証金の値上げを行いました。1M OHLCと "all ticks "の場合 - ストップロスをいくつも持っています。
その後、"始値 "を使うことを提案するのですか？
それは前方（最適化期間の％の時間に応じて）後に30％を超える場合は、リーグのTSは、デモに設定し、本物の前にラのように、ここでレポートを投稿してはならないが、最適化のために再送信します。
理解できない。
ここで、私はTSを取り、テスターでそれを実行し、バックテストを持ち、前進し、パラメータの最適なセットを選択し、ブレークイーブンパラメータと保護TP - SLを決定し、デモにそれを置く。何かご提案がありますか？
入札からコントロールショットを 取るために、そこで待っているわけではありません。
チェックショット」は、主に市場が変化したことを確認するために必要です。
1年前、GBPUSDのTS ChnTrendSPは、バランスでトップ、品質でトップ5に入るという素晴らしい結果が出ていました。
そして、そのまま崩壊してしまったのです。そして、この半年近くは、リーグ中地区への進出もままならない。ニジニにぶら下がり、定期的に "コントロールショット "を見せる。
そして、この1年のポンドドル相場が1年前と大きく異なっていることをよく表しています。コントロールショット」だけで、このことに「早い段階で」気づくことができるのです。
理解できない。
ここで、私は自分のTSを取り、テスターでそれを実行し、バックテストを持ち、前進し、パラメータの最適なセットを選択し、ブレークイーブンパラメータと保護TP - SLを決定し、デモにそれを置く。何かご提案がありますか？
私はそれがそうでない場合、デモでの取引は、遅くとも最適化期間の20％よりも開始すること、例えば、前方、2年間の最適化 - 1四半期、その後デモ、取引はデモでのテストの1四半期後に、有益である場合 - これは最適化期間の25％になります、より、貿易にそれを残すかのように - さらに損をする貿易があることを確率が...であると思います。
私はあなたが制限的な制御フレームを導入したいので、それはそのように判明しなかった、例えば、2年 - 最適化、1四半期 - 前方、1 - 四半期あなたはデモを持って、その後、部門間でそれらのベスト/ワーストを散乱し、デモでレポートを置くことは本質的にシステムが取引された時間の25％後、すなわちそれは時間のパラメータと設定ですでに "時代遅れ "のとき、そしておそらくそれはフォローアップショットを待たずにパラメータ値の最適化に再送されなければならないです...。つまり、TC LIGIに関する情報がすでにここに「古い」ということにならないように......。
---
P.S.書き込み、最適化後のどのような期間で - あなたは入札レポートTC-okにここに投稿する？
あなたは "プーさん "です。そんなピエロのお忍びで話すのは嫌なんです。
しかし、例外として、Expert AdvisorのOnTick()関数の 入力は以下の通りです。
また、「全ティック」モードと「始値で」モードでの速度はほとんど同じです。
しかし、「始値で」モードを使う場合、バーの影でタッチしたストップのトリガーをどう考えるのだろう？
長い影が「下」にある強気なバーがいくつかあるとします（リーグ・シックスの場合、これは非常によくある出来事です）。オープニング価格について - 保証金の値上げを行いました。1M OHLC と "all ticks" で - ストップロスをいくつも持っている。
その後、"始値 "を使うことを提案するのですか？
バカ言うなよ）コードを教えてください。1m OHLCを一緒に探しましょう。
コードをお渡ししました。このコードは、1つのバーにつき1回使用できます。ダニがどうであろうと同時に、1M OHLC と "all ticks" では、ストップをキャッチしますが、"opening prices" では、クソをキャッチしません。
また、「1MのOHLCのペアより、600TSの始値の 方が速い」なんてことは論外です。
偉そうなこと言ってるけど、まだ自分のことは何も発表してないじゃん。
そして、そこにあるのは......。教えてあげたい特に、「Equityがバランスに来るので、Equityよりもバランスが重要」という話は面白いですね。さて、さて...
私はそれがそうでない場合は、デモでの取引は、例えば、最適化期間の遅くとも20％を開始すること、2年間の最適化、前方 - 1四半期、その後デモ、取引はデモでテストの1四半期後に、利益である場合 - これは、最適化期間の25％になりますより、取引にそれを残すかのように - その後不採算取引があるだろうという大きなチャンスがある...
私はあなたが制限的な制御フレームを導入したいので、それはそのように判明しなかった、例えば、2年 - 最適化、1四半期 - 前方、1 - 四半期あなたはデモを持って、その後、部門間でそれらのベスト/ワーストを散乱し、デモでレポートを置くことは本質的にシステムが取引された時間の25％後、すなわちそれは時間のパラメータと設定ですでに "時代遅れ "のとき、そしておそらくそれはフォローアップショットを待たずにパラメータ値の最適化に再送されなければならないです...。つまり、TC LIGIに関する情報がすでにここに「古い」ということにならないように......。
---
P.S.書き込み、最適化後のどのような期間で - あなたは入札レポートTC - OKに月曜日ここに投稿する？
だから、何が問題なのか、よくわからないんです。取引の質を評価するためには10回の取引が必要です。その後、報告書に表示される場合があります。
前回のレポート、システム442021（EURGBPのChnFlatSP）を見るのに、遠くへ行く必要はありません。バックテスト15.06.17 - 15.06.18, フォワード15.06.18 - 15.06.19, 実際にはフォワードからわずか2週間後です。25%」はどこにある？
システム443040（EURCHFのEMAFlatSP）があります - 一般的に、それは品質によって3位にありますが、その前進は6.06.19に終了 - 3週間前、17取引で。あるいはシステム742350は、少し前に取引に出して16件の取引があり、時計ではなく4時間足で動くことを考えると、かなり活発な動きをしていますね。
テストショット」を見せたシステム、部門から部門へ移動したシステム--は、毎日稼働している。一般的に、3〜10本のTCは過剰最適化され、5〜20本のTCは事業部から事業部へと移動していく。
レポートは毎週月曜日に掲載され、前週までの各掲載TSの全取引が含まれます。
だから、何が問題なのかよくわからないのです。取引の質を評価するためには10回の取引が必要です。その後、報告書に表示されることもあり、このようなことが何度もありました。
遠くへ行く必要はありません、最後のレポートを見てください - システム442021（EURGBPのChnFlatSP）です。バックテスト15.06.17 - 15.06.18, フォワード15.06.18 - 15.06.19, 実際にはフォワードからまだ2週間しか経っていません。25%」はどこにある？
システム443040（EURCHFのEMAFlatSP）があります - 一般的に、それは品質によって3位にありますが、その前進は6.06.19に終了 - 3週間前、17取引で。あるいはシステム742350は、少し前に取引に出して16件の取引があり、時計ではなく4時間足で動くことを考えると、かなり活発な動きをしていますね。
テストショット」を示したシステムや、部門から部門へ移動したシステム-は、毎日実行されます。一般的に3～10本のTCは過剰に最適化され、5～20本のTCは事業部から事業部へと移動します。
毎週月曜日に掲載されるレポートは、先週までの各TCの全案件を含んでいます。
OKです。すべてクリアしています。
ここで明確にしたいのは、レポートが掲載されるのは、最適化の時間間隔が何％なのか、ということです。
PPSSY - そんなに興奮しないでください - 彼は違いも何もかも理解しています - 彼らはここであなたを荒らしているだけです、それだけです...
ここで明らかにしたいのは、最適化の時間間隔が何％で、レポートが掲載されているかということです。
さて、試算してみよう。
最適化の時間は、1年前、1年前の2年間です。 レポートは毎週掲載されるので、約0.2～1％です（TSが週の初めに実行されるか、最後に実行されるかによって異なります）。
我々は、TSが10取引後にのみレポートに表示される可能性があることを考慮する必要があります（そうでなければ、取引の品質を推定することは不可能です）。つまり、最良のケースでは、TSが頻繁に取引を行う場合 - 10件の取引すべてが、システム開始後、レポートが投稿される前、つまりまさにこの週の期間内に行われることになります。しかし、月に2、3回しかトレードしないTCもある。そしてもちろん、レポートに表示されるのは、最適化期間の25％である6ヶ月間の作業後です。
もう一つの可能性は、（履歴の結果から）最初は低位または中位に位置していたシステムが、突然高位に値する取引品質を示し始める場合です（逆トレーリングシステム、「6」や「7」の場合、それは非常によく起こる可能性があります）。この場合、高い取引品質が検出された直後（当日）に上位部門に移動し、そこで再び10回取引して取引品質を測定する必要があり、格付けに入るチャンスがある。 しかし、最初の10回の取引で上位部門に到達したシステムが、再び中下位部門の品質を示し、元の場所に戻ってしまうケースもある。