ライブラリ: コントロール_トレード_セッション

新しいコメント
 

コントロール_トレード_セッション:

取引セッション制御用ライブラリ。起動時に、週7日（土日は暗号通貨取引が可能）の取引セッションの時間をカウントし、1日最大10セッションまでカウントします。そしてOnTick()でチェックができ、もしティックが取引セッションの外に来たら、それ以降の処理を終了することができます。

コントロール_トレード_セッション

Author: Aleksei Kuznetsov

 

これらはすべてでたらめです。もしブローカーが、実際の相場とは異なる形で商品の仕様を記入した場合、あなたのライブラリはブローカーと同様に、あからさまな嘘をついてしまうことになります。

例としては、フィナムで実行してみてください。

 
Alexey Viktorov #:

それはすべてでたらめだ。もしブローカーが、実際の相場とは異なる形で商品の仕様を記入した場合、あなたのライブラリもブローカーと同様に、あからさまに嘘をつくことになるだろう。

例はフィナメで実行できます。

誰に責任があるかは判明しました。では、どうすればよいのでしょうか？

sinput を使って日単位でセッションを入力するオプションを追加することも可能です。
 
素晴らしいライブラリですね、ありがとうございます！最大の特徴は速度です。最適化を行う者にとっては、まさにうってつけです。
 
Forester #:
責任の所在は明らかになった。では、どうすればいいか？

sinput を使って日ごとのセッションを入力するオプションを追加できる。

そのオプションを追加しました。説明とコードをご覧ください。

 
コードをさらに少し高速化しました。 以前は、取引セッション 外の各ティックごとに時刻の計算を行い、それをセッションの配列と比較していました（
）。現在は、セッションが切り替わる際に、現在のセッションの終了時刻だけでなく、次のセッションの開始時刻も計算するようにしました。その結果、チェックも1回だけになりました（
）。 
if(time < this.NextTradeStart ) { return false; }
 
Forester 取引セッション 外の各ティックごとに時刻の計算とセッション配列との比較が行われていましたが、
現在では、セッションが切り替わる際に、現在のセッションの終了時刻に加えて、次のセッションの開始時刻も計算するようにしました。その結果、チェックも1回だけになりました：

これは、任意の時間枠への該当を判定するための最も適切なアプローチです。例えば、取引時間が12時から15時までである場合、このようなNextTimeアプローチを使用すべきです。

サードパーティのコードの中では、あなたのものでしかこのような実装を見かけませんでした。

 
SymbolInfoSessionTrade エラー 4307
 
あまり詳しく読み込んでいないが、現在の実装では、セッションは厳密に1日の範囲内に収まることを前提としているようだ。しかし、時差が 大きな場合、つまり 例えば、アジアのブローカーを通じて欧州セッションの取引が行われる場合や、その逆の場合などです。つまり、datetimeから日付を除外すると、Toの時間がFromの時間より早くなるケースがあるということです。
 
Stanislav Korotky #:
カスタムシンボルでは、セッションに関するあらゆる複雑な状況を設定し、ライブラリの正確性を確認することができます。幸いなことに、セッションを変更しても、気配値の書き換えは必要ありません。
 
Stanislav Korotky #:
あまり詳しく読み込んでいないのですが、現在の実装では、セッションは厳密に1日以内に収まることを前提としているようです。しかし、タイムゾーンに 大きな差がある場合、つまり 例えば、アジアのブローカーを通じて欧州セッションの取引が行われる場合や、その逆の場合などです。つまり、datetimeから日付を除外すると、Toの時間がFromよりも早くなるケースがあるということです。
単に時刻の比較が行われているだけです。
if(!TradeSession.isSessionTrade(TimeCurrent())){Print("Market closed. OnTick return");return;}
代わりに 
TimeCurrent()
ちなみに、任意の値を指定することも可能です。

取引セッションの時間はブローカーから取得されるか、手動で設定することも可能です。
12
新しいコメント