ライブラリ: MT4Orders QuickReport - ページ 6

新しいコメント
 
Forester #:

最大ロング・ドローダウンに関する情報は興味深い。文字列の配列全体に対して作ったんだ。
しかし、何のための日付なのかがよくわからない。もし（私が提案したように）バックテストとフォワードテストに分割するポイントを作るなら、2つのテーブルで別々に統計情報を計算する必要がある（最大ドローダウン期間もそこにある）。

バックテスト/フォワード テストの統計の完全な計算を作成した
。

ファイルを更新しました。
 
Forester #:

日付がはっきりしないのは、それが何のためなのかということだ。

2020年以降を見たいのであれば、どうぞ。2023年からでも構わない。ただ、2010年のことは気にしないということもある。そして、最も長い期間は2010年であることを示している。
 
fxsaber #:
2020年から観たいなら歓迎する。2023年からでも問題ない。ただ、2010年のことは気にしないということもある。そして、2010年が最長であることを示す。
なるほど。一人の専門家／戦略を持つテスターのためではなく、異なるアイデアがテストされた実際の口座のためだ。

フォワード・デートを設定すれば、統計を分けるのに役立つだろう。

 
Forester #:
ああ、言いたいことはわかった。1人の専門家／戦略を持つテスターのためではなく、さまざまなアイデアがテストされた実際のアカウントのためだ。

私自身はテスターにしか使いません。実際のドローダウンはまったく面白くない。

 
Forester #:
何が悪い？

潜在的に危険なスタイルだ。例えば、後日、独自のカスタム日付フォーマット関数を書きたくなり、その呼び出しが習慣的に超超長い1行で書かれることになる：

Print("From " + TimeToString(From[i], TIME_DATE) + " MaxLengthDD = " + (string)(MaxLengthDD(BeginDD, EndDD, From[i]) / (25 * 3600)) + " days: " + Format(BeginDD) + " - " + Format(EndDD));

しかし、Format-idsがMaxLengthDDの後に呼び出される保証はない。

原則的に、1行の超長いレコードには負の側面がある：読みにくく、理解しにくい（実際、コンパイラが行うように式の解析を頭の中で繰り返すのは難しいが、結局のところ人間はコンパイラではない）、デバッグしにくい。また、このようなコンパクトな記録は、パフォーマンスの向上にもつながらない。

 

スーパー図書館！作者に感謝！

改善提案:
- インタラクティブ・チャートを再度クリックすると非表示にする(または別の仕組みを追加する),
- ソースをUTF-8で保存し、GitHubで正常に読み込めるようにする(これは1回限りのイベントで、何も脅威にはなりませんが、利便性が向上します)
- ファイル名に禁止文字がないかチェックする( \ / / * ?" < > | : :) がないかチェックし、中立的な文字 (- など) に置き換える
- レポートを端末の 共通フォルダに 保存するパラメータを追加し、エージェントのフォルダから探さなくても済むようにする。


とても便利なツールです！

 
Andrey Khatimlianskii 端末の 共通フォルダに 保存するパラメータを追加する。


非常に便利なツールです！


呼び出しに2つの新しいパラメータを追加
void QuickReport(string file_name, bool is_open_file_in_browser=true, int virtual_number=0, bool hide_account_and_name=false, bool common_path=false, bool fileANSI=true){...}
common_path - 共通のターミナルフォルダに保存します。最適化中に他のエージェントによってファイルが上書きされないように、ファイル名にエージェント番号 (3000, 3001,...) を追加しました。
fileANSI - ANSIエンコーディングまたはUNICODEで保存します。UNICODEファイルのサイズは2倍大きく、処理に時間がかかるため、例えば1GBのような大量のデータをアップロードする場合は、ANSIを使用した方が経済的です。UNICODEが必要な場合は、サードパーティのサービスとの互換性のために追加されます。

文字チェッカーと非表示ボタンも追加されているが、説明は省略した。
 
Forester #:
呼び出しに2つの新しいパラメータを追加
このように新しいパラメーターが追加される。そのため、シグネチャーを一度書いて、そこに条件の構造を入力するのがよい。そうすれば、シグネチャが変わることはない。レポートではそのようにした。
 
fxsaber #:
こうして新しいパラメータが追加されていく。そのため、シグネチャーは一度、条件の構造が入力されるように書いた方がいい。そうすれば、シグネチャーが変わることはない。レポートではそうした。
おそらくその方がいいのだろう。しかし、誰かがコードを編集する必要がないように、ライブラリを使用する既製のプログラムとの互換性のために、現在の呼び出しの方式を維持する必要がある。
 
Forester #:
おそらくその方がいいだろう。しかし、誰かがコードを編集する必要がないように、ライブラリを使用する既製のプログラムとの互換性のために、現在の呼び出しスキームを維持することはすでに必要なことだ。

オーバーロードはその助けになるだろう。

12345678910
新しいコメント