記事"連続的なウォークフォワード最適化（その7）。オートオプティマイザの論理部分をグラフィックスでバインドし、プログラムからグラフィックスを制御する"についてのディスカッション

新しいコメント
 

新しい記事 連続的なウォークフォワード最適化（その7）。オートオプティマイザの論理部分をグラフィックスでバインドし、プログラムからグラフィックスを制御する はパブリッシュされました:

この記事では、オートオプティマイザプログラムのグラフィカルな部分と論理的な部分の接続について説明します。 ボタンクリックから最適化マネージャへのタスクリダイレクトまで、最適化の起動プロセスを考慮します。

既に述べたように、ViewModel はアプリケーションのグラフィカルな部分とロジックのソフトウェア実装の間のコネクタです。 アプリケーションの論理部分のコールバックに対するアプリケーションロジックの呼び出しとグラフィックスの反応を実装したプログラムのグラフィックス表現です。 したがって、ViewModel部分のパブリックプロパティは、アプリケーションのグラフィカル部分の各編集可能フィールドに対応します。 プロパティは、ゲッター（この場合はグラフィックから変更できません）か、セッター（このプロパティの背後に隠されたオブジェクトを上書きすることができます）のどちらかになります。 これまでのパートでは、すでにデータバインディング技術について詳細に検討してきました。 そこで、ここでは例を挙げてみます。 

テキストフィールドは、書き込みと読み取りの両方のアクセス権を持つプロパティを使用して接続されています。 例として、最適化を実行するアセットの名前を示すフィールドを考えてみましょう。 このフィールドのXAMLマークアップはシンプルです。

    
<TextBox Width="100"
         IsEnabled="{Binding EnableMainTogles, UpdateSourceTrigger=PropertyChanged}"
         Text="{Binding AssetName}"/>

テキストウィンドウの幅を設定するだけでなく、IsEnabledとTextというフィールドも持っています。 最初のは、そのフィールドが編集可能かどうかを設定します。 trueに設定すると、編集可能なフィールドになります。 falseの場合、フィールドはロックされています。 "Text"フィールドには、このフィールドにインプットされたテキストがあります。 そして、それぞれの反対側に巻き括弧での構築があります。 その内容は、"Binding "パラメータの後に指定されたViewModelクラスの特定のパブリックプロパティとオブジェクトの接続を設定します。

作者: Andrey Azatskiy

 

プログラマーとしてのレベルの高さをあらためて証明した。いわば、もう少しユーザビリティを高めれば、もっと人気が出る。このような記事を理解するためには、それに見合った時間を執筆に費やす必要がある。あなたのオプティマイザーをkodobaseにコードと使用説明書だけ載せてくれませんか？おそらく、より多くのトレーダーの目に留まるでしょう。

カスタム・オプティマイゼーションの基準は まだ出ていないようですし、カレンダーの高さも......。OnTester()は強制的に使用されるのだから、カスタム基準だけで十分ではないか。そしてもう一度、テスト期間の入力の自動化について考えたい。私の実践によると、テスト・フォワードの最適化は、3～5週間の期間を複数の商品で実行するのがよいようです。各楽器のすべての期間を手作業で書くのは、気の弱い人には向かない。MQL5ツールを使ってスクリプトを作成し、期間を受信して出力することは難しくありませんが、サンドボックスとフォーマットの制限により、手作業でAuto-Optimiserに転送する必要があります。プログラムの機能でそれを行うことができます。個人的には必要ないかもしれませんが、誰のためにこのような大規模で複雑な記事を書いたのでしょうか？

オート・オプティマイザーの信頼性の高い動作は、よく知られたアナログ製品に対する利点ですが、設定の複雑さは欠点です。しかし、マニュアルがあります。

 
Good Beer:

プログラマーとしてのレベルの高さをあらためて証明した。いわば、もう少しユーザビリティを高めれば、もっと人気が出る。このような記事を理解するためには、それに見合った時間を執筆に費やす必要がある。あなたのオプティマイザーをkodobaseにコードと使用説明書だけ載せてくれませんか？おそらく、より多くのトレーダーの目に留まるだろう。

カスタム・オプティマイゼーションの基準は まだ出ていないようですし、カレンダーの高さも......。OnTester()は強制的に使用されるのだから、カスタム基準だけで十分ではないか。そしてもう一度、テスト期間の入力の自動化について考えたい。私の実践によると、テスト・フォワードの最適化は、3～5週間の期間を複数の商品で実行するのがよいようです。各楽器のすべての期間を手作業で書くのは、気の弱い人には向かない。MQL5ツールを使ってスクリプトを作成し、期間を受信して出力することは難しくありませんが、サンドボックスとフォーマットの制限により、手作業でAuto-Optimiserに転送する必要があります。プログラムの機能でそれを行うことができます。個人的には必要ないかもしれませんが、誰のためにこのような大規模で複雑な記事を書いているのでしょうか？

オート・オプティマイザーの信頼性の高い動作は、よく知られたアナログ製品に対する利点ですが、設定の複雑さは欠点です。しかし、マニュアルがあります。

コメントありがとうございます。記事の結論にも書きましたが、前回の記事で追加したものはすべて追加します。これは以前から予定していたものの一つです。私は、レポートをアップロードする部分から自動オプティマイザ自体の内部構造まで、プログラム全体を公開するすべての記事で説明しようとしました。約束した編集については覚えているし、すでに取り組んでいる。しかし、まずはプログラムの最初のバージョンの説明を完成させなければならなかったので、次の記事で公開するつもりだ。
。コードについては、記事に添付されているので、必要であれば変更したり、分解したり、モダナイズしたりすることができます（私は約束した編集をしますし、もしあなたがもっと個別的なものが必要であれば、オプションとして追加したり、興味があればただ作業したりすることもできます）。自動ピリオド分割を追加します。

新しいコメント