続けます。ようやくシミュレーションの話。
プログラミング的な用語でいうと、実装の前に設計から始まる。
回りくどい。けど急がば回れだ。
●5日移動平均が20日移動平均を上回ったら新規買い
●利益が2%を越えたら利食い
●損失が1%を越えたら損切り
こんなロジックを検証するとして、
移動平均のクロスというシグナル。
損益率によるシグナル。
このシグナルの部分を取り替えられるようにしておいきたい。
考えておきたいのは、
仕掛けと手仕舞いのシグナルが、着脱可能でかつ複数組み合わせられるように。
ロジックの変数（何％などの設定）は簡単に出来るように。
最低限このくらいは設定可能にしておきたい。
毎回プログラミングいじるのでは嫌だ。
記録するに管理しづらいし。作業が煩雑すぎる。
あとは、
仕掛けと手仕舞いのタイミング指定は（寄り付きとか）固定か？随時か？
信用売りにも対応してるのか？売りからに固定か？
このヘンでしょうか。気になるのは。
毎回プログラムいじって対応するのでは、作業の煩に耐えないというのは、
シミュレーションしてるときと、プログラミングしてるときでは、
頭の使い方が違うから、同時にはやりたくない。
シミュレーションはシミュレーションで集中したい。
プログラミングは手段に過ぎず、検証はお金に直結する。
でまあ、Rubyはオブジェクト志向でもあり、
部品化するにも、対応してくれる。
坂本タクマ先生、
このあたりでは、プログラミングの設計上も、そうとう試行錯誤したのではないか？
あるいは、最初からスマートに設計して、そのとおり無駄なくプログラム書いたか、
後者の場合は、先にいろいろ勉強したはずだ。
有償無償関わらず、出来合いのソフトやWEBサービス利用する場合にも、
このあたりの自由さは最低限担保して欲しいもの。
ロジック自体はおろか、パラメータの設定も不自由なものも、
あったりするという噂を聞いたことがある。有償で。
使い勝手の柔軟さは、費用対効果に直結するので、
自作他作問わず、大事にしたいところですね。
質問コーナー、お問い合わせは、sanpome.net@gmail.com まで。
