eugenk1 писал (а): xeon、テスターは常時動作させることが可能です。もちろん、mql4ではなく、高度に最適化されたC言語で書かなければならないだろう。しかし、これには一つ重大な落とし穴がある。すなわち、システムの推定と最適化の期間である。つまり、どれくらいの期間、その性能を評価するのか？仮に、2つの戦略が実売買の権利を争っているとしよう。成功した現在のものと、最悪のもの。例えば1時間以内に、現在の戦略は損をし、逆にバックアップの戦略は成功した。問題は、戦略を変えるか、変えないか？結局のところ、これは新しいトレンド（トレンド／フリットと混同しないように！）の始まりであったり、偶然であったりするのです。つまり、このようなテスターは、少なくとも1つの（そして重要な！！）設定可能なパラメータ、評価と最適化の期間を持つことが判明したのです。そのようなやり方が不可能だと言っているのではありませんよ。全てにおいて難しいところ、曖昧なところがあると言うことです。
これまでのところ、私にはすべてがずっとシンプルに見えます。最小限の設定パラメータを持つ、シンプルで素朴なシステムから始めて、リアルタイムにパラメータを変更するブロックを追加する必要があります...。
これで、やることはほとんどなくなりましたね :) 適応パラメータを計算するために、どのデータを使うかを決める必要があります。何を提案したらいいのかもわからない :(
この点について、どなたかお考えがありますか？
まず、次のようなTCモデルを提案することができます。
我々は、単純なExpert Advisorを取り、それにブロック "テスター"（そのタスクになります書き込む - 1日1回例えば01:00 GMTで毎月の歴史の下でTSを調整するために）。
xeon、テスターは常時動作させることが可能です。もちろん、mql4ではなく、高度に最適化されたC言語で書かなければならないだろう。しかし、これには一つ重大な落とし穴がある。すなわち、システムの推定と最適化の期間である。つまり、どれくらいの期間、その性能を評価するのか？仮に、2つの戦略が実売買の権利を争っているとしよう。成功した現在のものと、最悪のもの。例えば1時間以内に、現在の戦略は損をし、逆にバックアップの戦略は成功した。問題は、戦略を変えるか、変えないか？結局のところ、これは新しいトレンド（トレンド／フリットと混同しないように！）の始まりであったり、偶然であったりするのです。つまり、このようなテスターは、少なくとも1つの（そして重要な！！）設定可能なパラメータ、評価と最適化の期間を持つことが判明したのです。そのようなやり方が不可能だと言っているのではありませんよ。全てにおいて難しいところ、曖昧なところがあると言うことです。
やっぱりシンプルにやってみよう。
課題：月次の履歴を1日1回実行し、ストップロスのパラメータに最適な数値を設定する関数を書くことは可能でしょうか？
この機能を使ってテスターをチェックすることはできますか？ テスターは全く動作しないのでしょうか？テストモードでは、毎日、新しい日の停止のパラメータを変更する必要があることが判明しました？ それは可能ですか？この課題が解決できれば、あとはもう言うことなしです。
xeon、テスターは常時動作させることが可能です。もちろん、mql4ではなく、高度に最適化されたC言語で書かなければならないだろう。しかし、これには一つ重大な落とし穴があります。すなわち、システムの推定と最適化の期間である。つまり、どれくらいの期間、その性能を評価するのか？仮に、2つの戦略が実売買の権利を争っているとしよう。成功した現在のものと、最悪のもの。例えば1時間以内に、現在の戦略は損をし、逆にバックアップの戦略は成功した。問題は、戦略を変えるか、変えないか？結局のところ、これは新しいトレンド（トレンド／フリットと混同しないように！）の始まりであったり、偶然であったりするのです。つまり、このようなテスターは、少なくとも1つの（そして重要な！！）設定可能なパラメータ、評価と最適化の期間を持つことが判明したのです。そのようなやり方が不可能だと言っているのではありませんよ。全てにおいて難しいところ、曖昧なところがあると言うことです。
やっぱりシンプルにやってみよう。
課題：月次の履歴を1日1回実行し、ストップロスのパラメータに最適な数値を設定する関数を書くことは可能でしょうか？
この機能を使ってテスターをチェックすることはできますか？ テスターは全く動作しないのでしょうか？テストモードでは、毎日、新しい日の停止のパラメータを変更する必要があることが判明しました？ それは可能ですか？この問題を解決すれば、あとはすでに言われているようにアイシングです。
私の知る限り、このような関数をmqlで書くことは可能ですが、私は「アマチュア・プログラマー」なので、この作業は簡単ではありませんし、時間が必要なのです。
自己調整型インジケーターは本末転倒。 自分の意見を正当化しようとする。
このような指標をいくつか開発しましたが、証券会社ごとに異なる相場の変動に敏感なようです。つまり、ある証券会社のデータでは問題なく動くが、別の証券会社のデータでは全く動かないという指標である。最悪なのは、TCのデータで動くことです。例えば、同じ気配値間隔の標準指標で、ある証券会社では乖離があり、別の証券会社では乖離がない。
私の研究では、ボラティリティがセルフチューニングの指標で考慮すべき代表的な要因であることがわかりました。しかし、最終的には、この指標は、異なる証券会社における相場のフィルタリング方法と、この方法の変更（証券会社から通知されない）に依存するようになります。
ここで私は、セルフチューニングが不連続ではなく、一定（リニア）であるため、（レナートがいつも言うように）「硬化」させることができないという事実にも直面することになりました。
ボラティリティの問題を回避するためには、指標や相場の絶対 値を無視するしかないと思っています。つまり、MTSで意思決定をするためには、何らかの形で値の相関関係を利用する必要があり、これは事実上パターン認識なのです。
それ
自己調整型インジケーターは本末転倒。 自分の意見を正当化しようとする。
このような指標をいくつか開発しましたが、証券会社ごとに異なる相場の変動に敏感なようです。つまり、これらの指標はある証券会社のデータではうまく機能するが、別の証券会社のデータでは全く機能しないということである。最悪なのは、TCのデータで動くことです。例えば、同じ気配値間隔の標準指標で、ある証券会社では乖離があり、別の証券会社では乖離がない。
私の研究では、ボラティリティがセルフチューニングの指標で考慮すべき代表的な要因であることがわかりました。しかし、最終的には、この指標は、異なる証券会社における相場情報のフィルタリング方法と、この方法の変更（証券会社から通知されない）に依存するようになります。
ここで私は、セルフチューニングが不連続ではなく、一定（リニア）であるため、（レナートがいつも言うように）「硬化」させることができないという事実にも直面することになりました。
ボラティリティの問題を回避するためには、指標や気配値の絶対値を無視するしかないと思っています。つまり、MTSで意思決定をするためには、何らかの形で価値の相関関係を利用する必要があり、これは本質的にパターン認識なのです。
どんなシステムでも、重要なのは価格値ではなく、価格変化のスピード（符号だけの場合もある）である。
価格加速度が使われることもある（価格に作用する力を推定し、先行指標とする）。
MTSで使用されるすべてのインジケータは、実際には速度を推定するために設計されています。
異なる指標は、速度を推定するための異なる選択肢に過ぎない。
1.すべてのオシレーターは速度を推定し、時には加速度を推定する（MACDのように）。
2.移動平均線 は単独で使用することはありません。
他の移動平均線（価格は長さ＝1の移動平均線）と比較した場合のみ。
この移動平均の比較（実際にはその差をゼロと比較する）がオシレーターである。
3.考慮すべきは価格ではなく、価格の対数である。
対数では、すべてがよりシンプルに、より正しくなる。
価格の変化が小さい場合は、価格と対数のどちらで作業しても差はありません。
大きな価格変動があれば、その差は大きくなります。
ちょっとヒントを出してもいいですか？:)
どんなシステムでも、重要なのは価格値ではなく、価格変化のスピード（符号だけの場合もある）である。
価格加速度が使われることもある（価格に作用する力を推定し、先行指標とする）。
MTSで使用されるすべてのインジケータは、実際には速度を推定するために設計されています。
異なる指標は、速度を推定するための異なる選択肢に過ぎない。
1.すべてのオシレーターは速度を推定し、時には加速度を推定する（MACDのように）。
2.移動平均線 は単独で使用することはありません。
他の移動平均線（価格は長さ＝1の移動平均線）と比較した場合のみ。
この移動平均の比較（実際にはその差をゼロと比較する）がオシレーターである。
3.考慮すべきは価格ではなく、価格の対数である。
対数では、すべてがよりシンプルに、より正しくなる。
価格の変化が小さい場合は、価格と対数のどちらで作業しても差はありません。
大きな価格変動があった場合、その差は大きくなります。
あるいは、あなたもコードを書くことに参加したいですか？あなたのプログラミングの経験があれば、もっと早くできるはずです。