定量戦略を開発するプロセスと考え方

Inventor Quantitativeの策略を書き始めたとき,おそらく多くの新規ユーザと同じだろう。 手を出せそうに感じて,そうだった。 書くことと詩を書くことは,まったく2つの概念である。 しかし,詩を書くためには,書くことが必要である。 プログラミングの基本を学ぶ必要があります. プログラミングの基本を学ぶ必要があります.送電ゲートこの記事の内容は,戦略を書くのに十分な内容で,短いものです.

• この記事では,この問題について説明します. 戦略を策定するプロセスはどんなものでしょうか? 簡単な手順は以下の通りです.

プログラミングは,その中の1つに過ぎませんが,重要な要素です.

- 1、建模：
    我的理解是，你的想法应该是一个靠谱的好主意（我想没人愿意付出大量精力去验证一个错误的IDEA）。所以这个好主意不是胡思乱想出来的。是通过观察市场现象、行为。数据分析，数学分析等一些科学的方法设计出的完善的逻辑、数学模型。并且要通过论证。
- 2、编程：
    这个过程就如同拿到设计图纸后造车一样。当然实际写的时候会遇到各种在 模型中 没有想到的问题，需要反复调整。经过这个过程你会深刻的体会到： “想的简单”这几个字，也会知道 策略 和 策略源码 之间的距离。
- 3、回测：
    必不可少的一步。此刻不管策略代码作者多自信，这个时候的策略代码也只是残次品。 还要经过 “回测” 这个大熔炉 锤炼。回测是在历史数据中，舒舒服服的测试。主要验证程序的基本逻辑，基本功能，验证策略的基本正确性、可行性。这个过程往往会发现一批明显的BUG。
- 4、实时行情的模拟交易：
    在明显的问题通过回测检验，排除后。回测结果接近预期的设计（至少是策略有可行性）。开始让策略程序接受实时行情模拟交易的考验。这个阶段依然会发现不少问题，这些问题更加隐秘、难以查找。所以该阶段DeBug需要认真。找错误是个基本功。（甚至我个人感觉DeBug功力比写代码还重要）。如果这方面经验不足、粗心大意，会导致一个BUG，没处理对（甚至没找到，但是误改了别的地方），进而产生更多的BUG，这种情况我经历过，说体验就两个字：“抓狂！”。
- 5、实盘测试
    终于迎来最残酷的实盘测试，策略程序要经得住实盘各种问题的摧残（网络异常，超时，交易细节问题，响应速度，容错机制 等等）。 有些问题藏得非常之深。要经过长时间的实盘测试才能体现出来。找出这些问题的根源也是需要一番功夫的。

一つの戦略には,上記のステップが必要である. 繰り返しテストは,全体のサイクルの大部分を占め,コーディングは,ほんのわずかな部分のみである.

• 経験:

  • 1. 私は,最初の戦略を書いているときも苦しめられていました. そして,通常,最初の書き込みが完全に完成することを期待しないでください.
  • 2 簡単な戦略のコードを模倣する
  • 3 真剣に,これは必要だ. 怠慢は災難だ.
  • 4 忍耐,BUGが私を虐げている,私はBUGを初恋のように扱っている! 気をつけなさい. 困った時は,テレビを見たり,路上で美女を賞賛したり,そして続けてください.
  • 5. 初期段階では,注釈をよくして,情報を出力する関数 ((API) をよく使って,発明者の量化では,Log () 関数を使用する.このようにLog () を書くことができます. これをあなたのコードの論理構造の中に追加して,このLog関数を持つプロセスにプログラムがいつ入るかを知ることができます. 活用Logは,多くのBUGの位置づけをすることができます. 実際のコードを書くとき,しばしば様々な死循環に陥ります. しかし,プログラムがどこに死んだのかわかりません.
  • 6 恐れるな 行動せよ