bitrinjani
片側未約定時のオーダーチェックの終了判定
ぜひ検討していただきたいことがあり失礼いたします。
いま片側未約定時のオーダーチェックのループ終了は経過時間のみですが
１：オーダーチェック時のベスト価格とオーダー価格の差 ２： 割り込まれたオーダー数 ３：割り込まれたボリューム数
のいずれかが設定値を超えたら即オーダーチェックループ終了 という機能はどうでしょうか？
ご一考いただければ幸いです。
早速のご返事ありがとうございます。 つたない説明で申し訳ありません。 正式な表現の仕方がわからないので
チェック時（ベスト価格が変わった）
価格 ボリューム
1500000 0.005 -best
1499800 0.010
1499700 0.100
1499600 1.000
1499580 0.001
1499500 0.100 - order
２： 1500000 -1499580 まで ５ ３： 1500000 -1499580 までのボリュームの和 1.116
という意味です。表現の仕方がおかしかったですね。
変動が少ないときはじっくりまつ。激しいときはさっさと「onSingleLeg」の処理に入ってもらいために提案させていただきました。
ご検討よろしくお願いします。
maxRetryCountを超えた場合、onSingleLegの動作によりlimitMovePercentの数値だけ不利な指値で注文が行われるため、資産が減少する事を考慮しての質問だと思います。 基本的にはmaxRetryCountを待った方が良いのではと考えています。(その方が損失が少ない為) 提案された機能はlimitMovePercentの数値を5%より小さくした場合に、出来るだけ少ない損失でonSingleLegの状態を解消する事を目的としていますか？
丁寧なご返答ありがとうございます。
提案された機能はlimitMovePercentの数値を5%より小さくした場合に、出来るだけ少ない損失でonSingleLegの状態を解消する事を目的としていますか？
その前段階の両約定済みペアを増やすためと考えております。 待つ時間を可変にすることによって両約定済みにしたいということです。 急上昇、急下降中と、うろちょろしているときでは「maxRetryCount」の適正な値が違うと感じたからです。 他の判定方法が選択できればいいなと愚考いたしました。
(その方が損失が少ない為) limitMovePercentの数値を5%より小さくした場合
質問に質問で返して申し訳ないのですが５％というのは初期値としての意味でしょうか？ また
maxRetryCountをオーバーしたとき
価格の変動が10% 「limitMovePercent」 5% 「TTL」3000 の場合 ３秒以内に価格の変動が5%に戻らなければ未約定
価格の変動が3% 「limitMovePercent」 5% 「TTL」3000 の場合 5%の価格でオーダーをだして3%の価格で約定（成り行き扱い？）
という認識であってますでしょうか？
勝手ながらのこの愚考にお付き合いいただき感謝いたします。
急上昇、急下降中と、うろちょろしているときでは「maxRetryCount」の適正な値が違うと感じたからです。
言われてみればそんな気がしますね。 ただ、取引所間の価格差が生まれるのは、急上昇、急下降中が殆どになります。 取引所Aにて急変化が起こり、取引所Bではまだ発生していない場合など、突発的に生まれる価格の差を突くのがアービトラージの手法になります。 取引所Aで発生後、追従するように取引所Bでも発生するので、価格の差が生まれるのは一瞬であり、人間では追い付けないため、このようなプログラムが活躍します。 価格が横這いの時にオープンしてしまうと、変化が起こるまで長い間ポジションを維持しなければならず、効率的ではありません。
maxRetryCountをオーバーしたときの動作は認識の通りです。
クレーム紛いのイシューを投稿する方が居る中、このような建設的な議論は楽しいです。
maxRetryCountをオーバーしたときの動作は認識の通りです。
limitMovePercentの数値を5%より小さくした場合に、出来るだけ少ない損失でonSingleLegの状態を解消する事を目的としていますか？
やっと気がつきました。設定値と価格の変動しだいではより少ない損失で抑えられそうということにもなりますね。
クレーム紛いのイシューを投稿する方が居る中
それでも公開され続けていることに深く感謝いたします。
よいアイデアだと思います。 ただ、現状取引所側のREST APIの呼び出し回数制限が厳しく、オーダー状態をチェックしながら価格を取得してくると制限にひっかかる可能性があります。 価格取得がREST APIではなくwebsocketならよいのですが、残念ながらQuoineが対応していません。 一旦このリクエストは保留とします。
