IBM, 7800 bars, to 1999/12/31 (Omega has no start date of period, has end date and number of bars)
Testing on daily bars by Close bar (by Open Omega does not do) Stops, toes and trailing in code made by pending orders, as Omega inside bar does not work otherwise and data only have daily bars.これは、オメガが日足バーでテストしているためです。
....しかし、なぜこれだけ広いスペースに1000本しかオーバーシュートがないのでしょうか？ とても荒削りです。MT4でこのExpert Advisorを15億の値の領域で実行したところ、18000のEURUSD H1バーの履歴で4分以内に4400の純反発が発生した。 ....
ターゲット関数の品質（フィットネス）に依存する。
- max NetProfit
- NetProfitの最大値とDDの最小値
- 最大NetProfitと最大PF
- 他に何か？
あなたのコードには、そのようなターゲット関数が見当たりませんでした。最適化パラメータはこんな感じです。その上、我々が知っている他のアルゴリズムよりも一桁以上速いオリジナルのアルゴリズムを使用しています。
100～200本というのは非常に疑問です。どのような母集団が使われているのか 16?:)広い探索領域から始めると、初期推定で256個の母集団で第一世代で256個のオーバーシュートを簡単に得ることができます。 これは最も汚いバリエーションです。これって、（最初の人口を実行して停止する）ってこと？巨大な亜種のフィールドで100～200回走った結果を信じるのか？そんな汚い結果が必要なのか？1000回の実行は少し多すぎます。私は通常、100～200回の実行で（パラメータの数に関係なく）ソリューションを評価します。
このスレッドの最初のページにあるあなたの初期条件で198 buildのMACD Sampleを実行したところ、以下のような結果になりました。
350億のオーバーサンプルの検索領域から、「始値による」モードで18691本のバーの履歴に対して、12800回の実行が8分46秒で行われました。ベストケースレポートを添付します。
さらに、不整合なデータ（すべてZIPファイル内の御社のレポートから）についての質問も多くあります。利益や取引回数 などは、TSGOのレポートのデータには全く及ばない（レポートの最後のページにあるように、880本で作られたXLSファイル）。
また、TakeProfitが80pipsで、トレーリングストップが6700なのはなぜですか？
これについては、どのように説明しているのでしょうか。あなたのテストは、どうにもこうにも考慮できないほど欠陥があるようです。
根拠・説明がシンプルでわかりやすく、こんな質問をしなければならないほど混乱するものであってはならない。何も表示されないスクリーンショットと、整合性のないデータのアーカイブは、それを理解するのが面倒な人たちのための証拠です。
ただ、その場ではよくわからないかもしれない・・・。
その結果を説明しよう。
1.最適化の基準は 任意でよい。
(ターゲット関数について)
ユーザー自身が計算し、TSGOに渡される。
つまり、自分が持っているものと、ユーザーが考えたものの両方を使うことができるのです。
例えば、期待ペイオフを基準にすることができます。
(すなわち、正の期待ペイオフを持つディールの確率、言い換えれば、システムがプラス側に働く)
. または、エクイティの線形性を記述するいくつかの基準 (Walk Forward Optimizationに似た問題を解決するのに役立つ) ...
最適化において重要な役割を果たすのが、最適化基準である。
(CurveFittingではなく、正しい結果を得るために)
2.最適化は、多くの基準に従って同時に行うことができます。
(対象機能について）
自宅にはTSGOの次期バージョンのプロトタイプしかないんです。
その中で、複数の最適化条件を同時に設定することができます（TS.GO.Criterion(...)関数参照）。
ビューアのテーブルの例では、使用される基準が黄色の背景で強調されています - それらはNetProfit、MaxDD、ProfitFactorです。
つまり、TSGOはこの3つの基準の最大値（OmegaのMaxDDはマイナス記号）付近のシステムを探したのです。
つまり、彼は利益が大きく、ProfitFactorが大きく、DrawDownが最小のシステムを探したのです。
興味深い結果は、各年（または月）のNetProfitを最大化すると同時に、
、すなわち履歴上の各年、あるいは各月に良い結果を持つシステムを探すことができます。
(TSGOの最適化基準は1000まで設定可能、実際にはこれまで150～200程度試した - これはMSFTのNetProfit by months）
3.母集団のサイズは1000枚までです（もっと増やせますが、無理があるようです）。
(100～200本というのはかなり疑問です。では、どのような母集団が使われているのでしょうか。16?:))
この例では、100だったと思います（TS.GO.Popul(...)のパラメータ値を参照してください）。
私は通常、50～100、時には1000の人口を使います。
一般的にこれはほとんど効果がなく、常に1000に設定すれば、検索速度にほとんど影響を与えません。
結果は、1000人の母集団で500回実行しても、非常に正確である...。:))
また、私は独自のアルゴリズムを使っていると書きましたが、これはインターネット上では今のところ何も見当たりません。
私が知っている（そしておそらくあなたも使っている）他のすべてのアルゴリズムよりはるかに高速です。
その中の人口の大きさは関係ない（小さすぎなければ）...。
これは（最初の母集団を実行して停止する）意味でしょうか？
さすが、私の場合は効き目が違いますね。
巨大な亜種のフィールドで100～200回走った結果を信じるのか？
さらに、CSの結果は、パラメータ空間の変種の数に依存しないと確信しています。
そんな汚い結果が必要なのか？
ごちゃごちゃしていないし、それなりに十分です。
CSで正確な結果が得られる保証はない。
正確な結果を得るためには、完全なオーバーシュートを行うしかないのです。
つまり、常に推定値、つまりおおよその結果を持っているのです。
私のアルゴリズムは、ほとんどの場合、100〜200回の実行で早々に良い推定値を得ることができます。
350億回の検索領域のうち、12800回の実行が行われた
私のアルゴリズムでは、2000回の実行で十分すぎるほどであった。
残念ながら、あなたのレポートはMetaTraderのようにシンプルで指標となるものではありません。オメガ社から母集団ラン番号880のXLSレポートファイルを投稿されましたが、この880ランの検出パラメータの記述はどこにもありません（XLSレポート自体にも、TSGOレポートにも、このスレッドのスクリーンショットにもありません）。
どうすればいいのか．
もしオメガリサーチ社が私たちのTSGOを買ってパッケージに組み込んだとしたら、あなたのようなチェックボックスだけになってしまうでしょう。
しかし、今のところTradeStationのAdd-Onに過ぎない。
結果はすべて正しい。
ラン880は、オメガによれば（NetProfit基準で）ベスト、
、TSGOによればベストではない（NetProfit、MaxDD、ProfitFactor基準で同時に）
TSGOは、サイクルバイパスの編成にのみオメガを使用しています。
また、Omegaで利用可能な任意の基準を選択することができ、TSGOの動作に影響を与えることはありません。
TSGOは、ユーザーがシグナルコードで指定した条件に基づいて最適化を行います。
オメガで取得したランの数も関係ない。
最適化が完了すると、ビューワの1行目からインスタンスに対する結果が表示されます。
また、不整合なデータ（すべてZIPファイル内の御社のレポートから）には、多くの疑問があります。利益や取引回数などは、TSGOレポートのデータには全く及ばない（XLSファイルはレポートの最終ページに記載されているラン880用に作成されています）。
そう、その感覚を得ることができます。あなたは私の例を解析して、本当に素晴らしい仕事をしましたね ...:))
ここで少し説明が必要です。
ポイントは、TSGOがOmegaの1つの機能を使って、見つかったベストなシステムを報告していることです。
最適なシステムはビューアーの1行目、そのパラメータを代入すると、レポートと完全に一致した結果が得られます。
Omegaは、その基準に従ってシステムを検索します（私たちはどれを気にしません）。
TSGOは、ユーザーによってシグナルに設定されたその基準に従ってシステムを検索します。
最適化処理中、OmegaはGenパラメータを1からKに変更します（これはOmegaに設定されている最適化パラメータです）。
Genの値がTSGOに送信される。
Genが増加した場合、TSGOは新しい候補のパラメータを出力し、実行結果をテストする。
Genが増加しなかった場合、TSGOは最適化が終わったと見なします（Omegaはその意見で最良の結果を再計算します）。
この場合、TSGOは（ビューアの最初の行から）最良の見つかったインスタンスのパラメータを出力します。
一般に、最適化が完了すると、Omegaレポートには、ビューワの1行目からインスタンスの結果が表示されます。
両者のパラメータを比較すると、まったく同じである。
これらはすべて、TSGOがOmegaのAdd-Onであり、Omegaの一部ではないからです。
それ以外に方法はない。
=============================================
レナート、これは絶対に本物のデータであり、その中のすべてが正しいことを保証します。
私たちはOmegaの開発者ではないので、Omegaの内部でオプティマイザを構築することができないため、混乱が生じています。
巨大な亜種のフィールドで100～200回走った結果を信じるのか？
信者になるのはやめましょう。この再集計について、あなたの主張を証明していただけませんか。さらに、CSの結果はパラメータ空間の変種の数に依存しないことも確かです。
結果はすべて正しい。
だからラン880はオメガによるとベストです（NetProfit基準による）。
しかし、TSGOによるとベストではありません（NetProfit、MaxDD、ProfitFactorの基準で同時に）。
- 880で見つかったベストランパラメーターが記載されていません。
- 黒は白」と言いながら、アドオンの特殊性で正当化するのか
- 不正確なオメガレポートを故意に送信した場合
- 1000回実行した結果を得るためにどのようなターゲット関数を使ったかを正確に示さず、「これでもか、これでもか」というモードになっている（プログラマは自分でコードの中に基準を設定できる-この基準をELコードで示せ）。
確認しないでください。数字やレポートで証明したほうがいい。球形真空中の馬」のレベルで問題を解決する分野に無理矢理にでも移動させてくれた（ありがとうございます）、移動して問題を解決したのです。しかし、何一つ解決していないばかりか、間違った報道で私たちを惑わすことさえしています。このスレッドの最初から、あなたが先に証拠として挙げたものは、すべて言葉遊びの全くのナンセンスです。証拠はなく、ただ突拍子もない数字を並べるだけのゲームです。1970年から1999年までのIBM Dailyを（正確には1970年初頭から1999年初頭まで）、上記の（正確には彼らの）限界値を実行し、そのようなレポートを、クレームのないように公表していただけませんか？そして、私のを公開します。
そして、なぜいつもここで言い訳をしなければならないのか？
退会してほしいなら、お願いします。
ここも禁止にしてくれ、もっと仕事して邪魔にならないようにする。
理解できないことがあっても、それは嘘をつかれたということではありません。
理解してないってだけで、礼儀正しい社会では
は、わからないことを説明しろと言わんばかりです。
人は通常、自分自身で他人を判断する。
私は、フォーラム参加者の誠実さを一度も疑ったことはありません。
(あなたと違って・・・）。
順番にお答えします。
1.ある記事で私はこう書きました。
さらに、私たちが知っている他のアルゴリズムよりも一桁以上速いオリジナルのアルゴリズムを使用しています。
1000回の実行は少し多すぎます。解の推定には、通常100～200回の実行を使います（パラメータの数に関係なく）。
答えてくれましたね。
あなた自身は、膨大なバリエーションのフィールドで100～200回走った結果を信じているのでしょうか？
信仰を持たないでください。この再計算について、あなたの言葉を証明していただけませんか。また、CSの結果は、パラメータ空間の変種の数に依存しないと確信しています。
---
何を証明すればいいんだ？
その「（パラメータの数に関係なく）通常100～200回のランを使用する」？
そして、そのような結果は十分に信頼に足るものであると私は考えているのですが？
それは私の意見であり、なぜ私がそれを証明しなければならないのか？
そう思わないか？- それはあなたの権利です。
"そんなことはない "と言えばいいんです。
同じテーマでも、2つの意見があることになります。
2.880のランで見つかった最適なパラメーターのリストが示されていません。
880の走りは、TSGOの面では最高とは言えません。
と、もはや人口に膾炙しているかもしれません。
ベストランは919で、TSGOビューアーの1行目に表示されている。
オメガのレポートにも出てくるやつですね。
比べてみてください。
ビューアでは、1行目。
Gen＝919（これはランの番号です）
トレード数＝52
NetProfit = 29312.07
MaxDD = -4939.19
PF = 7.42
オメガの報告書では
純利益の合計＝$29,312.07
総取引数＝52
日中の最大ドローダウン = ($4,939.19)
プロフィットファクター＝7.42
なぜオメガが880番を作ったかは、以前のメッセージに書いたとおりです。
3.あなたはオメガから偽のレポートを送ってきました。
わざと嘘の報告書を送ったオメガさん、もっとよく見てください。
4.1000回の実行結果を得るために使用したターゲット関数が正確に指定されていません。
すでに前回の記事で書きましたが、NetProfit、MaxDD、ProfitFactorの3つの基準で同時に最適化を行いました。ビューアーでは、黄色い背景でハイライトされています。
Easyのシグナルコードでは、TS.GO.Criterion関数で定義されています。
以下は、コードスニペットです。
R = TS.GO.Method(1); -- 多基準の最適化を可能にする。
R = TS.GO.Criterion("NetProfit",1); -- 第一基準
R = TS.GO.Criterion("MaxDD",1); -- 第二の判断基準
R = TS.GO.Criterion("PF",1); -- 第三の基準
基準値は、コードの最後のバーで割り当てられる。
R = TS.GO.Set("NetProfit",NetProfit);
R = TS.GO.Set("MaxDD",MaxIDDrawDown);
R = TS.GO.Set("PF",GrossProfit/(0.001-GrossLoss));
あなたの攻撃に耳を傾ける気は毛頭ありません。
話をするのであれば、対等な立場で話をする必要があります。
あなたはそう思いますか？
では、あなたの主張を証明してみてください。
1.あなたは意図的に虚偽の報告をオメガに送りました。
2.どのターゲット関数を使用して結果を得たのか、正確に示されていません。
3.しかも、自分では何一つ解決していない上に、間違った報道で誤魔化してるんですよね。
4.このスレッドの最初から、あなたが先に証拠としてあげたものは、すべて言葉遊びの全くのナンセンスです。(これは単なる主張ではなく、すでに侮辱である）。
5.根拠はなく、ただ突拍子もない数字を並べただけのゲームです。
私は、言葉遊びの領域から、あくまでも実践的なレポートの領域へ移行することを提案し続けています。前回は、再度問題解決を提案しました。それを解決して、文句のつけようのないレポートを公開できるか？
この作業の後、巨大な分野の変種について100〜200回ほど実行すれば十分であるという発言にスムーズに移ることができるのです。
オメガのランナンバーには、たったひとつだけ誤解があった。
次の記事で、これがどういうものかを詳しく説明しました。
巨大な変種変量場で100～200回ほど走れば十分な程度。
私は発言や主張をしていない。
文字通り、次のように書きました。
...私は通常、解を推定するために100-200回（任意の数のパラメータに対して）実行します。
推定」と「充足」の違いを理解していますか？
特に、レポートやプルーフに関しては、私が普段からお願いしているように、わかりやすく、シンプルなものです。著者のコメントを最大1行ずつ添えたコンピュータ・レポートが必要です。
二言で説明してもいいのですが、それがわからないと、何キロも長い記事を書かなければならないので．
この課題の後...
そして、あなたは私に課題を 与えるために私を雇ったのですか？
私は、あなたがあなたの結論を 証明するのを待ち続けています。
もし、あなたがとんでもない技術的な主張をしているのなら、それを証明するくらいの親切心が必要です。
すでに100～200本で対応し、（「推定」とはいえ）絶対的に汚い結果になった（すぐにそう言ったが、納得いかなかったのか）。そして、プレッシャーの中でしか認めないようにしていたんですね。
私 は、突飛な技術的主張をすることはありません。
正確には、あなたにとっては圏外かもしれませんが、私にとってはごく普通の、働いているものです。
我々はすでに100～200本のランを扱っており、これらは（「推定」とはいえ）絶対に汚い結果であることがわかりました（私はすぐに言いましたが、あなたは同意しませんでしたね）。そしてそれは、プレッシャーの中でしか認めないことでした。
絶 対に汚い」というわけではなく、かなり実用的な結果です。
それに、私はプレッシャーに負けて何も承諾していません。
ずっと同じことを言っているのだから、もう一度言ってもいい。
特にあなた には、
オメガで別の最適化を実行しました。
最適化の基準として、NetProfitという 1つだけを残して、簡単にできるようにしました。
オメガも同じ基準で判断しています。
合計で1000本ありました。
IBM, 7800 bars, to 1999/12/31
(Omega has no start date of period, has end date and number of bars)
Testing on daily bars by Close bar (by Open Omega does not do)
Stops, toes and trailing in code made by pending orders,
as Omega inside bar does not work otherwise and data only have daily bars.これは、オメガが日足バーでテストしているためです。
添付ファイルに
@Renat.txt- ELシグナルコード。前回と異なり、基準が1つしか残されていない。
1000.XLS- Omegaシステムレポート（Omegaによるベストラン）
SOR.xls- Omegaテストレポート（全ラン）
TSGO-1000.CSV- TSGOにおける最後の集団の構成（集団サイズ100）。
R = TS.GO.Method(1);
R = TS.GO.Criterion("NetProfit",1); -- 第2パラメータ = 1 - 最大基準を探す
R = TS.GO.Criterion("MaxDD",0); -- 第2パラメータ = 0 - 基準による最適化は無効
R = TS.GO.Criterion("NetProfit",1) 。基準定義ブロックはシグナルコードで変更 されている。GO.Criterion("PF",0); -- 第2パラメータ = 0 - 基準による最適化は無効
ご注意
1. ビューアの最初の行は母集団の最初の行に対応し、Omegaの結果に対応するものです。
2. ビューアでのベストランの数は401、オメガでは948、SOR.xlsを 見ればこれらのランが同じ結果であることがわかる。TSGOは、繰り返されるマッチング結果を拒否します。
3. 最後の母集団の構成を見ると、最もよく見つかった結果はNetProfit1891.86（401回実行時）、213回実行の結果は1814.16、93回実行の結果は1796.40となっていることがわかります。つまり、93回目の結果は、1000回実行した後の最良の結果と5.3％異なっており、これは悪くない、良いNetProfitの推定と考えることができると思うのです。
以下はスクリーンショットです。