minTargetProfitPercentのチューニングに関して

[tenten35]

オープンのminTargetProfitPercentの設定を1%に 設定した場合に、仮にも全平均2%(勿論分散が大きいかもしれませんが) だとすると価格差が開く傾向にありエグジットできる 可能性が下がると思います。プラスの予想収益 のみのログ(できれば、フィールドに時刻と予想利益を csvで書き出しできるもの)があり、それを 元に統計を取れば、チューニングの閾値を 各々決定でき裁定機会の頻度が上がるのではないかと 思っております。また、簡易的に平均、分散を出力し、 それらの情報を元にminTargetProfitPercentを自動で決める というのもありなのかな、と思いますが 個人的には前者の方法がいいのかなと思っております。 ご検討とご意見を頂けると幸いです。

[Connie-Wild]

info.logに時刻と予想収益が表示されているので、grepやsed等で必要な部分を抽出し、ご自身で解析、パラメータの決定をされてはいかがでしょうか？

[Connie-Wild]

また、質問の内容が抽象的過ぎて検討のしようが無いかと思われます。 どのような計算式を用いるのかを含めて、具体的に質問して下さい。

[tenten35]

ご指摘ありがとうございます。 n=1247にて解析したのですが、分布に 従う結果となりました。

繰り返しますが、minTargetProfitPercentの1％の設定をしてその周辺の 予想利益で約定し、平均が2％の場合、Bit Askの差額が約定の場合より 大きく広がり続けるままの為、中々クローズされない という認識です。この場合、exitNetProfitRatioが 低くても中々約定しないのではと感じた次第であります。 これは例にあげると予想収益が1％で設定しその値が200の場合、

200[1％] + (-400[2％]) > 0

となり中々約定されないという意味です。 上記の認識が誤っておれば、指摘して頂きたい と思って質問させていただきました。

具体的な計算式としては、あくまとして理想論で 他の方の意見を仰ごうと思っていた次第です。 私としては、平均値+3σまたはそれ以上の水準の偏差(σ) をminTargetProfitPercentの値にすることによって、

300[平均値+ 3σ] + (-200)[平均値] > 0

となり、約定しやくすくなるのではないかと感じております。

[bitrinjani]

申し訳ありませんが、私にはほとんど内容が理解できません。

例えば、この[1%], [2%]は何を意図しているのでしょうか?どのように計算したら >0になるのでしょうか?

200[1％] + (-400[2％]) > 0

[tenten35]

1%はminTargetProfitPercent、 2%は実際の予想利益の平均を仮定したものです。

[Connie-Wild]

ご理解されているかと思いますが一応。

「config_default.json」の「minTargetProfitPercent」「exitNetProfitRatio」等の値はあくまで設定例です。 有効にする取引所によってはdefault値で運用すると資産が減ります。 自分が有効にしたい取引所を数日間デモで動作させ、予想収益の%値を収集し、そこから利用者の判断で数値を決定し、実際に運用する事をbitrinjaniさんは想定されているかと思います。 ※収益率は取引所間のスプレッド乖離率でもあります。

また、このような金融プログラムで平均値や偏差値を計算に用いるのは効率が悪いです。 もっと効率の良いやり方はあります。 その方法はtenten35さん自信で試行錯誤して頂ければと思います。

[tohyan]

そろそろこの辺りの議論になるかと思っていた頃でしたので横から失礼します。 私的にtenten35さんの提案はとても貴重な意見だと思っています。うまく機能化 できれば、チューニングの頻度がグっと下がり、ものすごい便利になります！

最近の状況としては、exitNetProfitRatioが設定できるようになり格段に便利になり ましたが、minTargetProfitを上手に設定しないとなかなかクローズがされません。 この課題を具体的な例に沿って説明させてください。

簡単な例） ■設定 minTargetProfit: 500 ※単純計算になるように％ではなく数値にします。 exitNetProfitRatio: 10 maxSize: 0.01 minSize: 0.01

■相場の状況 Quoine Ask 短期的にみて 1,800,000～1,820,000を行き来 　↑↓　10万くらい離れる状態が暫く続いている相場 Coincheck Bid 短期的にみて 1,900,000～1,920,000を行き来

設定上、下記の場合にもオーダーを出します。 Quoine Ask 1,820,000 Coincheck Bid 1,900,000 予想収益 800 ＞ minTargetProfit

しかし、この場合はexitNetProfitRatioの10%を確保するような クローズのチャンスはなかなか訪れません。

相場の状況を鑑みると、下記のケースの方がクローズ し易いのは分かると思います。 Quoine Ask 1,800,000 Coincheck Bid 1,920,000

上記の相場では、minTargetProfit: 500ではなく1100であったり1200であったりが イイ感じの値になるかと思います。 現状は、自身で分析してminTargetProfit(Percent)を調整されているかと思います。 これが動的に、セミオートで設定できれば便利なことこの上ないと思っています。

パッと考えつくのは、tenten35さんの提案されたような統計情報からの算出です。 外部ファイルの書出し＆読込みより、内部メモリ上で展開できる範囲の情報量でも 割と充分じゃないかと思ってます。

上記の例でいうと、 ・直近の板情報の履歴（XX回数分）から、取引所間で平均10万の差が開いていると分かる。 ・その10万＋新設定値YY％分　差が開いていれば、オーダーを出す。 　つまり、minTargetProfit（or Percent）を自動設定するイメージです。

どこまで変数化し、チューニング可能にするかはお任せします。 勿論この機能だけでは不完全で、欲を言えば上記の新設定値YY%も、 約定機会が減った際に閾値内で自動減少させれば完璧なのですが。

なかなか文章で伝わらないかもしれませんが、この機能を突き詰めれば 最強になるかと思っています。（取引所間の資金移動問題は除く） ぜひとも、ご検討の程よろしくお願い致します。

[Connie-Wild]

bitrinjaniさん

私は1日1回、ある計算式を利用してminTargetProfitPercentの設定値を求めております。 実際に取引所に合計8万円を預けた状態で、1日当たり2000円の利益が出ている状況です。 (市場が荒れた場合のロスカットを回避するために、maxLongPositionとmaxShortPositionを0.05で運用しているので、この数値を増やせば利益は増えるかと思います。) もし、自動チューニングを検討されるのであれば、この計算式を提供できます。 恐らく、半永久的に利益を上げ続ける事が出来るのではと思っています。

ただ、1点懸念があります。 現在、裁定取引の判断基準となる数値は全て、利用者がconfig.jsonにて自身の判断で設定をしています。 minTargetProfitPercentを自動チューニングとした場合、期待した以上に利益が出ないや、クローズしない等のクレームを言ってくる輩が出てくるのではと思っております。 そのようなクレームでプログラム開発者であるbitrinjaniさんのモチベーションを下げるような結果となることは最も避けたいと思っております。

自動チューニングを有効にするかどうかはポリシーに関わってくるところかと思います。 もし、実装されるようであれば出来る限り協力します。

[bitrinjani]

@tohyan さん、説明ありがとうございます。もとの質問内容が理解できました。 自動チューニングは有効だと思う一方、@Connie-Wild さんの指摘している通りベストなパラメータはそれぞれのトレーダーが探すべきだとも考えます。

そこで、以下の案はいかがでしょうか?

1. 期待収益、ベストクオート等のCSV書き出し機能を追加。ローカルDBに格納しヒストリカルデータを取り出せるようにする。
2. その後、プラグイン形式でtarget profitを上記データにもとづいて動的に変更可能とする。サンプルプラグインとしてヒストリカルデータから平均+αをターゲットとする実装を提供する。プラグインはJavaScriptの関数として実装可能とする。

2は少し時間がかかると思いますが、1は最近追加したローカルDBを使えば比較的簡単に実装できます。

[Connie-Wild]

@bitrinjani さん CSV書き出し機能は大変すばらしいと思います！ 可能であれば、書き出し情報には下記情報を加えて頂けたら大変嬉しいです。 「日付時刻、Best Ask、Best Bid、Best組み合わせ時の予想収益+収益率%、Worst Ask、Worst Bid、Worst組み合わせ時の予想収益+収益率%」

Worstを記録する理由ですが、Bestでオープンした場合に、クローズするのはWorstの組み合わせになる事が多いためです。 クローズに必要なコストを予め把握する事で、minTargetProfitを逆算する事が可能になります。

[tenten35]

@tohyanさん 丁寧な説明ありがとうございます。 @Connie-Wildさん 説明をしっかりできてなくて申し訳ありません。@tohyanさんの例の通りであります。実際の平均+αの数値のα(新設定値YY)を何にするというのは自身で何らかの条件を元に決定する必要があると思いますが、分散の大きさを元に決定するのもいいかもしれません。 @bitrinjani 色々考慮に頂いてありがとうございます。 おおかね@tyhyanさんの言う通りです。平均は何十万回の施行である程度収束しますが、裁定の機会を見つけるという点においては@tyhyanさんの言う通り直前X回の情報を元にして平均を求めた方がいいのかと思います。

[tohyan]

bitrinjaniさま、ご検討とご提案ありがとうございます。 頂いた案のtarget profitの動的変更は大変素晴らしいです。 お時間が掛かってもお待ちしておりますので、是非ともよろしくお願いします。

Connie-Wildさまが懸念されているようなクレームがくることは私も避けたいと思います。 そのために、標準機能ではなくオプション機能にして頂き、XXやYYの設定値は各ユーザー がベストパラメータを探し、設定してもらうべきかなと考えております。

案の２番につきましては、tenten35さまも同意して頂いたように、直近XX回から平均を求める ことで相場の変化にもついていくことができ、裁定機会も増えるのではと考えております。 念の為の確認ですが、プラグインでtarget profitを動的に変更する際、ユーザーオペレーション は不要という認識で合っておりますでしょうか。

また、当機能は３取引所間での取引に対応するのは複雑になり難しいと思いますので、 ２取引所間での取引を前提条件としたオプションでもよいかと個人的には考えています。

[tenten35]

ここの議論で出すことでは ないかもしれませんが、懸念のクレーム を出す方は、基本的にQiitaやgitのコミュニティ 外の方だと思われるので、Qiitaエントリの 「例えば、10秒に〜」の部分を削除した 方がいいのではないか、と個人的に思っております。 ここの文言につられて多数の人を 扇動してる気がするので。

[Connie-Wild]

これらの機能を追加頂けたおかげで、自動コンフィグチューニングが出来るようになりました。 本当に感謝しています。ありがとうございます！ ・期待収益、ベストクオート等のCSV書き出し機能 ・config.json auto-reload

環境はubuntu16.04を利用しており cut,sed,awkを利用して、csvデータから統計情報を計算し、sedでコンフィグの書き換えを行うShellScriptを作成し、cronで定期実行しています。

統計情報が見れるようになってまた別の楽しみ方が出来るようになりました。

[Connie-Wild]

オートチューニングによる運用に変えてから面白いデータが取れたので共有します。 青線がオートチューニングにより設定されたminTargetProfitPercent 赤線がBest ProfitPercentの上位10データの平均値 黄線がWorst ProfitPercentの上位10データの平均値 になります。 minTargetProfitPercentはexitNetProfitRatioを10%とした場合にクローズが見込める最低ラインを計算しています。 そして、オーダ実行時のデータはCSVに出力されない仕様なので 赤線が青線を超えている部分は、ポジションの最大値に達していたので注文できず機会損失が起こった部分になります。 こうデータで見ると約定できる機会は結構あるんだなぁという印象です。

そして収益のデータになります。 約定できずにonSingleLegの動作となると損益が発生するので、各取引所のAPIの動作がもっと俊敏になればあまり起こらなくなるのかなと思ってます。 損益が出てもNetExposureが増大するよりはマシなので、onSingleLegを追加してくれたbitrinjaniさんは神です。 5:30に1000円程収益が減ってますがこの時は一度しかonSingleLegが発生しておらず、約定金額をみても1000円減るような取引でないので、取引所がバグったのかと思いましたが、取引所のデータが消えていたので後追いできませんでした。。。

ログには残っていませんが、Quoineのサーキットブレイクで3000円吹っ飛んだので、Quoineのサーキットブレイク時に動作を停止するプルリクをマージしてもらいました。 多分次は大丈夫だと思います。(起きてほしくないですが

[PeterGrainfield]

部分約定してからonSingleLeg(Proceed)が発動するときの数量が丸められるので収益の計算がへんになるときありますね。

• 売りの動作 目標数量 0.01BTC 部分約定数量 　0.0000652 BTC OnSingleLeg　 0.009 BTC（丸め）

• 最終的な約定 買い 0.01 BTC 売り 0.0090652 BTC 発生するエクスポージャー 0.0009348 BTC

このエクスポージャーが丸々損益に乗っかって表示されてるようです。

INFO [PairTrader] >>Sending order targetting quote Coincheck  Ask 1,316,700 0.068...
INFO [PairTrader] >>Sending order targetting quote Quoine     Bid 1,308,900 0.853...
INFO [PairTrader] >>Order check attempt 1.
INFO [PairTrader] >>Checking if both legs are done or not...
INFO [PairTrader] >>Filled: Coincheck Buy 0.010005 BTC filled at 1,316,608
WARN [PairTrader] >>Pending: Quoine Sell 0.01 BTC sent at 1,308,900, pending size 0.0099348 BTC
 :
INFO [PairTrader] >>Order check attempt 10.
INFO [PairTrader] >>Checking if both legs are done or not...
INFO [PairTrader] >>Filled: Coincheck Buy 0.010005 BTC filled at 1,316,608
WARN [PairTrader] >>Pending: Quoine Sell 0.01 BTC sent at 1,308,900, pending size 0.0099348 BTC
WARN [PairTrader] Max retry count reached. Cancelling the pending orders.
INFO [SingleLegHandler] >>Trying to execute the unfilled leg Quoine Sell 0.01 BTC at new price 1
INFO [SingleLegHandler] >>Sending an order with TTL 3000 ms...
INFO [SingleLegHandler] >>Filled: Quoine Sell 0.009 BTC filled at 1,308,226
INFO [PairTrader] >>Profit is -1317.

[Connie-Wild]

あぁ、収益って書き方が良くなかったですね 取引所に預けている証拠金(JPY, Margin)を30分置きに取得して取引所の合計値をグラフにしているので、表示の問題じゃなくて本当に減ってたんですよね 問題があったのはCoincheckですが、トレードビューで取引履歴を見れるのが直近数回分だけだったので問題があった時間の取引を参照できなかったのです

[yukimemi]

とても有益な情報ありがとうございます！ ちなみに、Coincheckでの、Nonce must be incremented エラーってたまに発生しますでしょうか？自分だけなのか確認したくて。

あと、注文時にこのエラーが出た時は、リトライが実行されてないようです

[Connie-Wild]

@yukimemi さん そのエラーについてはこのイシューを確認してください。 https://github.com/bitrinjani/r2/issues/8 質問する前に一度全てのイシューに目を通す事をお勧めします。

[yukimemi]

すいません、そのイシューも一応目は通していたのですが、"ポジション取得APIの呼び出しに1秒間TTLのキャッシュを追加" とあり、Closeされていたので、修正後は発生しないのかなと思って聞いてみた次第です。 どんな修正をしたとしても、Coincheck側のAPIの問題って感じですかね？ 実際に動かして収益をあげている @Connie-Wild さんにも発生してないのかなと思って気になっちゃいました……ご迷惑なら無視してくださいすいません。

[Connie-Wild]

自分も発生しますよ coincheck側でAPIのリクエストに制限かけたらそのエラーが出るので まだビットコイン黎明期なので、あと半年もしたらAPIサーバも増強されるのではないかなと そうなってほしいって希望も含めて

[yukimemi]

回答ありがとうございます！やっぱりそうですかぁ…… ちなみに、今日は "Amount amount is too big" ってのも見ました。 発生した時に、リトライ処理が行われないのは仕様ですかね？それでエクスポージャーが偏ってしまってる時がありました…

[Connie-Wild]

証拠金に対して注文量が多い時に対して表示されるようなエラーですね。 maxPositionってBTCいくらにしてますかね。 取引所に預けている金額の半分くらいを使って買えるBTC量にしないと、売り買いが偏ったときにそのエラーが出るかと思います。 特にレバレッジ取引の場合、5万円預けて、coincheckだと5倍なので25万円分までBTCを買う事が出来るのですが、25万円分売り買いする事をフルレバといいます。 フルレバの場合およそ7%価格が予想と反対方向に行くだけでロスカットが発生し、ハンパじゃない負債を負うことになるので余裕を持った取引が必要です。

投資計画をしっかりと練った上でツールを利用される事をオススメします。 また、ツールやブロックチェーン、仮想通貨に興味があって勉強目的で投資されてるなら良いのですが、資産を増やす事が目的なら投資信託のインデックスを購入するか、個人向け国債を買うのがいちばんローリスクな投資です。

[bitrinjani]

その後、プラグイン形式でtarget profitを上記データにもとづいて動的に変更可能とする。サンプルプラグインとしてヒストリカルデータから平均+αをターゲットとする実装を提供する。プラグインはJavaScriptの関数として実装可能とする。

プラグインシステムを追加しました。

• config.json

  "analytics": {
  "enabled": false,
  "plugin": "SimpleSpreadStatHandler.js",
  "initialHistory": { "minutes": 30 }
  },

enabled: プラグインで動的に変更する機能を有効化 plugin: プラグインのファイル名。./pluginディレクトリ下にそのファイルが存在する必要がある。 initialHistory: 起動時に読み込む過去データの範囲。

サンプルとして作ったSimpleSpreadStatHandler.jsは、minTargetProfitPercentを過去データから算出した平均値+標準偏差に3秒(もしくはiterationInterval設定値)ごとに書き換えます。平均値 + 3 * 標準偏差などにも簡単に変更できます。

プラグインの実装方法のドキュメントは後ほど作成します。

[Connie-Wild]

@bitrinjani さん 実装ありがとうございます！ ドキュメントおまちしてます。

[bitrinjani]

ドキュメントを作成しました。 https://github.com/bitrinjani/r2/blob/master/docs/ANALYTICS_PLUGIN_JP.md

[Connie-Wild]

ドキュメントありがとうございます。 nodeだとsimple-statisticsが使えるのがホント便利ですね。

[volment]

プラグインに追加されたコードを見てみたのですが、 exitNetProfitRatioの値は見てないように読めました。 となると、オープンだけがプラグインにより適切にチョイスで行われ クローズ自体はそれを見て動的に手動で変更する感じがあるのでしょうか

[Connie-Wild]

@vol2223 さん あくまで実装サンプルのプログラムになります。 認識の通り、exitNetProfitRatioは加味されていません。 必要であればご自身でjavaScriptのコードを作成頂き、ご利用下さい。

[ghost]

例えば、minTargetProfitPercentとは別にexitNetProfitRatioも計算しておき、 const config = { minTargetProfitPercent, exitNetProfitRatio}; return config; とすることでconfig.jsonに反映されるのでしょうか。

[bitrinjani]

はい、反映されます。

[ghost]

ありがとうございます！

[Connie-Wild]

@bitrinjani さん サンプルスクリプトありがとうございます！

下記で不変標準偏差を求められていますが https://github.com/bitrinjani/r2/blob/master/plugins/SimpleSpreadStatHandler.js#L39 simple-statisticsのsampleVariance自体が不変標準偏差を返すようです。 https://simplestatistics.org/docs/#samplevariance なので初回起動時にsampleSizeが2以上無いと、エラーを返すかなと。

細かくて申し訳なく、間違ってたらごめんなさい！

[Connie-Wild]

@bitrinjani さん ごめんなさい！忘れて下さい！ sampleVariance(不変標準偏差)からstandardDeviation(標準偏差)に戻してるんですねこの式は。 失礼しました。

[tohyan]

bitrinjaniさま 何から何までご対応頂きありがとうございます！ 想定以上の機能で感激しております。 各設定値を分析しつつ、使用してみたいと思います。

[bitrinjani]

@Connie-Wildさん、たしかに少し意図しているものと違いました。不偏標準偏差を求めたかったので、コンストラクタの初期化では普通の分散にすべきでした。あとで直しておきます。

[ghost]

継続的に稼働させている場合、平均値は現在の数値から離れた数字になってしまうため、直近何分かのデータのみを反映させるように変更したいと考えております。

handleメソッド内で毎回ヒストリーを読み込むのは効率が悪いでしょうか。 また、そうする場合、history変数がhandle内では参照できないのですが、この場合どこを変更したらよいでしょうか。具体的にはasync handle(spreadStat, history)としたいです。

[bitrinjani]

history変数をconstructor内でインスタンス内に保存し、handleメソッド内で新しいデータの追加と古いデータの削除を行えば、一定期間内のデータのみ反映させることが可能です。

class SimpleSpreadStatHandler {
  constructor(history) {
    this.history = history; // historyを保存
    const profitPercentHistory = history.map(x => x.bestCase.profitPercentAgainstNotional);
    this.sampleSize = profitPercentHistory.length;
    this.profitPercentMean = this.sampleSize != 0 ? ss.mean(profitPercentHistory) : 0;
    this.profitPercentVariance = this.sampleSize != 0 ? ss.variance(profitPercentHistory) : 0;
  }

  async handle(spreadStat) {
    this.history = _.tail(this.history); // 最も古いデータを削除
    this.history.push(spreadStat); // 最新データを追加
    ... // 平均・標準偏差等をthis.historyから計算
  }
}

[ghost]

なるほど、そうすればよかったのですね。 教えていただいたおかげで、 一定のサンプル数まではヒストリーにデータを追加 一定のサンプル数に達していたら末尾のデータ削除 ができるようになりました。

わりと自分の思った通りに設定を変更できるようになりました！ ありがとうございます！

[yokawase]

R2の皆様、おはようございます。

早速ですが、 this.history = history; // historyを保存 this.history = _.tail(this.history); // 最も古いデータを削除 this.history.push(spreadStat); // 最新データを追加 を追記すれば、

config.json設定で "analytics": { "enabled": true, "plugin": "SimpleSpreadStatHandler.js", "initialHistory": { "minutes": 3 } とすることによって3分足移動平均によって発注されるという理解で良いのでしょうか？

csvデータ分析するとProfitPercentの3分足移動平均＋２σが、良いエントリーポイントになると思われました。

[bitrinjani]

3分に限定するには、timestampでフィルターすればできると思います。 試していませんが、以下のような感じです。

this.history = this.history.filter(x => x.timestamp > Date.now() - 1000 60 3)

[yokawase]

いつもながらの素早いレスポンスありがとうございます! 試してみます！

[UroboroZero]

プログラム未経験者です。ANALYTICS_PLUGIN_JP.mdやみなさんの意見を参考に書き換えたのすが、さっぱりわかりません。

◯平均値 + 3 標準偏差などにも簡単に変更できます。とありますが const minTargetProfitPercent = _.round(mean + 3 standardDeviation, precision); とした所、実行できているようですがあっていますでしょうか？

◯3分足移動平均によって発注。とありますが class SimpleSpreadStatHandler { constructor(history) { this.history = history; // historyを保存 this.log = getLogger(this.constructor.name); const profitPercentHistory = history.map(x => x.bestCase.profitPercentAgainstNotional); this.sampleSize = profitPercentHistory.length; this.profitPercentMean = this.sampleSize != 0 ? ss.mean(profitPercentHistory) : 0; this.profitPercentVariance = this.sampleSize != 0 ? ss.variance(profitPercentHistory) : 0; }

async handle(spreadStat) { this.history = _.tail(this.history); // 最も古いデータを削除 this.history.push(spreadStat); // 最新データを追加 ... // 平均・標準偏差等をthis.historyから計算 this.history = this.history.filter(x => x.timestamp > Date.now() - 1000 60 3) // 3分に限定 const newData = spreadStat.bestCase.profitPercentAgainstNotional; // オンラインアルゴリズムで新しいサンプルデータを平均値に追加する。 this.profitPercentMean = ss.addToMean(this.profitPercentMean, this.sampleSize, newData); // オンラインアルゴリズムで新しいサンプルデータを分散に追加する。 this.profitPercentVariance = ss.combineVariances( this.profitPercentVariance, this.profitPercentMean, this.sampleSize, 0, newData, 1 ); とした所、 ERROR Analytics Service failed. Unexpected token thisと返され、Analytics plugin systemの起動に失敗します。 ... // 平均・標準偏差等をthis.historyから計算の...の部分に平均・標準偏差等をthis.historyから計算のプログラムを独自に書かないと駄目みたい？

ご教示、よろしくお願い致します。

[bitrinjani]

◯平均値 + 3 標準偏差などにも簡単に変更できます。とありますが const minTargetProfitPercent = _.round(mean + 3 standardDeviation, precision); とした所、実行できているようですがあっていますでしょうか？

はい、それであっています。

二つ目の質問については、単純にJavaScriptの文法エラーのように見えます。JS一般の質問は他のサイトにお願いします。

[UroboroZero]

@bitrinjaniさん 返答ありがとうございます。 平均値+◯◯*標準偏差の設定が可能になり、非常に助かります。

すいません、ソフトウェアの設定に関連する質問とおもい書きましたが、 JavaScriptは別ということで、他のサイト、書籍等で調べて 文法エラーにならないよう、少しずつ理解していきたいです。

[Connie-Wild]

様々な指標を試してきましたが、15分間の移動標準偏差が一番オープンクローズが上手く出来たような気がします。 低い利益率でオープンしてしまうと、高振れした場合に数日間クローズ出来なくなってしまう事もあり、この調整か肝になるのを実感しました。

[Connie-Wild]

15分間の移動標準偏差を利用してminTargetProfitPercentを算出、運用した結果のグラフです。 MAXが30分間の内、Best値のTOP10で、MINがWorst値のTOP10になります。 targetがminTargetProfitPercentです。 前回に引き続きexitNetProfitRatio 10%を見込めるラインを設定しています。 価格差の変動に合わせてtargetを指定できているようです。 以前は外部Shellscriptで1分置きに設定してましたが、Analytics Plugin Systemに実装を切り替えました。 裁定判定毎に設定を変えるので、こっちの方が急変時に変な値で約定する事が無くて良いですね。

[ghost]

初めまして。自分も使い始めているのですが、小規模のポジションをExpected profit を下げたくさんこなしていくのと、大きめのポジションに絞って Expected profit を大き目で対応するのとかは、どちらが有効なのでしょうか、自身が実験できてないのが難点ですが。ポジションを取るにも口座に置いておく資金量が非常に重要になっているとおもうので。

[atommy1966]

◯平均値 + 3 標準偏差などにも簡単に変更できます。とありますが const minTargetProfitPercent = _.round(mean + 3 standardDeviation, precision); とした所、実行できているようですがあっていますでしょうか？

はい、それであっています。

二つ目の質問については、単純にJavaScriptの文法エラーのように見えます。JS一般の質問は他のサイトにお願いします。

3 * standardDeviationの修正は、ソースを修正後インストールし直す必要があるのでしょうか？ Config.jsonを修正すれば、「3 」の部分をプログラム実行中に変更できると、大変ありがたいです。

[atommy1966]

ヒストリーデータの平均値、分散が、ときどき大きな値になったり小さくなったります。

原因は、通信エラーなどによって、同じブローカーの値を使用してスプレッド値がほぼゼロになることがあり、その値を使った偏差の平均と、分散が計算されているからのようです。

同じブローカーの時は、ヒストリーデータには反映させないようにするには、どうすればいいでしょうか？

2019/8/4 17:13:22 BitflyerFX 1185000 0.468344 BitflyerFX 1184800 0.15334017 200 0.153 0.03 -6 -0.017 BitflyerFX 1185000 0.468344 BitflyerFX 1184800 0.15334017 200 0.153 0.03 -6 -0.017