Channel Breakout Bot for bitflyer-FX (by Connie-Wild氏)読解メモ32
の続きです。
題材は https://github.com/Connie-Wild/ChannelBreakoutBot です。
backtestメソッドの続きから。
#エントリーロジック
if pos == 0 and not isRange[i]:
ポジションが無くかつレンジでない場合はエントリー判定に入ります。
#ロングエントリー
if judgement[i][0] != 0:
pos += 1
buy_entry.append(judgement[i][0])
buyEntrySignals.append(df_candleStick.index[i])
trade_log.append([df_candleStick.index[i], 'buy entry', judgement[i][0]])
ロングエントリー判定の場合は、
posに1加算し、
buy_entry配列にjudgement配列に入れておいたロングエントリー価格を入れ、
buyEntrySignals配列に現在のローソク足情報を入れ、
trade_log配列に現在のローソク足情報、買いエントリーであること、エントリー価格をappendします。
elif judgement[i][1] != 0:
pos -= 1
sell_entry.append(judgement[i][1])
sellEntrySignals.append(df_candleStick.index[i])
trade_log.append([df_candleStick.index[i], 'sell entry', judgement[i][1]])
ショートエントリー判定の場合は、
posを1減算し、
sell_entry配列にjudgement配列に入れておいたショートエントリー価格を入れ、
sellEntrySignals配列に現在のローソク足情報を入れ、
trace_log配列に現在のローソク足情報、売りエントリーであること、エントリー価格をappendします。
#ロングクローズロジック
elif pos == 1:
posが1、つまりロングポジションを持っている場合はロングクローズ判定に入ります。
#ロングクローズ
if judgement[i][2] != 0:
nOfTrade += 1
pos -= 1
buy_close.append(judgement[i][2])
#値幅
plRange = buy_close[-1] - buy_entry[-1]
pl[-1] = pl[-2] + (plRange-self.cost) * lot
buyCloseSignals.append(df_candleStick.index[i])
plPerTrade.append((plRange-self.cost)*lot)
trade_log.append([df_candleStick.index[i], 'buy close', judgement[i][2], (plRange-self.cost)*lot])
#waitTh円以上の値幅を取った場合,次の10トレードはロットを1/10に落とす.
if plRange > waitTh:
waitTerm = originalWaitTerm
lot = originalLot/10
elif waitTerm > 0:
waitTerm -= 1
lot = originalLot/10
if waitTerm == 0:
lot = originalLot
ロングクローズ判定の場合の処理です。
nOfTradeに1加算します。
エントリーからクローズまでを1トレードとして捉えて、何トレード行われたかを記録するためのものと思われます。
ロングクローズするのでposを1減算します。
buy_close配列にロングクローズ価格をappendします。
今appendしたbuy_close配列の末尾価格からbuy_entryの末尾価格を引いてplRangeに入れます。
このトレードでの損益値幅を表す変数となります。
pl配列の末尾に、pl配列の後ろから2番目と値幅から指定しておいたcostを引いたものにlotを掛けたものを足してappendします。
前回見た「末尾から取り出してappendするので一見謎な処理」の理由がわかりました。
ここの計算に使うための用意だったと考えられます。
また、costはREADMEにある通り、
バックテストおよび、optimizationで利用。遅延等で1トレード毎にcost円分のコストが発生するものとして評価を行う。
というものです。
成り行き注文をする以上必ず約定価格は想定より滑りますし、
リアルタイムAPIで約定を受信するとしてもサーバ状態によっては数秒遅れることがあるため、
若干不利な値で約定すると考えておいたほうがよく、
そのフォローとしてcost変数が使われています。
15分経ったので今日はここまで。
↓次
この記事が気に入ったらサポートをしてみませんか?