ちゅーすい@フリーランス塾講師 兼 FXトレーダー(目標)

入社半年で鬱退職した東大卒が塾講師しながら人生逆転目指してFXに挑むブログ

ローソク足各部名称

FX

カシオペア製作①~機能α~

前回書いたカシオペアの機能のうち、最低限かつ最優先で実装したいのは、

・特定ローソク足形状でのシグナル表示(機能α)

・シグナル表示時の売買(機能β)

の2つです。ともあれ機能βについては機能αの発展型なので、ひとまずαの実装を目指します。

で、まずは特定ローソク足形状について。

とりあえず以下を読むために雑ですが

  • ローソク足:図中の赤(手書きだと白抜き)青(手書きだと斜線)の棒。○○足というと○○毎に1本増えるものを指す。(例.15分足は15分毎に1本完成して増える。)
  • 実体:ローソク足の太いところ。そのローソク足の始値(Open)~終値(Close)部分を指す。私は値上がると赤、下がると青で表示させています。
  • ヒゲ:ローソク足の上下端の細いところ。一番上が高値(High)、下が安値(Low)を指す。

だけ覚えといてください。

[ローソク足各部名称]

 

ピンバー系(トンカチ等) 

[11/13 USD/JPY 15分足]

 

上のチャート内の黒矢印で示したようなローソク足です。価格が一旦片側へと動いたものの、その足が完成するまでに戻した場合にこの形がでます。見た目がそれっぽいので向きと上げ下げと実体部分の大きさ次第でトンカチやらトンボやらカラカサやらと呼ばれます。

さて、ピンバーが成立したということは、価格が動くと見せかけて戻したわけですから、引っかかって売買した市場参加者(上の例だと価格が上がったタイミング、すなわち上ヒゲの先端付近で買った人)は短時間のうちに含み損が出始めているので焦っているはず。もう少し逆行すれば損切りしてくれそうなので、ピンバーが成立した次の足で逆行継続を確認したら追いかけます。

とりあえずまずはこのピンバー系判定機能を最優先で実装しにいきます。

 

全否定系(包み線の一種)

[11/13 USD/JPY 30分足]

 

上のチャート内の黒矢印で示したような1本前の足の動きを帳消しにするような足です。これは包み線の一種を私が勝手に呼んでるだけなんですが、まぁ市場が動きを完全に否定してるのでこれでいいかなと。

成立原理と利用法はピンバー系とほぼ同じです。本質的にはローソク足をどの時間幅で見るかによって見え方が変わるだけなので。(どちらかでしか認識が難しいパターンもよくある。)

ピンバー系判定の実装が終わり次第こちらの判定機能実装に移ります。

 

ピンバー判定機能詳細の言語化

今後コンピュータにやらせたい操作や判定をまずもって自分(人間)はどうやっているのか(何を基準に判定しているのか)を言語化して、更にそれを数式や条件式に落とし込みます。

ピンバー系の検出条件を決めるにあたり、ひとまず[上に動いたが戻した]場合にできる下降予兆のピンバーで考えることにすると、

  • ローソク足全体の長さが短すぎない…①
  • 上ヒゲが全長の大部分を占める…②
  • 実体そのものが小さい…③
  • 下ヒゲがないか、あっても小さい…④
  • 続く足が安値を更新する…⑤

の5条件を満たせばいいかなと思います。

また今回後々売買に使うことを想定すると、損切りラインがあまり遠くになりすぎないこと及び形状の微妙な違いごとに判定条件を切り替えられることも欲しいので、

  • ローソク足全体の長さが長すぎない…⑥
  • 実体部分が上昇か下落かほぼ同値かの識別…⑦

も合わせた6条件分岐1識別で進めることにしました。

ちなみに④と⑦については下図のようなもののうちどこまでを信頼できるピンバーとして認めるかというのを後々外部パラメータで変更できるようにしたかったので導入しています。

[どこまで信頼できるピンバーとみなすか]

 

ピンバー判定機能詳細の条件式化

続いてこれらを数式的な条件式に落とし込んでいきます。

①~⑦について、次の図のように各部を定義すれば、

[ローソク足各部計算; O:始値, C:終値, H:高値, L:安値]

 

  • (定数a) < SizeofBar…①
  • SizeofBar × (割合定数b) < UpperShadow…②
  • RealBody < (定数c)…③
  • LowerShadow < SizeofBar× (割合定数d)…④
  • Low[続きの足] < Low[ピンバー成立足]…⑤
  • SizeofBar < (定数e)…⑥
  • (定数f) < O-C→(下げ), O-C < (定数f) × (-1)→上げ, その他→ほぼ同値…⑦

となります。また、後々逆向きでのピンバー検出を行うことも考えて記述しやすくするために便宜上これらを、

  • 共通判定 : ①、③、⑥
  • 反転兆候判定 : ②、④
  • 最終判定 : ⑤
  • シグナル点灯時の信頼度チェック : ⑦

に分けてフラグを割り当てていきました。

このうち共通判定と反転兆候判定を入れ子で書いて下のように記述。(正直コード的にドチャクソ汚いですが、まぁそれは今回一旦置いとくとして。"if((条件式)&&(条件式)&&(条件式)…)"みたいな表記あんまり好きじゃないんですよね。)

[条件分岐の入れ子構造部分]

 

とりあえずここまでの段階で「ピンバーか否か」(シグナル点灯とは別)の判定はできるはずなので、ピンバー判定されたら矢印が出るように設定して一旦コンパイルしてみました。

 

array out of range

まぁそしたら早速この↑エラーですよ。いやしかし200行近いコードの初回コンパイルでこれ以外は1箇所(なんか変数名誤字ってた)しかエラー出なかったしむしろ優秀かも知れん。

メッセージの示すエラー吐いてる行を見にいくと配列が定義時以外で初登場するとこでした。まぁ"array out of range"ってあるしね。どう考えても配列で確保してないとこ触ろうとしてるんだよね。

エラーが出ていたのは SizeofBar[i]=BufHigh-BufLow; の行。

[初回コンパイルエラー部分]

 

エラーメッセージ的に配列の存在そのものは認知されてるっぽい。あとこの感じ、この1行だけ解決してもたぶん続く UpperShadow[i]とかその辺全部同じエラーが出るんだろうなってとこまで予想がつきました。

ループ初回たるi=0のときから out of range ということはそもそもこれ配列が定義だけされてるが枠が確保されてないなと判断。

結局、「配列定義時に動的配列で確保したつもりだったができていなかった」ということでした。

OnInit関数の中でSetIndexBufferにぶっこんだ配列はBars(ローソク足本数)分確保されますが、そうでなく定義しただけだとあとで自動では確保されないんですね(ド素人感)。。。malloc関数とかないしいらないのかと。。。

普通にArrayResize適用してBars分の確保させました。

 

出力結果(ピンバーか否かの判定)

というわけでコンパイル通して出力させた結果がこちら↓

[ピンバー判定]

 

ちょっと見づらいですが、矢印が出てるとこが判定の出たところです。たまーに明らかにピンバー判定されそうなのに判定でてないやつがあるのでもう少しデバッグは要りそうですがひとまずそれっぽい挙動はしている。

 

というわけでとりあえず今日はここまで。売買向けの最終判定と信頼度チェックの実装も明日以降ですね。

うーん、この時間(午前8時過ぎ)にこれが更新されてることからもわかるようにそこそこ時間かかってるんだがまだこの辺か……。先が長いな、間に合うのか。焼肉……。

-FX