メタトレーダー5でのシンボルとデータフィード - ページ 11 1...456789101112131415161718...26 新しいコメント Vladimir Suslov 2015.04.25 08:08 #101 最大値の2つの偶数プラトーを含む別のテスト関数を追加します。z = abs(tanh(x) + tanh(y))X,Yを-20から+20までステップ0.1で変更した場合、完全な反復には160801回の反復が必要です。テストでは、両方のプラトーが1400回の反復で見られ、これは完全な探索の1％未満である。これをGAで動かす人はいるのでしょうか？比べてみると面白い。 Andrey Dik 2015.04.25 08:21 #102 event:最大値の2つの偶数プラトーを含む別のテスト関数を追加します。z = abs(tanh(x) + tanh(y))X,Yを-20から+20までステップ0.1で変更した場合、完全な反復には160801回の反復が必要です。テストでは、両方のプラトーが1400回の反復で見られ、これは完全な探索の1％未満である。これをGAで動かす人はいるのでしょうか？比べてみると面白い。GAで見ていないのですか？最適化された関数の2つの引数で作業しても、全く指標になりません。探索空間が小さいだけでなく、探索アルゴリズム自体の「悪い」性質が現れることがあるからだ。数式を少なくとも10個の引数を持つ形式に変換すると、アルゴリズムの正負の特性がすべて表示されます。 Vladimir Suslov 2015.04.25 08:30 #103 joo:GAで見るのではないのですか？最適化された関数の2つの引数で作業しても、全く指標になりません。探索空間が小さいだけでなく、探索アルゴリズム自体の「悪い」性質が現れることがあるからだ。数式を少なくとも10個の引数になるような形に変換する - アルゴリズムの正負の特性がすべて一度に表示されるようになる。これはGAではなく、スレッド内に記事へのリンクがあります。上記では、6つのパラメータを持つ例を掲載しました。パラメータをたくさん表示することの難しさ全体。もし、もっと多くのパラメータを持つ関数を提案されたら、私はテストを行います。 Andrey Dik 2015.04.25 08:42 #104 event:もし、もっと多くのパラメータを持つ関数を提案されたら - テストをしてみます。Y=a+bです。 のところです。a=Skin(x1, y1)+Skin(x2, y2)+Skin(x3, y3)+Skin(x4, y4)+Skin(x5, y5)となる。b=Skin(x6, y6)+Skin(x7, y7)+Skin(x8, y8)+Skin(x9, y9)+Skin(x10, y10)となる。スキン機能がどこにあるかは、もうお分かりですね。つまり、20個の変数があり、Y関数は非常に視覚化しやすいのです。この原理を使えば、引数の数が無限にある関数を作っても、可視化することができるのです。そしてそれに従って、最終結果は極限の既知の値に対してY*2/nとしてチェックされる（ここでnは引数の総数）。 削除済み 2015.04.25 09:04 #105 Laryx:また、「アンダーステア」では数十時間、「MT」では数ヶ月で完全なオーバーステアになるようなアルゴリズムの例を教えてください。 また、最適化ヒューリスティックよりも高速に完全探索を行うことも現実的である。MTにおける完全なブルートフォース攻撃は、独立した実行の集合として表現される。実際、最適化を1つの計算問題として考え、アルゴリズムによる最適化を適用することは常に可能です。 この方法では、ほとんどすべての計算がキャッシュされるため、パスの順序が非常に重要である。TCのほとんどすべての（すべて独立した）入力パラメータに対して、オプティマイザには常にグローバルバッファがあり、以前のパスの値を保存しています。 例えば、MA MAやPriceChannelを使用します。これらの指標は、それぞれ独立した入力パラメータを持っています。このため、各インジケータに対して、グローバルバッファを満たすための関数を規定します（実際には数行ですが、OOPではさらに美しくなるはずです）。そして、各指標の資源強度を比較します（PriceChannelはMAより重い）。重い指標の入力パラメータは外部ループ（最初のfor）で、単純な指標は内部ループ（ネストしたfor）で列挙され始める。 ここで大きな収穫を得ることができました。さらに、C++や整数計算、無駄なチェックをしない独自のオーダーシステムもあります。そうやって、結果を出していくのです。その結果、シングルランはMTに比べて少なくとも1桁以上高速化された。そして、その最適化は桁違いに速いのです。 MT-optimizerに欠けているのは、得られた最適化結果の 行列に完全にアクセスするためのOnOptimization機能である。そこで、得られたマトリックスに対して、フィルタリング、取引時間によって重複しない注文のパスの結合など、さまざまな分析を行います。しかし、さらに有用なのは、適切なポートフォリオの形でメタTSを構成するための、各パスに対する重み係数の計算である。これを実現するために、OnOptimizationは「絶望的」ではない各パスに対してvector-Equityを持っています。 しかし、アンダーテスターは、動作するTSを探す段階で発明されるのではなく、残念ながら既に見つかってしまった段階で発明される。検索そのものは、説明文なしという全く別のステージになります。 Sergey Chalyshev 2015.04.25 09:29 #106 event:誰かGAで動かしてくれないかな？比べてみると面白い。 Vladimir Suslov 2015.04.25 09:48 #107 joo:Y=a+bです。 のところです。a=Skin(x1, y1)+Skin(x2, y2)+Skin(x3, y3)+Skin(x4, y4)+Skin(x5, y5) となる。b=Skin(x6, y6)+Skin(x7, y7)+Skin(x8, y8)+Skin(x9, y9)+Skin(x10, y10)となる。スキン機能がどこにあるかは、もうお分かりですね。つまり、20個の変数があり、Y関数は非常に視覚化しやすいのです。この原理を使えば、引数の数が無限にある関数を作っても、可視化することができるのです。そしてそれに従って、最終結果は極限の既知の値に対してY*2/nとしてチェックされる（ここでnは引数の総数）。 こわいものみたさ）また、「機能Yが非常に可視化 しやすい」ことを説明できますか？ Vladimir Suslov 2015.04.25 09:49 #108 Serj_Che: 何回パスして、どの程度の可変ピッチで計算するのでしょうか？ Sergey Chalyshev 2015.04.25 10:19 #109 event: 何パスで、何ステップの変数で計算するのですか？絵が嫌いな人は気にしない？MT5の64bitGAは非常に優秀で、あらゆる問題を解決してくれます。このスレでGAについて語ってるのがどこのオタクかわからん。GAに問題があるのではなく、テスター自体が使い物にならないのだと思います。特に取引所では、間違った相場履歴の保存や自分の履歴の保存が不可能なため、使い物になりません。この問題が解決されればいいのですが、3～5年待たないといけないようです。 Georgiy Merts 2015.04.25 11:43 #110 zaskok: 例えば、MAやPriceChannelを使用します。これらの指標は、それぞれ独立した入力パラメータを持っています。したがって、各インジケータには、対応するグローバルバッファを埋める関数が書かれています（実際には数行ですが、OOPではさらに美しくなるはずです）。そして、各指標の資源強度を比較します（PriceChannelはMAより重い）。重い指標の入力パラメータは、外部ループ（最初のfor）で列挙され、単純な指標は内部ループ（ネストされたfor）で列挙され始める。何か、このやり方はGAでも簡単にできそうな気がします。作業量もほぼ同じです。インナーループ」は、どのパスでも通過している...。 しかし、最も重要なことは、それがどれほどの需要になるのか、ということです。おそらく、誰もが単純なカスタムOnTester() 関数を 使用するわけではありません。しかし、これは非常に強力な最適化ツールなのです。 例えば、私の実装の一つを紹介します。double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert){ ulong ulTickedTime = pmeExpert.GetTickedTime(); uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions(); double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT); double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT); double dProfit = TesterStatistics(STAT_PROFIT); double dNumOfTrades = TesterStatistics(STAT_TRADES); double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES); double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES); double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR); double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK; double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY; Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2)); Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1)); if(dNumOfTrades == 0) { Print("Ни одного трейда !"); return(-100000); }; if(dMaxNumOfSL > uiIMaxNumOfSeqSL) return(-10000 - dMaxNumOfSL*100 + dProfit/1000); double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades; if((bILongAllow == false) || (bIShortAllow == false)) dBarsPerTrade /= 2; if(dBarsPerTrade < MIN_BARS_PER_TRADE) return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor); Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1)); if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify) { Print("Слишком много СЛ подряд !"); return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000; }; Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1)); if(dBarsPerTrade > MAX_BARS_PER_TRADE) { Print("Слишком редкие трейды !"); return(dRecoveryFactor - dBarsPerTrade/100); }; Print("Profit: ",DoubleToString(dProfit,3)); Print("Profit per day: ",DoubleToString(dProfitPerDay,3)); Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL)); Print("Приемлемая торговля."); return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);};ここではリカバリーファクターに基づいていますが、最小限の連続したSLと、かなり頻繁なトレードで実行されることを強調しています。しかし、私が思うに、ほとんどの場合、標準的なオプションを使用しているのです。 Your symbols and your 最適化結果の視覚的評価 SQLite: MQL5 での SQL 1...456789101112131415161718...26 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
最大値の2つの偶数プラトーを含む別のテスト関数を追加します。
z = abs(tanh(x) + tanh(y))
X,Yを-20から+20までステップ0.1で変更した場合、完全な反復には160801回の反復が必要です。
テストでは、両方のプラトーが1400回の反復で見られ、これは完全な探索の1％未満である。
これをGAで動かす人はいるのでしょうか？比べてみると面白い。
最大値の2つの偶数プラトーを含む別のテスト関数を追加します。
z = abs(tanh(x) + tanh(y))
X,Yを-20から+20までステップ0.1で変更した場合、完全な反復には160801回の反復が必要です。
テストでは、両方のプラトーが1400回の反復で見られ、これは完全な探索の1％未満である。
これをGAで動かす人はいるのでしょうか？比べてみると面白い。
GAで見ていないのですか？
最適化された関数の2つの引数で作業しても、全く指標になりません。探索空間が小さいだけでなく、探索アルゴリズム自体の「悪い」性質が現れることがあるからだ。
数式を少なくとも10個の引数を持つ形式に変換すると、アルゴリズムの正負の特性がすべて表示されます。
GAで見るのではないのですか？
最適化された関数の2つの引数で作業しても、全く指標になりません。探索空間が小さいだけでなく、探索アルゴリズム自体の「悪い」性質が現れることがあるからだ。
数式を少なくとも10個の引数になるような形に変換する - アルゴリズムの正負の特性がすべて一度に表示されるようになる。
これはGAではなく、スレッド内に記事へのリンクがあります。
上記では、6つのパラメータを持つ例を掲載しました。パラメータをたくさん表示することの難しさ全体。
もし、もっと多くのパラメータを持つ関数を提案されたら、私はテストを行います。
もし、もっと多くのパラメータを持つ関数を提案されたら - テストをしてみます。
Y=a+bです。
のところです。
a=Skin(x1, y1)+Skin(x2, y2)+Skin(x3, y3)+Skin(x4, y4)+Skin(x5, y5)となる。
b=Skin(x6, y6)+Skin(x7, y7)+Skin(x8, y8)+Skin(x9, y9)+Skin(x10, y10)となる。
スキン機能がどこにあるかは、もうお分かりですね。
つまり、20個の変数があり、Y関数は非常に視覚化しやすいのです。この原理を使えば、引数の数が無限にある関数を作っても、可視化することができるのです。
そしてそれに従って、最終結果は極限の既知の値に対してY*2/nとしてチェックされる（ここでnは引数の総数）。
また、「アンダーステア」では数十時間、「MT」では数ヶ月で完全なオーバーステアになるようなアルゴリズムの例を教えてください。
この方法では、ほとんどすべての計算がキャッシュされるため、パスの順序が非常に重要である。TCのほとんどすべての（すべて独立した）入力パラメータに対して、オプティマイザには常にグローバルバッファがあり、以前のパスの値を保存しています。
例えば、MA MAやPriceChannelを使用します。これらの指標は、それぞれ独立した入力パラメータを持っています。このため、各インジケータに対して、グローバルバッファを満たすための関数を規定します（実際には数行ですが、OOPではさらに美しくなるはずです）。そして、各指標の資源強度を比較します（PriceChannelはMAより重い）。重い指標の入力パラメータは外部ループ（最初のfor）で、単純な指標は内部ループ（ネストしたfor）で列挙され始める。
ここで大きな収穫を得ることができました。さらに、C++や整数計算、無駄なチェックをしない独自のオーダーシステムもあります。そうやって、結果を出していくのです。その結果、シングルランはMTに比べて少なくとも1桁以上高速化された。そして、その最適化は桁違いに速いのです。
MT-optimizerに欠けているのは、得られた最適化結果の 行列に完全にアクセスするためのOnOptimization機能である。そこで、得られたマトリックスに対して、フィルタリング、取引時間によって重複しない注文のパスの結合など、さまざまな分析を行います。しかし、さらに有用なのは、適切なポートフォリオの形でメタTSを構成するための、各パスに対する重み係数の計算である。これを実現するために、OnOptimizationは「絶望的」ではない各パスに対してvector-Equityを持っています。
しかし、アンダーテスターは、動作するTSを探す段階で発明されるのではなく、残念ながら既に見つかってしまった段階で発明される。検索そのものは、説明文なしという全く別のステージになります。
誰かGAで動かしてくれないかな？比べてみると面白い。
Y=a+bです。
のところです。
a=Skin(x1, y1)+Skin(x2, y2)+Skin(x3, y3)+Skin(x4, y4)+Skin(x5, y5) となる。
b=Skin(x6, y6)+Skin(x7, y7)+Skin(x8, y8)+Skin(x9, y9)+Skin(x10, y10)となる。
スキン機能がどこにあるかは、もうお分かりですね。
つまり、20個の変数があり、Y関数は非常に視覚化しやすいのです。この原理を使えば、引数の数が無限にある関数を作っても、可視化することができるのです。
そしてそれに従って、最終結果は極限の既知の値に対してY*2/nとしてチェックされる（ここでnは引数の総数）。
何パスで、何ステップの変数で計算するのですか？
絵が嫌いな人は気にしない？
MT5の64bitGAは非常に優秀で、あらゆる問題を解決してくれます。
このスレでGAについて語ってるのがどこのオタクかわからん。
GAに問題があるのではなく、テスター自体が使い物にならないのだと思います。特に取引所では、間違った相場履歴の保存や自分の履歴の保存が不可能なため、使い物になりません。
この問題が解決されればいいのですが、3～5年待たないといけないようです。
例えば、MAやPriceChannelを使用します。これらの指標は、それぞれ独立した入力パラメータを持っています。したがって、各インジケータには、対応するグローバルバッファを埋める関数が書かれています（実際には数行ですが、OOPではさらに美しくなるはずです）。そして、各指標の資源強度を比較します（PriceChannelはMAより重い）。重い指標の入力パラメータは、外部ループ（最初のfor）で列挙され、単純な指標は内部ループ（ネストされたfor）で列挙され始める。
何か、このやり方はGAでも簡単にできそうな気がします。作業量もほぼ同じです。インナーループ」は、どのパスでも通過している...。
しかし、最も重要なことは、それがどれほどの需要になるのか、ということです。おそらく、誰もが単純なカスタムOnTester() 関数を 使用するわけではありません。しかし、これは非常に強力な最適化ツールなのです。
例えば、私の実装の一つを紹介します。
double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert)
{
ulong ulTickedTime = pmeExpert.GetTickedTime();
uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions();
double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT);
double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT);
double dProfit = TesterStatistics(STAT_PROFIT);
double dNumOfTrades = TesterStatistics(STAT_TRADES);
double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES);
double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES);
double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR);
double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK;
double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY;
Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2));
Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1));
if(dNumOfTrades == 0)
{
Print("Ни одного трейда !");
return(-100000);
};
if(dMaxNumOfSL > uiIMaxNumOfSeqSL)
return(-10000 - dMaxNumOfSL*100 + dProfit/1000);
double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades;
if((bILongAllow == false) || (bIShortAllow == false))
dBarsPerTrade /= 2;
if(dBarsPerTrade < MIN_BARS_PER_TRADE)
return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor);
Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1));
if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify)
{
Print("Слишком много СЛ подряд !");
return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000;
};
Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1));
if(dBarsPerTrade > MAX_BARS_PER_TRADE)
{
Print("Слишком редкие трейды !");
return(dRecoveryFactor - dBarsPerTrade/100);
};
Print("Profit: ",DoubleToString(dProfit,3));
Print("Profit per day: ",DoubleToString(dProfitPerDay,3));
Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL));
Print("Приемлемая торговля.");
return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);
};
ここではリカバリーファクターに基づいていますが、最小限の連続したSLと、かなり頻繁なトレードで実行されることを強調しています。
しかし、私が思うに、ほとんどの場合、標準的なオプションを使用しているのです。