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

新しいコメント
 
Roman Shiredchenko:

厳しいな...。:-)

ビリビリした後にそこそこ可能性がある、Equityとup!!!!!!!

下がり始めたら、そうですね。もちろん、あなたはよくご存じでしょうが...。これからも見守りましょう...。

可能です。

でも、2年連続でそうなっていないんです。私たちは、「フライトアップ」を待っているのでしょうか？確かに可能性はありますが、「飛び出す」可能性の方が大きいと私は思います。

 
Georgiy Merts:

言い間違えました。

私が言いたかったのは、0.8日レンジの損切り後-6回トレードした後は、高値更新を待ちすぎているので、トレードからの撤退があるはずだということです。

その通りです。

例643642を考えてみましょう。最適化の間、大きな損失はなかった（0.6レンジ以上の損失はなかった）。

取引 中は、0.6を超える損失が容易に 発生します（実ティックのドローダウンで確認できます）。レンジの0.6を超える損失が発生した場合、TSが修正される機会を奪ってしまうようです。そして、これは論理的ではないのですが、それはまた、実際のティックでの実行で見ることができます。この損失は、システムが儲からなくなったということではなく、単にOHLCでモデル化されていないだけなのです。 TSが大きな損失を出すと同時に、上限更新不可により自動的に取引から外されることが判明した。

TCを一ヶ所で踏むことと、負けた後の修復をどうにか分けて考えるべきだと思います。例えば、nトレードの平均収益率という基準を導入する。

実時刻を用いた最適化後のチェックは、TSの動作の潜在的な側面を理解するのに有効かもしれないということには、まだ同意されないのですか？

 
Eduard_D:

その通りです。

例643642を考えてみましょう。最適化の際には、一度も大きな損失はなかった（0.6レンジ以上の損失はなかった）。

取引 中は、0.6を超える損失が容易に 発生します（実際のティックで確認できます）。そのため、0.6以上のレンジロスの場合、TSから勝機を奪ってしまうことになります。そして、これは論理的ではないのですが、それはまた、実際のティックでの実行で見ることができます。この損失は、システムが稼動しなくなったということではなく、単にOHLCでモデル化されていないだけです。 TSが大きな損失を出すと同時に、上限更新不可により自動的に取引から外されることが判明した。

モデル化されていないため、取引から外さなければならない。

取引から外した主な理由：システムが履歴上の振る舞いをしない。テスト時に考慮しなかったこと、市場が変化したこと、アルゴリズムに誤りがあったことなど、理由は問わない。

もし、システムを取引から外すことになった損失が偶発的なものであったとしても、一日のうちにシステムは再最適化され、再最適化の結果は実際の取引よりも確実に良くなり、すぐに以前と同じ結果を示すようになるのです。 そして部門は重要ではありません、レポートのための統計情報を収集するスクリプト - すべての部門のためにすぐにそれを収集しますが、ミドルまたはローワー部門のTSがトップ部門での貿易の質を示すために開始するとすぐにので、もちろん、トップでトップ部門からTSのみを取得すること - それはすぐにそれに転送されます。

つまり、まさにこのTSがエドワードさんにとって高価なものであるならば、失うのは最大で10ディールということになるのです。6」であることを考えると、ひとつひとつの取引は非常に小さい。まあ、最適化しすぎた結果、TSがそのままトップディビジョンになった時には、興味のある方にお知らせするのを忘れないようにしたいと思います。

現在、高等部には90のTCが取引されています。

 
Eduard_D:

踏ん張ることと、負けた後のリカバリーをどうにか分けて考えることが必要だと思います。例えば、nトレードの平均的な収益性の基準を導入することによって。

分離されているのでは？

いいか、我々は丸2年かけてシステムがどのように機能するかをテストしているんだ。そして、最も長い回復期間を取ります。実際の取引でTSの回復に時間がかかるようであれば、それはTSが意図したとおりに動作していないことを示す明確なサインです（繰り返しますが、理由は私たちには重要ではありません）。

 
Eduard_D:

あなたはまだ、実際のティックでの最適化後のテストが、TCの動作の隠れた側面を理解するために有用であることに同意していないのですか？

意味がわからない。結局のところ、そこにあったものは二度とないのです。

しかし、自分でやることは誰も止めない。制限のないTCであれば、REGコードなしでテスターで動作します。

 
Georgiy Merts:

このコードについて、ログにはどのように書かれていますか？無効ですか？

確認したところ、すべてうまくいっているようです...。

あえて言うなら、REGコードではないでしょうか。

ここにいます。

ここでクラッシュです。


レジストレーションコードと書いてある

口座番号：2599118
マジック：542041

RegCode: 3265001878


 

置く

チックの登場により、それがなくなりました...。



ログはこちら


 

ローマン、マジコンに悪態ついてます。542041のビルドデートは2019.06.12です。 お客様の実行ファイルは6月の日付になっています。私の推測では、この実行ファイルが作成されたときには、まだ542041は存在しなかったと思います。

新しいモジュールを入手すれば、うまくいくはずです。

 
Georgiy Merts:

意味がわからない。結局のところ、そこにあったものは二度とないのです。

では、履歴を最適化する意味はあるのでしょうか？

もし技術的に可能なら（時間的に）、私はすべてをリアルティクだけで最適化します。

 
Eduard_D:

ローマン、マジコンに悪態ついてます。542041のビルドデートは2019.06.12です。 お客様の実行ファイルは6月の日付になっています。私の推測では、この実行ファイルが作成されたときには、まだ542041は存在しなかったと思います。

新しいモジュールを入手し、動作するはずです。

OKです。試してみます。他のもの（3個）は問題なくインストールできたのに・・・。

口座番号：2599118
マジック：442042- 良い 。

RegCode: 966523303

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

口座番号：2599118
マジック：443122- 良好 です。

RegCode: 446429648

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

口座番号：2599118
Magic: 542041- No.

RegCode: 3265001878.

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

ここTC magic 443122 - 何かが硬い...。:-)

何か脅威を感じるかもしれない...。:-)


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