デイトレードのテンプレEAを作りつつの更新

MQL5にはTimeDaylightSavings()って夏時間の補正を返す関数があるんだけど、

一見便利そうじゃん、俺も思ったわけこれはいいじゃんって。

でもこれPCのタイムゾーンを参照するから日本に住んでる奴の大半が補正無しって出ちゃうの、バックテストじゃ動かねえし

こういうの多すぎだろMQ社よ、馬鹿が。

怒りに任せて書き殴れってことか↓

4月と10月は問答無用で夏時間として

追記：3月までと11月からのboolにfalseが入っていない

　　　詳しくは一番下のコードの中身を見てください、ほかにもいろいろ変わってるので。

3月の2週からの判定が69行目から3月1日が何曜日か分かれば2週目の判定ができますday_of_weekを使って8から引いてやってそれより大きかったら2週目で夏時間。

日曜日だけちょっと1週ずれるけどまあ日曜日は相場が開いてないので無視。

11月は逆に小さかったら1週目で夏時間適用。

そしていろいろ書いてる間にわかった

オフセットの意味を勘違いしていて修正

TimeTradeServer()で管理するんだから夏時間とOFFSETが関係するのが逆なんだよね。CP-CLで管理するのは単純にOPとCLに時間を入れればいいだけだったて言う。

よく考えたらちゃうな、GMTの時間でOPとCLだからNewYorkだと常に11か

OFFSET分引いておかないとダメだ。

差し替えるまでそのままなんで後で直します。

差し替えた

そしてTokyoとGMToffsetが

もうちょっと綺麗に書けそうな気がするんだけど

どこなおすか今のところ思いつかないね。まあちゃんと動いてるっぽいしいいだろ。

一応MQL4に戻しやすいようにやりつつだし、んーめんどかった。

しかしタイム関連の関数はローカル参照するのが多すぎて使いもんにならんよな、

MQL4に落とすときに相互性がちょっとないし。

MQL5でかけるけど実際採用された時両建てできないのはつらすぎるし

困ったもんだぜ。

ということで今回のEAのサンプル

まじめにデイトレードやりたい人は持って行って。

追記：間違っているので後で差し替える。

さらに追記：差し替え済み

眠い | DTEA.zip ダウンロード | uploader.jp

仕様（パラメータ）の説明

SaP_Modeは先行指標の区切りをどこにするか

dayperiodは取引する一日の区切り（サインがでてポジションを保持する期間）

G_Offsetは業者の夏時間を考慮しないタイムゾーンを入れる。

１H足以外では動かないのでそれ以外で使いたいなら工夫してね

2割ほど書き換えたら多分なおせるでしょ。

まあそんなとこかな、ちゃお。

追記：色使ってホワイトボードに図を書きなぐると修正が早かった、これからもブログにお絵かきするのは有用かもしれない。

システム設計。過去の事象の及ぶ範囲と狙い所。

過去の事象の影響力について考えます、

注意：その証明や検証については行うつもりはなく全部俺の経験則です。

つまりは、俺は正しいとは言わない！！！

さてちょっと前に貼った期待値1.5の曲線ですが、

期待値ごとで比べるために2段目の表を用意しました。

おさらい、この青いライン上にのるシステムを20個用意できれば日計りで合成して

黄色いラインのシステムが出来上がりで目標達成です。

しかし、右側に注目するとYの幅がほとんど変わりません

そこまで行くとちょっとスプレッドが変わっただけ、勝率が変わっただけ、

極端な場合一つでも負けが増えたり減ったりするだけで

期待値に偉い様変わりが起きてしまいます。

そうなってくると期待値での評価はあてにならなそうです、リスクの評価も負けが足りない気がします。

別のシステムの評価方法が必要になってくるでしょうし、もっと精査しないとなんか勘違いで起こってるかもしれないと疑うレベルです。

というかそんなに勝率がいいならP/Lを無視できるのでFXではなくてBO（バイナリーオプション）で運用すべきです、反対に勝率がクソ低くても同じ（逆に張れば）BOでやった方がいい。

実際にBOできりんさんとかは大儲けしたらしい（俺もなんとなく気づいたが乗り遅れました）。今はもういろいろルールが変わってだめらしいですが。

要するに過去の事象の影響力はそんな極端なことを起こしません。

期待値で評価するのであればせいぜいこの赤いラインで囲った部分を狙うことになります。ぎりぎり許容して外一個分。

それ以外は過去の事象以外の影響力を必要とします。