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

 
Georgiy Merts:

だから、この作業以外はほとんど自動化されているんだ。

選択することなく、すべてが自動化されています。私はただ、システムの過剰最適化のプロセスを観察し、その中で最も優れたものについてレポートを投稿しているだけです。

もし、同じシンボルに強いトレンド系と強いフラット系を設定した場合、スプレッドの存在だけで利益を出すことはできません。また、どちらのシステムも深刻な赤字になることが明らかなのに、「どっちもどっち」というのはどうなんでしょう!

どこが「真実に向き合おうとしない」のか・・・。どんな「真実」を語っているのだろうか。システム全体では利益を出せないということですか?それは事前に分かっていたことで、TCリーグの趣旨とは違う。目的は、「何をすれば儲かるか」から「すでに儲かっているものの中から、最も安定したものを選ぶにはどうしたらいいか」という問いかけに移ることだった。それはかなり解決されたと思います。次は、この最も重要で最後の質問です。

一緒でなくてもいいんです。

しかし、その選択こそが問題なのです。

もっと簡単に言うと、2つの簡単なシステムがあります。1つは毎日ロングで開き、もう1つはショートで開きます。それぞれ、ある期間に稼ぐ。一方を開始し、他方を停止する期間の選び方を学ぶ必要があります。
考え方がわかっていただけたでしょうか?)

そして、私の戸惑いは、一度のテストを実行するのではなく、取引の結果を観察するために数ヶ月間、適切な場所から手を持つ合理的な人という事実のためです。

新年あけましておめでとうございます。

 
Andrey Khatimlianskii:

一緒にいる必要はありません。

しかし、その選択こそが問題なのです。

さらに単純化すると、2つの単純なシステムがあります。1つは毎日ロングで開き、もう1つはショートで開きます。それぞれ、ある期間に稼ぐ。私たちは、一方を可能にし、他方を止めるための期間を選択することを学ばなければなりません。
考え方がわかっていただけたでしょうか?)

そして、私が困惑しているのは、手の空いている合理的な人が、たった1回のテストを実行する代わりに、何カ月もトレードの結果を眺めていることです。

新年あけましておめでとうございます。

ジョージーさんを応援しています最後は彼のリーグが一矢報いるのではないでしょうか!
 
Vladimir Baskakov:
ジョージさんを応援しています彼のリーグは、最後には飛躍すると思います

ありがとうございます。

"ショット "は間違った表現です。リーグの本質は「シュート」ではない--今回の選考問題が解決されれば、「順調な上昇」を期待したいところだ。

私はいつも、サッカークラブを例えに出します。しかし、もう一つ印象的な例えがあります。出会い系サイトです(こんにちは、ヴォルチャンスキーさん)。

マンバで知り合いになろうとした人は、そこにあることを知っている - 魅力的でないメンバーの多くは、少なくとも自分自身の何かを表すもの - ほとんど常に自分の価格を作ることができない、と未知の応募者から期待しています。また、あなたが注意を引くのに十分幸運だ場合でも - 会話の対談者が何かを好きではない可能性があり、彼女はすぐに無視にあなたを置くという事実ではない。また、仮に会わせることができたとしても、やはり親しい間柄になる保証はない。一方的に力を入れても、得られるのは経費だけ。

つまり、儲かるTSを探すのとほとんど同じで、くだらないものはたくさんあるし、まともなものは稀だし、設定も簡単ではないし、それを考慮しても、それで儲かる保証はないし、いつシステムが停止するかもしれない。

つまり、マンバからブロードへの通常のアプローチは、システムを見つけるための通常のアプローチと似ているのです。惜しい結果で。ごくまれに、運のいい人もいる。しかし、大多数の人々は、「マンバで釣るものは何もない」と確信しています。 しかし、マンバを使って、それ自体でかなり規則的なセックスをしている会員がいます。どのようにしているのだろうか。リーグ方式」による参加者全員が同じ定型文を送り、何か答えた人も定型文で、見ずに答える。その結果、最も魅力的な女性は手に入らないが、醜い女性とは定期的にヤレるようになる。キーワードは「定期的に」だ。

ここでは、TCリーグと同じです。最もシンプルなTCに何らかの記録を示すことを期待するのは愚かなことだ。偶然、もちろん、それはかもしれないが、これらのレコードは、私は劇的な失敗(私は繰り返し言っているように、リーグの単一のTSは、預金を排出することはできませんが、代わりにお金を稼ぐの引き出しに入る - 簡単に)、正確に多くのようになると思います。そして、主な利益は、目立たない、灰色がかったTSの仕事にあり、それは徐々に結果をもたらすでしょう。

 

神様、あなたの瓶の中の魚はなんてナンセンスで気持ち悪いんでしょう。

量は足し算でなければ、質にはならないのです。

 
Maxim Dmitrievsky:

神様、あなたの瓶の中の魚はなんてナンセンスで気持ち悪いんでしょう。

量は足し算でなければ、質にはならない。

統計が納得しない。

和の期待値は個々の量の和の期待値に等しく、和の分散は分散の和に等しい。つまり、和の標準偏差は二乗和の平方根に等しく、これは通常の和よりも小さい。つまり、量が質へとかなりスムーズに変換されるのです。

 
Andrey Khatimlianskii:

しかし、その選択こそが問題なのです。

簡単に説明すると、2つの単純なシステムがあります。1つは毎日ロングで開き、もう1つはショートで開きます。それぞれ、ある期間に稼ぐ。私は、一方を活性化させ、他方を停止させる期間を選択することを学ばなければなりません。
考え方がわかっていただけたでしょうか?)

そして、私が困惑しているのは、手の空いている合理的な人が、たった1回のテストを実行する代わりに、何カ月もトレードの結果を眺めていることです。

新年あけましておめでとうございます。

だから、一番の問題は「選択」であることは隠していませんし、そのためにリーグを作ったのです

以前は、何を思いついたらシステムが成立するのかがわかりませんでした。テスターでも利益が出ません。テスターでも!現実をどう捉えるか・・・。そして、5回の試行のうち、テスターの結果が出たのは1回だけでした。しかし、これらのシステムを実際に使ってみると、必ずと言っていいほど失敗するのです。そして、すべてがやり直しになった。システムを動かすために何をしなければならないのか、理解できなかったのです。リアルトレードに使うかどうかも聞けなかった!?

リーグ構想のおかげで、この問題から逃れることができたのです。現在、私は常に、うまく機能し、しばらくDemoで動いていたシステムのセットを持っています。そして、今、私が取り組んでいるのは、「選択」の問題なのです。その問いはどちらかになりますが、複雑なシステムを作ろうとすれば......ということではありません。リーグと一緒で、まだ持っているんです。それでいいんです。

 
Serqey Nikitin:

戦略構築の理解度が違う...。

私の考えでは、TSのデバッグは、正しいプロフィットセオリーを確認した後、長期間にわたってストラテジーをテストするところから始まる...。

あなたのアプローチは異なっている...あなたは "試行錯誤 "法によるデモ口座で収益性の高いオプションを決定しようとしている、それが動作しない場合は、別のためにそれを変更する...このアプローチは可能ですが、より多くの時間がかかり、予測できない、戦略の理論が存在しないので"結果 "しか見ていない。TSが受け入れがたい振る舞いを見せたら-即座に取引から外される...」。

方法論的には、あなたのアプローチは正しくありません......しかし、それはあなたの方法です! 新年の幸運と繁栄を祈ります。

NO.

どんな「突き方」?それはちょうどあなたです(何回私は私を "突く "しないように求めることができます) "テストの方法" - あなたはこの非常に "利益を上げるの理論 "とTS自体を行うあなたはどこを取得するのでしょうか?適当に、気に入ったから開発する--「経験則」でないものはない?この分野で利益が出るという保証はどこにあるのでしょうか?

TCリーグは「ワイドなギブアップ方式」です。TCのバリエーションをフルに活用しています。そして、それこそが、TCリーグが確実に利益領域を「カバー」することを保証しているのである。

この方法の場合、TCを改善しても収益に結びつかない可能性があるのが難点です。また、リーグの経験から、絶対に互換性のないシンボルやシステムがあることがわかりました。ストラテジーテスターでも取引の質が極めて低く、デモにインストールするとすぐに許容できない動作を示し、常に過剰な最適化を要求されます。つまり、このシステムを使おうとすると、どんなに改良しても必ず赤字になるのです。でも、『流れに乗れば』、システムは大儲けできるんです。

私の手法では、儲かるシステムも儲からないシステムも、すべて一度に「ネットワークに入る」ので、まさに「選択」が難しいのです。つまり、利益は保証されているが、問題は「損失を解消する」必要があることだ。しかし、システムが単純であることを考えると、リーグはあまり利益を上げることはできないが、より安定したものになるであろう。

 

そこで、約束通り、あるシステムを例にして、再最適化のプロセスを説明します。実際には、このような再最適化が毎日3〜5回、多いときには20回行われています。 しかし、すべては自動化されており、私は不測のエラーが発生しないようにプロセスをコントロールし、再コンパイルした新しいバージョンのリーグをUPUにアップロードするだけです。

スクリプトを実行すると、許容できない挙動を示したシステムのリストが作成されます。

まず、NZDJPY、443740、EMAFlatSP、Many SL (2)だとします。

これは、固定TP-SLと価格とスライドの交差によって示される、トレンドに逆らってインパルスでエントリーのTSです。TSが許容できない数のSLを連続で表示した(2個、履歴上ありえない)。

過剰最適化のために送信され、その結果、新しい初期化関数がファイルに書き込まれました。その「アクティブコア」はこのような形をしています。

   _NOT_TESTED_IF(GetWorkSymbol() != CS_NZDJPY);
   m_didData.m_etWorkTimeFrame = PERIOD_H1;
   m_bMustExitOnWorkEnd = false;
   m_bMustExitOnWeekEnd = true;
   m_dtBuildMoment = D'2019.01.02';
   m_iH6WorkIdx = -1;
   m_uiEMAPeriod = 7;
   m_dFilterDATRLevel = 0.10;
   m_dTPvsSL = 0.64;
   m_dSLvsDATR = 1.85;
   m_esEnterSignal = ES_LONGSHIFT_BAR_5;
   m_bInverseSignal = true;
   m_dUnlossTriggerVsDATR = 0.70;
   m_dUnlossDistanceVsDATR = 0.07;
   m_uiMaxDirectTPC = 0;
   m_cfpControlParams.m_dStability = 0.145;
   m_lcEALeagueClass = LC_MEDIUM;

また、制御パラメータ機能も生成されており、その「アクティブコア」は以下の通りです。

   // NZDJPY
   // FlatSP & EMA
   _NOT_TESTED_IF(GetMagic() != 443740);
   _NOT_TESTED_IF(m_cfpControlParams.m_dStability <= 0);           // должна быть заполнена в конструкторе
   _NOT_TESTED_IF(m_cfpControlParams.m_dStability >= 1);           // должна быть заполнена в конструкторе
   _NOT_TESTED_IF(m_cfpControlParams.m_dStability == EMPTY_VALUE); // должна быть заполнена в конструкторе
   m_cfpControlParams.m_dtTradeStartMoment = D'2017.01.02';
   m_cfpControlParams.m_dtTradeEndMoment = D'2018.12.31';
   m_cfpControlParams.m_uiNumOfTrades = 222;
   m_cfpControlParams.m_uiNumOfProfitTrades = 137;
   m_cfpControlParams.m_dClearPriceProfit = 19.12300000;
   m_cfpControlParams.m_dMaxPriceDrawdown = 5.18400000;
   m_cfpControlParams.m_uiMaxLoseQueue = 6;
   m_cfpControlParams.m_uiMaxTrades2PriceMax = 39;
   m_cfpControlParams.m_ulMaxSec2PriceMax = 10942096;
   m_cfpControlParams.m_ulMaxSec2NewTPC = 1228040;
   m_cfpControlParams.m_dPriceProfitFactor = 1.37144300;
   m_cfpControlParams.m_dPriceRecoveryFactor = 3.68885031;
   m_cfpControlParams.m_dGrailRatio = 0.64046145;
   // dGrail.RecoveryPerYearComponent = 0.154
   // dGrail.m_dSharpeComponent = 0.934
   // dGrail.m_dProfitFactorComponent = 0.686
   // dGrail.m_dTradesPerYearComponent = 0.702
   // dGrail.m_dAvrMoneylotPerTradeComponent = 1.556
   // Trades per week =  2.13
   // Wait for renew price maximum (days) =  116
   // Max wait for new TPC (hours) =  311

あなたは、CUが64%という低い品質(グレイル率)でリーグの "平均"(LC_MEDIUM)部門に到達することがわかります(お気に入りのトレードの品質を比較し、50%以下の品質でCUは "下位 "部門に到達することになります)。

2年間の歴史の中で、価格の最大 ドローダウンは5.18千3桁ポイント、連続SLの最大回数は6回であった。年間平均価格再計算はわずか3.689(これが取引品質スコアが低い主な理由です)、利益率は1.37です。特集の最後にコメントを残していますが、そこには品質スコアの本質、つまりスコアの構成要素がわずかに見え隠れしています。例えば、同じ低反発でも15%しかないと試算されており、極めて低い水準です。平均して週に2.13回の取引が行われ、価格の最大更新は116日以内、1回の取引の決済は最大311時間待つ必要があります。

ちなみに、このTSが前回許したSLは1回のみであったことも特筆すべき点である。現在では6台まで増えています。このシンボルでは、市場が本当に大きく変化していることがわかり、システムの再最適化が必要であることが証明されました。

機能が更新されたTSはリーグに戻り、実行ファイルが再コンパイルされ、再びデモ取引に戻る。その性能を見てみましょう。

このシステムのテスターレポートを添付します。
ファイル:
 
Georgiy Merts:

そこで、約束通り、あるシステムを例にして、再最適化のプロセスを説明します。実際には、このような再最適化が毎日3〜5回、多いときには20回行われています。 しかし、すべては自動化されており、私は不測のエラーが発生しないようにプロセスをコントロールし、再コンパイルした新しいバージョンのリーグをUPUにアップロードするだけです。

スクリプトを実行すると、許容できない挙動を示したシステムのリストが作成されます。

まず、NZDJPY、443740、EMAFlatSP、Many SL (2)だとします。

これは、固定TP-SLと価格とスライドの交差によって示される、トレンドに逆らってインパルスでエントリーのTSです。TSが許容できない数のSLを連続で表示した(2個、履歴上ありえない)。

過剰最適化のために送信され、その結果、新しい初期化関数がファイルに書き込まれました。その「アクティブコア」はこのような形をしています。

また、制御パラメータ機能も生成されており、その「アクティブコア」は以下の通りです。

CUは、品質(Grail Ratio)が64%と低く、リーグの「平均」(LC_MEDIUM)の部類に入ることがわかります(好事家の売買品質を比較する)。

2年間の歴史の中で最大値幅の スリッページは5.18千の3桁ポイント、連続SLの最大回数は6回でした。年間平均価格再計算は3.689に過ぎず(これが取引品質を低く見積もる主な理由)、利益率は1.37であった。特集の最後にコメントを残していますが、そこには品質スコアの本質、つまりスコアの構成要素がわずかに見え隠れしています。例えば、同じ低反発でも15%しかないと試算されており、極めて低い水準です。平均して週に2.13回の取引が行われ、価格の最大更新は116日以内、1回の取引の決済は最大311時間待つ必要があります。

ちなみに、このTSが前回許したSLは1回のみであったことも特筆すべき点である。現在では6台まで増えています。このシンボルでは、市場が本当に大きく変化していることがわかり、システムの再最適化が必要であることが証明されました。

機能が更新されたTSはリーグに戻り、実行ファイルが再コンパイルされ、再びデモ取引に戻る。その性能を見てみましょう。

このシステムのテスターレポートを添付します。
だからいいんです、トレードが足りないんじゃないんですか?
 
Vladimir Baskakov:
だからいいんだ!というのは、ちょっと無理があるのでは?

物足りないかな?ここで、TCはもう十分だと判断したのだから、私が反論する必要はないだろう?デモに置いて取引させ、許容できない挙動を示したらすぐに、最適化されすぎてしまうのです。

私の経験では - テストで64%の品質は、非常に低い品質です。つまり、「降格寸前」の中堅どころで、そこで「勝負」させる......ということだ。