こちらはインタラクティブブローカーズのAPI情報、Dmitry's TWS API FAQを日本語に訳したものです。元のウェブページの量が多すぎて閲覧しにくい＆元サイトを翻訳にかけるとPCが固まるため、備忘録用に章ごとに分けつつ、できる範囲で変な訳を修正して保存しています。
目次
基本データ
【Q】SPYの配当金はどうやって受け取るのですか？
こんにちは、 ここでは、いくつかのシンボルのティック タイプ 59 から IB から配当を取得しようとします。 返された文字列は簡単に解析してフィールドに入れることができますが、SPY の DY 値が間違っているようです。 IWM や AAPL などの他のシンボルは正常に見えます 配当文字列: 7.15705,6.284,20200918,1.578 SPYの配当金=6.28% 配当文字列: 2.02671,1.85,20200923,0.346 IWMの配当=1.85% 配当文字列: 3.13,3.31,20200807,0.82 AAPLの配当=3.31% これには何か理由がありますか？ 前もって感謝します |
ブルーノ 6.284 は、2020 年 6 月 19 日 (1.40) を除く、今後 12 か月の配当の合計です。 9月18'20 1.578 12月18'20 1.753 3月19'21 1.376 6月18'21 1.577 合計: 6.284 |
参考までに:ファンダメンタルズ API を通じて配当データを取得することもできます。 「 ReportsFinsummary」 レポートには、さらに 2 つのバージョンの配当データが含まれる場合があると思います。 私の経験では、これら 3 つの情報源は互いに矛盾する可能性があります。一方の情報が欠落していても、もう一方の情報が欠落していない場合があります。したがって、それらを比較する価値があります。 私の経験上、配当情報はかなり当てにならない場合があるので注意が必要です。大型株やETFならおそらく大丈夫でしょう。 TWS (シンボルを右クリック) で確認できる「配当スケジュール」についても Interactive Brokers に問い合わせましたが、これは API には公開されていないようです。 よろしくお願いします、 ピーター |
[Q] reqFundamentalData() – XML ファイルを解析するにはどうすればよいですか?
[A] by souqmateはこちらから
ロイターのファンダメンタルズレポートに関する最新情報はほとんどありません。
API 9.68 (だと思う) 以降、スナップショット/finstat/estimates に新しい名前、つまり ReportSnapshot/ReportsFinStatements/RESC を使用できるようになりました。
また、ReportsFinsummary、ReportRatios、CalendarReport という 3 つの新しいタイプもあり、現在のデータがあるのは最初のタイプのみです。 ReportsFinsummary では、3 つのレポートタイプ (TTM/A/R/P – twelveTrailingMonths/audited/restated/preliminary?) が見つかります。たとえば、MSFT の場合: これら 3 つのタイプは、2013 年 6 月 30 日の EPS では異なりますが、収益では異なりません。
ReportSnapshot/ReportsFinStatements/RESC 用の xml から csv へのパーサーは、20130708 に提供されました。新しい ReportsFinsummary ファイルのパーサーは次のとおりです (はるかに簡単です!)。
cat $x.ReportsFinsummary.xml | awk -F\" 'BEGIN{print "# what,curr,asofDate,reportType,period,amount (ただし、配当の 8 フィールド: what,type,exDate,recordDate,payDate,declareDate,amount)"} ! /summary/{ if(/currency/) curr=$2; if(NF>3){split($0,a," "); sub("<","",a[1]); printf a[1]"," curr","; for(k=1;k<=NF;k++) if(k%2==0) printf $k"," ; gsub(/<[^>]*>/,"",$0 ); sub(/ *|\.000000$/,"",$0); print $0}}' >! $x.ReportsFinsummary.csv
例えば：
一株当たりの配当、USD、2014-09-30、TTM、12M、1.120000
EPS、USD、2014-09-30、TTM、12M、2.582009
配当,USD,CD,2014-11-18,2014-11-20,2014-12-11,2014-09-16,0.310000
# 配当 (8 フィールド) を別のファイルに出力します。 cat $x.ReportsFinsummary.csv | awk -F, 'NF==8' >! $x.ReportsFinsummary_divi.csv
幸運を、
スークメイト。
[Q] Fundamental データはどれくらいの頻度で更新されますか?
[A] IB サポートの Angel より
基本データはトムソン・ロイターによって直接更新され、IB は生の XML データを提供し、API 用に操作/解析しません。トムソン・ロイターはファンダメンタルズ・データを毎日更新します。
[Q] 6 つの基本的なリクエストのうち 4 つだけが成功し、6 つのうち 2 つでエラーが発生するのはなぜですか:
– 取得に失敗しました
- 禁じられている
[A] IB サポートの Angel より
「取得に失敗しました」トムソン・ロイターが受信していないことを意味し、トムソン・ロイターがこの種類のレポートを提供していない可能性が高くなります。
そして、「許可されていません」はバグのようです (現在修正中であり、フォローアップする予定です:) [2014 年 8 月現在]
[Q] 「API Ver.9.67の直接サポートは終了しました」とのことですが。これはどのように作動しますか？最新の公開された安定バージョンのみをサポートし、リリース日にバージョン -1、-2、… -N をあきらめますか?ここのルールは何ですか？
[A] IB サポートの Angel より
現在のバージョン、1 つ前のビルド、および (利用可能な場合) ベータ版を公開します。 API コンポーネントの実稼働バージョンに問題がある場合は、その問題を解決するためにその特定のバージョンへのアップデートをロールアウトします。古いビルドの場合は、引き続き IB への接続に使用できますが、公開 Web サイトから削除され、問題を修正するためのサポートは提供されなくなります。
IBデータ購読
[Q] IB はどのようにしてレベル 1 データをスロットル/サンプリングしますか? (別名「最高の説明」
IB フィードで何が起こっているのか")
[A] Richard L King 著:オンラインでの表示/返信 (#43104) とTickSize イベントの「ごまかし」要素
2021 年 12 月 19 日に追加
ソース: 2007 年 8 月のトピック: NickSize イベントの「ファッジ」係数 実際、IB は何も蓄積しません (総量を除く)。 スロットル。彼らはすべての取引やすべての入札と質問を報告しているわけではありません。 以下のような興味深い内容が見つかるかもしれません。いくつかの投稿を合成したものです ここ数か月で私はここで作成し、いくつかの非常に集中的な内容に基づいています 数年前に私が取り組んだ、IB データ フィードがどのように機能するかについての研究 ( 私が見る限り、それは今日でも同じように機能します）。 IB データフィードは、市場のニーズに確実に対応できるように最適化されています。 市場がどんなに忙しくても。この結果、IB はすべてのレポートを報告するわけではありません。 あらゆる取引所でのあらゆる金融商品の取引、またはあらゆる入札や要求。 これを達成するために、各製品の価格スナップショットを効果的に送信します。 一定の間隔で楽器を動かします。この間隔は300くらいらしい ミリ秒。買値、売値、最終値のそれぞれについて、現在の価格を比較します とサイズは最後のスナップショットの値になります。値段が違うなら 価格とサイズの両方を送信します。価格が同じでサイズが同じであれば、 サイズのみをお送りします。価格もサイズも同じであれば、 どちらも送信しません。最後のスナップショット以降に取引があった場合、 （累積された）量を送信します（つまり、価格とサイズが送信されていない場合） 変更されましたが、1 つ以上の取引がありました。これは次の方法で検出できます。 ボリュームが増加します）。 これにより、IB は各ティッカーに必要な最大帯域幅を把握し、 したがって、顧客ごとに（ティッカーの数が限られているため）、 その負荷に対処できるようにサーバーのサイズを調整できます。市場になったら 非常に忙しいですが、それでも更新を送信するだけなので違いはありません たとえ100回の取引があったとしても、1秒間に3回程度 その一秒の間に。これにより、他のすべてのデータ フィードが発生する問題が回避されます。 混雑時にはデータが市場に大きく遅れることがあります。 (これまでに使用した他のベンダーでは、データが 市場より最大 2 ～ 3 分遅れる可能性があります)。 この手法には腹立たしい副作用があり、それが代償です。 スナップショット間の動きはまったく報告されない可能性があります。たとえば、 スナップショット 1 の最後の価格は 100 で、その後価格は 102 まで上昇し、その後 スナップショット 2 までに 101 に戻ると、スナップショット 2 で報告される価格は 101 になります。 102 の価格はまったく報告されません。これにより、時折 バーの高値と安値が不正確ですが、まれに 1 ティック以上の差があります。 それが重要であるかどうかは、使用される取引戦略に大きく依存します。 私の経験では、不正確さがある場合の数は、 重大な影響は無視できるほど小さいですが、それは当然のことです。 部分的には私が使用していた特定の戦略の関数ですが、次の点に注意してください。 1分足から積極的に取引し、非常にタイトなストップを使用したため、 不正確さに非常に敏感になると思うかもしれません。それに、時々、 不正確さはあなたに不利に働き、時にはあなたを助けることもあるので、全体として私は かなりバランスが取れていると思います。 上記は完全な説明ではありませんが、基本的なメカニズムを説明しています。あ ただし、注意してください。これは正確な科学ではありません。できたらいいですね 私が言ったことはそれがどのように機能するかを正確に説明したものですが、奇妙に感じるでしょう 事前のサイズを指定せずにボリュームを更新するなど、時々発生すること ボリュームの増加が正確な倍数ではないメッセージ 最近のサイズ メッセージ、または同時に送信された複数の最後の価格/サイズ メッセージ 時間メッセージ、または以前よりも小さいボリュームのメッセージ!しかし ほとんどの場合、私の説明は正確です。 もう 1 つの重要な点は、スナップショットが異なる時点で取得されることです。 さまざまな TWS セッションの時間。これはIBの観点からすると賢明です それは、何千ものすべてのユーザーに更新を送信する必要がないことを意味するためです。 ユーザーを一度に。しかし、これには興味深い副作用があります。 TWS のコピー (同じアカウントへの異なるログインなど) がわずかに得られます スナップショットが行われていないため、それらとは異なるデータ 同時に。 ちなみに、上では触れなかった注意点が 1 つあります。それは、両方の価格が サイズメッセージが (単一の TICK_PRICE ソケットメッセージで) 送信され、TWS も送信されます。 別の TICK_SIZE メッセージでサイズを再度送信しますが、ボリュームは 正しく更新されたのは 1 回だけです。この重複の理由は次のとおりだと思います バージョン 2 の TICK_PRICE メッセージが導入される前は、メッセージには サイズフィールドがあるため、価格とサイズは常に個別に送信されます: TWS が送信しなかった場合 重複したサイズを送信してから、別の TICK_SIZE に依存するプログラムを送信します。 メッセージは修正されない限り正しく機能しなくなり、 再コンパイルされました。 バックテストには、常に IB リアルタイム データを使用してきました。 SQL データベース、私はそれに完全に満足しています。事実は、 バックテストは、特に戦略が立てられている場合には、ほとんどが近似値にすぎません。 あらゆる種類の指値注文を使用します。成行注文または逆指値注文では、 注文は完了しているはずですが、どのくらいの価格になるかわかりません 一方、指値注文では、少なくとも最悪の価格を知ることができます。 満たされていただろうが、完全に満たされていたかどうかは確信が持てない （価格が実際に制限を超えない限り） – そしてあなたの戦略は次のとおりです 注文があったかどうかに応じて、その後の動作がまったく異なる 満たされているかどうか。 収集したデータをバックテストに使用する代わりに、次のことが考えられます。 代わりに、IB が提供する履歴データを使用してください。それが反映されていると思います。 取引所から送信された完全な情報。ここでの問題は、IB が リアルタイム データが維持されている期間であっても、履歴データは常に完全であるとは限りません。 データフィードは大丈夫でした。を収集するハイブリッド アプローチを試すこともできます。 リアルタイム データを作成し、後で任意の履歴データで更新します IBから入手できます。しかし、私の考えでは、これはやりすぎです。 リチャード |
[Q] HistoricalData のボリュームは数百単位で表されますか?
[A] by Joshオンラインで表示/返信 (#44876)
2018 年 7 月 8 日に追加
乗数は、ContractDetails クラスの mdSizeMultiplier フィールドによって指定されます。ほとんどの米国株では100です。
IB からの履歴データは、NBBO で発生する取引を表すことを目的としているため、通常、奇数ロットなど、NBBO 以外で発生する可能性のある取引タイプに応じてフィルタリングされます。 (ここで言及)
[Q] NYSEオークションの注文不均衡データは？
NYSE オークション注文の不均衡データを購読したところ、不均衡 (フィールド – 36) が合計不均衡であることがわかりました。
フィールド 36 で市場の不均衡を受け取る方法を知っている人はいますか?
2018 年 5 月 27 日に追加
これは、 リアルタイムの市場データ フィードで利用できます。EClient.reqMktData の汎用ティック リスト パラメーターで汎用ティック タイプ 225 を指定するだけで、オークション データがティック タイプ 34、35、そして36。
[Q] NYSE TRIN、NYSE Advancing issues、NASDAQ などの広範な市場統計をダウンロードするにはどうすればよいですか?
[A] by Mario Pisa mario.pisa[at]gmail.comオンラインで表示/返信 (#40162)
2018 年 7 月 4 日に追加
https://www.interactivebrokers.com/en/software/tws/usersguidebook/mosaic/marketStatistics.htm
- また -
これらは API から利用できます。
シンボル: TICK-NASD
セキュリティの種類: IND
取引所: ナスダック
通貨: 米ドル
[Q] ティック価格とティック文字列の違いは何ですか?
[A]この 興味深いスレッド (約 38 メッセージ) を読みました。 2017 年 11 月 21 日更新: グループがhttps://groups.io/g/twsapiに移動した後、 元のディスカッションへのリンクが壊れています: ( Todo: ディスカッションを見つけてリンクを更新してみてください…
【Q】同じ商品を紙口座とリアル口座で契約した場合、同じデータを取得できますか?それは「1行」としてカウントされますか？
[A] リチャード L. キング著:オンラインで表示/返信 (#46527)
2021 年 2 月 16 日に追加
2003 年に私が初めてこのメカニズムの調査を開始したとき、TWS のすべての市場データ行と API 経由のすべての市場データ要求は、同じティッカーを複数回リクエストした場合でも、100 ティッカーの割り当てに対してカウントされていました。これはおそらく、リクエストが別のサーバーに割り当てられており、実際に受信したデータ ストリームが異なっていたためだと思われます。しかし、1990 年代後半のある段階で (おそらく)、これは同じユーザーからの同じリクエストのみが送信されるように改良されました。 1 回カウント: したがって、複数の異なる API クライアント プログラムから特定の金融商品のデータをリクエストした場合、それは 1 つの市場データ行としてのみカウントされ、それらはすべてまったく同じデータを受け取ります (データがリクエストされたかどうかにも当てはまります)。ライブまたは紙の取引アカウント）。
[Q] 有効期限が切れた商品の過去の価格データを取得できますか?
[A] by JGオンラインで表示/返信 (#38987)
最長 2 年前に有効期限が切れたすべての商品の過去の価格データを取得できます。通貨オプションの価格履歴がどれほど長いのかはわかりません。 6か月としましょう。次に、2 年前に有効期限が切れたオプションを選択し、その価格履歴全体を尋ねた場合に取得できる最も古い価格が得られます。その場合、最も古い価格点は 2.5 年前になります。
これはあなたの質問の答えになりますか?
[Q] 毎日の終値を信頼しますか、それとも 1 分データの終値を信頼しますか?
日足（株式）とIBから引っ張ってきた1分足のデータを比較していますが、かなりの違いがあります。
ほとんどの場合、異なるのは終値であり、平均すると約 2% です。これは私にはかなり大きいように思えます。流動性の低い株式を除外すると、はるかに少ないとはいえ、依然として差異が存在します。
ここで読んだところによると、多くの注文が取引終了間際に到着する場合と、一部の注文が終了時刻を数ミリ秒過ぎてから注文される場合に違いが発生する可能性があり、これらの注文は次の分までまとめられるものの、最終的には毎日の取引終了としてカウントされることになります。 。
2% の潜在的な差を考慮すると、バックテストで何を信頼しますか?
[A] by Julian Sommerfeldt julian.sommerfeldt [at ] gmail dot comオンラインで表示/返信 (#42516)
2019 年 5 月 31 日に追加
これらの終値の差について考慮すべき点がいくつかあります: オークション/時間/為替
1) 主要取引所でのオークションからの終値が存在します。このオークションは、取引所に応じて、16:00:00以降いつでも実行できますが、数分後でも実行できます。金融の世界ではほとんどの場合、これが中古終値だと思います。
2) 分単位のデータから得られる価格があり、最後の分は 15:59 であり、16:00:00 ではなく 15:59:59 に終了します。したがって、通常の終値（およびオークション）価格は直前の価格にも含まれません。
3) データを取引所に送信するか、SMART (利用可能なすべての取引所を含む) としてリクエストする場合には、大きな違いが生じる可能性があることに注意してください。
「時間と販売」ウィンドウを調べると、各取引とその取引所および条件 (例: オークションや、取引が最終価格として報告されない理由などの追加情報) が表示されるので、よく理解できます。さらに、分足チャートを見て、「通常の取引時間外のデータを表示」を true に設定します。たとえば、MSFT 2019-05-30 16:00 の取引高は、オークションとこの分足が含まれているため、15:59 よりもはるかに大きくなります。通常、バーは表示されず、通常の取引時間の分データには含まれません。
したがって、主要取引所の終値を知りたい場合は、日次の指定リクエストを実行できます。ただし、MOC 注文 (オークションに参加する) などではなく、SMART をルーティングしている場合は、クロージングに関するデータも興味深い可能性があります。結局のところ、それはあなたの取引アプローチの問題です。
楽しむ、
ジュリアン
[Q] APIを介したVWAP
[A] MattScarpino 著mattscar@gmail.com
2019 年 7 月 18 日に追加
リアルタイムの VWAP 値を探している場合は、reqRealTimeBars を呼び出して whatToShow を TRADES に設定します。 reqMktData を呼び出して、genericTickList に 233 を追加することもできます。
[Q] RTVolume フィールドとは何ですか?
[A] by rwk (この スレッドから)
reqMktDataEx() の 3 番目のパラメータに汎用のティックタイプ「233」を指定して RTVolume をリクエストすると、データは次のようにセミコロンで区切られた 6 つのデータ項目を含む 1 つの文字列として、tickString() へのコールバックで返されます。
1239.25;50;1312388185479;2439001;1244.86324288;false
API グループの Raymund 氏によると、RTVolume は「リアルタイム ボリューム」であり、返される 6 つのデータ項目は、最後の取引価格、最後の取引サイズ、最後の取引時間です(編集者更新: この「最後の取引時間」は、実際には TWS/ゲートウェイ側 (クライアント側) であり、ネットワーク経由で IB によって渡されるわけではありません。これは完全に偽物であり、偽物です。 詳細については、この説明を参照してください) 、総量、vwap、単一取引フラグ。これは良いもので、まさに私が探していたものです。
背景として、市場深度 (DOM) またはレベル II (ただし、後者は特にナスダックを指します) とも呼ばれるオーダーブックの分析には、実際には 2 つのデータ ストリームが必要です。 1 つ目はオーダーブック自体で、これには注文 (数量の入札と各価格でのオファー) のみが含まれ、取引は含まれません。取引はタイム＆セールとしても知られる[ティッカー]テープに表示されます。どちらも、それ自体ではトレーダーのワークステーションを構築するには十分な情報ではありません。
私が抱えていた問題は、reqMktDataEx() が最後の価格と数量を別々のコールバックで返し、それらの関連付けが非常に複雑であることでした。ここでのさまざまな議論を整理しているときに、ラウルのスレッドを見つけました。 RTVolume はまさにこの問題を解決するために作成されたようです。残念ながら、これはほとんど文書化されておらず、セミコロンで区切られた文字列形式は必ずしも最もユーザーフレンドリーとは言えません。ティック汎用パラメータで「mdoff」フラグを指定すると、帯域幅を節約するために不要な市場データがすべてオフになります。ティッカー テープはticString()で返され、オーダーブック（ビッドとオファー）はupdateMktDepth()で返されます。これは衝撃的だ。
これで「ドキュメント」が完成しました。 🙂
[rwk]
—————-そしてまた—-
ところで。上記のメソッドはAPI バージョン 963 に適用されるため、
新しいバージョンでそれ以降に何か変更があったかどうかを確認してください。アップグレードするということは、
当時私がやったように、あらゆる小さなコールバックを再テストする必要があります。
ごきげんよう、
ラウル
[Q] リアルタイムボリュームのタイムスタンプが逆になることがありますか?
この スレッドからの[A]
2016 年 9 月 13 日に追加
はい、存在しないために逆戻りすることがあります。 🙂
「リアルタイム ボリューム タイムスタンプ」は IB によって転送されるのではなく、TWS/ゲートウェイ アプリケーションによってローカルに生成され、約 3 ～ 7 分ごとにローカル時間の情報が調整されます。ローカル TWS/ゲートウェイ時間は、最大 1.4 秒の値で瞬時に調整されます (通常は 100 ～ 200 ミリ秒未満)。 2 つの RTVolume メッセージ間で IB/ゲートウェイ時間が 1.0 秒後方にジャンプする場合、実際はそうではないにもかかわらず、2 番目のメッセージの順序が間違っているように見えます。
pps: あるいは、これらのティックが実際には時々間違った順序で配信される可能性もありますが、IB が時間情報を共有しないことを決定したため、IB のデータ サブスクリプションのみを持っていることを判断する方法はありません。
【Q】S&P500指数構成銘柄を簡単に入手する方法はありますか？
[A] by souqmateこの スレッドから
2016 年 2 月 17 日に追加
… API を使用してこれを行う簡単な方法はありませんが、…
TWS を使用して手動で実行できることに注意してください。
TradingTools -> BasketTrader -> IndexPanel -> インデックスとして SPX@CBOE を選択
金額 = 10000 株を設定し、「注文の作成」をクリックします。
504 行の注文が表示されます ([送信] をクリックしないでください)。
これらは「ファイル」→「SaveBasket」からエクスポートできます。
CSV ファイルにはティッカーが含まれます。
API でも同じことができるとは思えません。
幸運だ
S
エディター アドオン: bash でファイルを解析する場合にも:
結果のファイルは次の構造になります。
（引用）
アクション、数量、シンボル、SecType、Exchange、通貨、TimeInForce、OrderType、BasketTag、OrderRef、OrderCreationTime、
購入、100、A、STK、SMART/NYSE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、100、AA、STK、スマート/NYSE、USD、日、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、100、AAL、STK、SMART/ISE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、100、AAP、STK、SMART/NYSE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、200、AAPL、STK、SMART/ISE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、100、ABBV、STK、SMART/NYSE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:11 EST、
購入、100、ABC、STK、SMART/NYSE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、100、ABT、STK、SMART/NYSE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:10 EST、
購入、100、ACN、STK、SMART/NYSE、USD、DAY、MKT、インデックス: SPX、インデックス: SPX、20160217 15:42:11 EST、
（引用終わり）
# これを解析して 3 番目のフィールドを抽出し、最初のヘッダー行をスキップしましょう。
カット -d 、 -f 3 snp500_basket.csv |尾部 -n +2
あ
AA
AAL
AAP
AAPL
ABV
ABC
ABT
ACN
アドベ
ADI
* * *
【Q】廃止されたシンボルのヒストリカルデータをダウンロードすることはできますか？
この スレッド の Vishruth Vasisthha による[A]
IContract の IncludeExpired を 1 に設定してみてください。
過去の FUT データ。
ありがとう、
ヴィシュルス
[Q] 過去のデータの分割と配当調整を取得するにはどうすればよいですか?
2021 年 2 月 8 日に追加
「TRADES」も利用できますが、分割調整のみとなります。 ADJUSTED_LAST は、分割と配当の両方が調整されることになっています。 (彼らのドキュメントによると): 履歴データの種類 (何を見せるか) さまざまな種類の履歴データはすべてローソク足の形式で返されるため、返される値はローソク足でカバーされる期間中の市場の状態を表します。
|
[Q] 蓄積したボリュームが TWS のボリュームと一致しません。ボリュームはどうなったの？
[A]この ディスカッション を読む
(2021 年 2 月からの更新: ここで「承認済み」の回答をコピー＆ペーストしなかったのは間違いでした。Yahoo フォーラムはもう存在しないため、今では答えが何だったのかを推測することしかできません…) 🙁
[Q] 別々のタスクに別々のデータ/ブローカー接続を使用することは意味がありますか?
TWSに接続することに意味はありますか?
– クライアント ID を使用したデータ関連サービスの場合、および
– 別のクライアント ID を持つブローカー サービスの場合
同じアプリケーションから?このアプローチを使用することに賛否両論はありますか?
ありがとう、
ゾルト
[A]リチャード・L・キング著
私の意見としては、一般的にはあまり有益ではないかもしれませんが、
それはアプリケーションに大きく依存します。
注文関連のイベントをもっと早く取得できると考えているのでしょう
市場データの流れと混同されるよりも、これは真実ですが、
利点は無視できるかもしれません。それ以上はかからないと仮定すると、
ほとんどの場合、ティック イベントの処理にかかる時間は非常に短いミリ秒です
未処理のものが存在しないため、おそらくまったくメリットが得られないでしょう
処理するティック。もちろん、大量の忙しい処理を行っている場合には、
マーケット データ ストリーム、およびおそらく 1 つ以上のマーケット デプス ストリーム、そしてこれは
かなりイメージが変わるかもしれません。すべてはやり方次第だと思います
アプリケーションにとって、注文関連のイベントをタイムリーに受信することが重要です。
たとえば 100 ミリ秒の遅延がある場合 (自然な遅延を超えています)
IB、TWS、クライアント接続への交換) が重要である場合、
価値があるかもしれない。
アプリケーションに多少の複雑さが加わることは間違いないので、私のアドバイスとしては、
最適化については、開発が完了するまでは気にしないでください。
アプリケーションをテストし、明らかな必要性がある場合にのみ実行します。
ここで追加する価値のある点が他にもいくつかあります。
– TWS は、市場データ、履歴データ、およびデータへの個別の接続を維持します。
アカウント サーバー (注文関連のイベントはアカウント サーバーを経由すると想定しています)
アカウントサーバー接続。ただし、これを調べて確認したことはありません。
渋滞）。したがって、注文関連のイベントが発生する可能性があるのは API 接続のみです。
足止めされる。
– 履歴データをリクエストすると、データ全体が返されます。
単一の API メッセージで。アプリが大量の履歴データをリクエストする場合
および/または履歴データの処理には比較的時間がかかります（更新
おそらくチャート)、それならこれらを
個別のクライアント ID。
リチャード
[Q] APIと取引時間は？
[A] リチャード L キング著(ソース)
契約の詳細には、現在および翌日のセッションの取引時間情報が含まれています。私自身は使用していないので正確性は保証できませんが、いつ見てもかなり良いと思います。
あなたがこの情報に気付かずに自動取引システムの作成までこぎ着けたということに少し驚きました。この情報は何年も前から契約の詳細に含まれていました。批判ではなく、単なる観察です。
リチャード
[Q] NYSE株の当日の始値を取得するにはどうすればよいですか？
このスレッド の Josh による[A]
2016 年 10 月 12 日に追加
申し訳ありませんが、ナスダック株は実際にはネットワーク C 上にあります。AAPL はナスダックでネイティブに取引されているため、正式な始値を持っているのはナスダック取引所のみであるため、ネットワーク C のサブスクリプションが必要になります。
ネットワーク A は Nyse の株式の正式なオープンを提供し、ネットワーク B は Arca の株式の正式なオープンを提供します。
ネイティブ取引所へのサブスクリプションがなければ、別の取引所で最初に取引された価格のみを受け取ることになります。
【Q】先物建玉はどうやって手に入れるのですか？
[A1] by mattpearson911
2016 年 11 月 24 日に追加
CME FTP サイトから、毎日の CME/CBOT/COMEX/NYMEX 建玉およびその他の関連情報を取得できます。
ftp://ftp.cmegroup.com/settle/
例: ftp://ftp.cmegroup.com/settle/stlcomex
[A2] by btw12342001
2016 年 11 月 24 日に追加
CME から直接データを取得するだけでなく、データを取得するための API を備えた Quandl からもデータを取得できます。
CME NYMEX WTI 原油先物 (CL) – Quandl からのデータ
[A3]アイザック著
2016 年 11 月 24 日に追加
または、TickData.com をお試しください。
OP からの更新: Tickdata.com は建玉情報 (とにかく毎日しか入手できない) にしか興味がないことを考えると非常に高価ですが、CME FTP サーバーと Quandl は優れたヒントです。
データ サブスクリプション: ボリューム
[Q] ある程度正確な累積量を取得するにはどうすればよいですか?
関連項目も参照してください: [Q] NickSize() NickPrice イベントのシーケンスは何ですか?
関連項目も参照: [Q] ライブ取引の構築
[A] by Mike Smith (この スレッドから)
…
累積量を監視し、各「最終価格」サンプルの「サイズ」パラメータの合計である累積量の合計を保持している場合は、クロスチェックが可能です。累積量の合計が IB が報告した累積量よりも少ない場合は、サンプルが欠落していることになります。私のアプローチは、あたかもその規模で取引が行われたかのように、現在の「最後の価格」でその差を追加することです。これにより、私の累積量が IB の報告された累積量と同期します。累積ボリュームの不一致が発生するたびにこれを行うと、実際に取引所から来たより多くのより小さなサイズの取引と比較して、より大きなサイズの取引が少なくなります。その結果、すべてのボリュームが考慮され、マーケット プロファイル テーブルはかなり近いものになり、人生は快適なものになります。ただし、1 つの点を除いては。 API の累積ボリュームは TWS Chart の累積ボリュームと一致します。
…
そしてbtw12342001によって
…
以前の累積量を覚えていて、それを現在の値から差し引くだけである点を除けば、同じことを行います。何らかの理由ですべての Cum vol (tickType 8) メッセージを取得できない場合を除いて、同じ結果が得られます。これは11月に私に起こりました。それ以来、8を受け取らない場合はtickSize (5)メッセージを使用するようにコードを書き直しました。
…
そしてマイクスミスに戻ります
…
私は両方の画面を目の前にして多くの時間を費やしましたが、対応する reqMarketData の更新なしで TWS が最終価格を更新するのを見たことがありません。これが起こっていることを確認できる唯一の方法は、TWS がそのシンボルのレベル 2 クォートをストリーミングしているかどうかです。これは、より頻繁に更新されることを意味します。こんなこともあり得るでしょうか？
サイズ イベントに関しては、間隔が 10 ミリ秒未満のサイズ イベントを探したり、タイミングにまったく依存したりしません。最終価格イベントの後にサイズ イベントがあり、その間に他のイベントが存在しないものを探します。次に、同じサイズの別のサイズのイベントが到着し、間に他のイベントがなければ、そのサイズのイベントを無視します。次に、IB が報告した累積ボリュームと現在の合計の差を常に確認し、合計が小さい場合は、サイズ値の差を使用して何もないところから「最終価格/サイズ」イベントを作成します。これにより、サイズ イベントを無視すべきではなかったまれな状況に対処し、欠落したサンプルを埋めて全体のボリュームも同期させます。タイミングに頼るよりもこちらの方が確実だと思いました。
マイク
…
ところで、そのスレッドの中で、Richard L King は、IB が 1 つのメッセージ (tickSize と TickPrice) で 2 メッセージを思いつく理由を説明しています。ここにコピー＆ペーストしますので、お見逃しなく：
[Q]すべての取引所からの出来高と 1 つの取引所のみからの出来高を取得するにはどうすればよいですか?
Josh がここで言及した [A]:オンラインで表示/返信 (#42746)
株式の市場データをリクエストする場合、取引所 = "SMART" を使用するのが最も一般的です。これにより、すべての取引所から NBBO と総出来高を受け取ることができます。したがって、返された conId を使用して Contract オブジェクトを作成し、取引所 = "SMART" に設定するだけで、それを使用して市場データをリクエストできます。
(Nasdaq からのみデータをリクエストしたい場合は、リクエストで「NASDAQ」ではなく、exchange = 「ISLAND」を設定する必要があります)。
データサブスクリプション:配当金
【Q】配当金情報を知りたいのですが？
[A] by カート
API について話すことはできませんが、API は決して機能しないと信じがちです
TWSより*優れています*。そしてTWSは再配当がかなり悪いことが判明しました。
しばらくの間、IB の標準スキャナを使用して EFP をいじっていました。
「超過現金」カテゴリの「関連する EFP」を設定します。さてある日、
スキャナーを使用すると、書き込みが非常に魅力的な EFP が表示されました。それは変わりました
配当金が発表されたばかりだったこと（配当金は存在しなかったと思います）
それ以外は予想よりはるかに低かった)、しかしその IB の配当情報はまだ残っていた
当初の予想配当を示しています。これは、EFP の利回りが
評価額は現実と大きく乖離しており、非常に良さそうだった。
将来は、配当が予想されるという知識に基づいてすでに価格が設定されていました。
TWS は間違った配当を表示しただけでなく、
EFP 収量の計算が間違っている。 EFP の作成は一瞬でした
負けましたが、次の日まで知りませんでした。
時間はかかりましたが、同じことが私に何度も起こったと思います
何が起こっているのかを理解するために。
IB が言うように、要するに、配当情報が提供されるということです…何とか何とか何とか。
言い換えれば、彼らには説明責任がほとんどないため、自由に行動できます。
重大かつ明白な方法で失敗し、何の影響も与えません。
したがって、具体的な質問には答えられませんが、IB は信用できません
*何でも*の配当情報。
(API 配当情報は TWS に表示される情報と一致すると思いますが、
確認していません。）
[Q] 配当カレンダー（dec、rec、div、exdiv、金額など）
[A] by Joshオンラインで表示/返信 (#39066)
2017 年 12 月 8 日に追加
配当情報を入手できる他の唯一の場所は、財務概要ロイター レポート (API 関数 reqFundamentals) です。宣言されたがまだ分配されていない配当を含む、過去の配当情報が提供されます。
【Q】配当金の調整は？調整済み前回終値は IB では利用できませんか?
すべての指標が正しく調整されていることを確認し、価格下落が誤ったトリガーを引き起こさないことを確認するために、今後の配当支払いをチェックしようとしています。 IB が配当を調整するという投稿を読んだことがありますが、この例では当てはまらないようですので、経験のある人の意見をぜひ聞きたいです。
たとえば、SPY (S&P 500 ETF) の過去の IB 価格データは生データであるようです。 SPY の分割日は 2013 年 12 月 20 日で、配当額は 0.98025 ドルでした。
取引用の req_historyal_data を介した IB からのデータ:
日付 | 開ける | 高い | 低い | 近い | 音量 |
2013 年 12 月 20 日 | 180.67 | 181.99 | 180.66 | 181.56 | 1,131,358 |
2013 年 12 月 19 日 | 181.19 | 181.70 | 180.71 | 181.51 | 927,670 |
Finance.google.comからのデータ:
日付 | 開ける | 高い | 低い | 近い | 音量 |
2013 年 12 月 20 日 | 180.68 | 181.99 | 180.57 | 181.56 | 197,086,908 |
2013 年 12 月 19 日 | 181.19 | 181.70 | 180.71 | 181.49 | 136,298,872 |
ナスダックからのデータ:
日付 | 開ける | 高い | 低い | 近い | 音量 |
2013 年 12 月 20 日 | 180.67 | 181.99 | 180.5683 | 181.56 | 196,525,900 |
2013 年 12 月 19 日 | 181.19 | 181.70 | 180.71 | 181.49 | 136,558,000 |
Finance.yahoo.comからのデータ:
日付 | 開ける | 高い | 低い | 近い | 音量 | 調整終了* |
2013 年 12 月 20 日 | 180.69 | 181.99 | 180.57 | 181.56 | 197,087,000 | 181.56 |
2013 年 12 月 20 日 | 0.98 配当 | |||||
2013 年 12 月 19 日 | 181.18 | 181.70 | 180.71 | 181.49 | 136,531,200 | 180.51 |
配当支払いの終値を調整しているのは yahoo だけのようです (他の情報源と比較した IB との出来高の不一致に注目するのも興味深いです)。
IB が配当支払いのために過去の価格をどのように調整するか、調整するかどうか、またそれらをどのように予測するかを知っている人はいますか?
ありがとう。
-BB
[A1] souqmate 作成https://groups.io/g/twsapi/topic/4046961
警告: IB は分割と株式配当について株価を調整しますが、現金配当、合併、スピンオフなどについては調整しません。
おそらく、ロイター ストリートイベント カレンダー (10 ドル) を購読すると、将来の現金配当の日付と金額が得られるでしょう。
IBは、20131101にUNTDで起こったように、スピンオフを相殺するために一部の（逆）分割が行われるため、時折、一連の株式の価格が誤って上昇することがあります。 IB と google は係数 1:7 (大幅な上昇) を主張していますが、yahoo はより現実的な係数 5.319:7 (FTD の同時分離のため) を持っています。
API 経由で企業活動カレンダーにアクセスできるようにするには、ここで投票できます。
https://www.interactivebrokers.com/en/index.php?f=2493&sid=9407 (固定リンク)(2017 年 6 月現在も機能します:)
余談ですが、あなたの出来高の不一致は、IB の米国株の出来高における暗黙の係数 100 によるものであり、おそらく特定の取引所 (SMART ではなく) または特定の時間への制限によるものです。 SMART は、12 月 20 日に 1,466,263 のボリュームを提供します。
スークメイト。
API 経由で企業活動カレンダーにアクセスできるようにするには、ここで投票できます。
[A2] souqmate@yahoo.comより
投稿する前にアーカイブを検索してください。例を参照してください。
https://groups.io/g/twsapi/topic/4046961
BP@BVME (20140310 に 1:10 分割、3 日間データがなかった) や IMI@LSE (20140217 に 7:8 分割、 2 週間データがありませんでした)。
さらに、分割はありませんが、いくつかの要素が任意に挿入されます。たとえば、20130102 より前の SWN@NYSE の価格は 100* 大きくなります (以前はそうではありませんでしたが、その後、そのようなものが突然表示されます…)。
そして補足として（ここでは分割はありません）、カナダ先物などの流動的なシンボルでもいくつかのギャップが現れることに注意してください。これらのシンボルには20140312（TSE60、CGB、BAX）のデータがなく、IBはデータを永久に失っています。
グラスが半分空ではなく半分入っているのが見えるようサポートしてくださった IB に感謝します。
スークメイト。
[Q] API reqFundamentals がインデックスの以前の配当データを返しません
[A] Josh と他のカップルによるオンラインでの表示/返信 (#42651)
2019 年 7 月 24 日に追加
残念ながら、TWS API からのインデックス データに利用できる同様のものは実際にはありません。
回避策として:
インデックスの場合は、SPY for SPX などのプロキシを選択する必要があります。
または、データの観点からは株式配当と実際には何ら変わらないETF配当として。
[Q]データ サブスクリプション: カレンダー イベント
こんにちは、みんな、
TWS のイベント カレンダー オプションに移動すると、今後のさまざまなイベントが表示されます。たとえば、企業収益に興味があります。
カレンダーのイベントに関連する API がいくつかあるようですが、データをダウンロードするには Wall street Horizon へのサブスクリプションが必要なようです。また、サブスクライブするページにもアクセスできないようです。もしかしたらプロのアカウントのみが利用できるのでしょうか?
これは事実でしょうか、それともプログラムでこのイベント データにアクセスする方法を誰かが見つけたのでしょうか? TWS からデータを「スクレイピング」できるかどうかを確認するために、ある種の Windows 自動化ツールを検討しようと考えています。
[A] alpha < pmularien@gmail.com >オンラインで表示/返信 (#44591)
2020 年 6 月 17 日に追加
はい、このデータは Wall Street Horizon サブスクリプト ([ユーザー設定] > [リサーチ サブスクリプション] で利用可能) を使用して取得できます。私は専門家ではないので、サブスクリプション (月額 5 ドル) を契約しています。
Python (IB-insync) API を使用している場合、このデータを取得するコードは次のようになります。
ib.reqFundamentalData(contract, 'CalendarReport')
これにより、解析が非常に簡単な XML データが返されます。
[Q] クロスプライスにつながる入札/売値の無効な更新を受け取りました。なんと？
[A] by Kurt (この スレッドから)
> IB が入札/売値の更新を無効な順序で送信する場合があることに気付きました。例えば
> ビッド/アスクは 45.47/45.48 でした。その後、IB は新しい入札 45.99 を送信し、クロスにつながります。
> 価格 45.49/45.48。次の瞬間、IB アップデートは 45.50 を要求し、価格は
> 通常に戻ります – 45.99/45.50。
>
> ビッド 45.49 / アスク 45.48 というくだらない価格を皆さんはどう扱っていますか?
> ありがとう
一般的な答えがあるかどうかはわかりません。潜在能力は常にある
無効な/古い引用符の場合。あなたが入札や質問を受けているとは思えません
文字通り「間違った順序」で。むしろどちらかが間違っているのです。だった
両側のサイズがゼロ以外ですか?何の楽器かは言いませんでしたね。
私はおそらくクロスビッド/アスクではなく、非常に狭いビッドアスクまたは同等のビッドアスクを見たことがあります。
基本的に、入札または質問は実際のものではなく、問題はどちらであるかです。私
ある命令に対する命令が実行されない場合、それを見つけるのは困難です。私
私が見たすべてのケースで、問題は 1 人に特有のものであったと信じています。
「SMART」相場に寄与する悪い相場があった取引所。一度
問題を認識し、引用符行を手動で入力するために介入しました。
TWS ですが、reqMktData を使用するとかなりうまく自動的に実行できます)、
一般に、プライマリ交換には問題がなく、
特定の取引所（例：BOX、おそらく ISE または ISLAND でした）
悪い入札や質問がありました。
この問題はここで認識されており、その方法についての代替案が議論されています。
最も効果的に対処するために。人々は、
最もボリュームのある取引所などですが、主な取引所は次のとおりだと思います。
一般的には良いです。そうすれば、可能性の低い企業から見積もりを取得できます。
SMARTよりも汚染源。 SMART は、次のような場合に大きな責任を負うことがあります。
人々がコメントしました。基本的に、取引所の見積もりが悪い場合は、
SMART は悪いので、見積もりに SMART を使用することで可能性を最大化できます
問題のために。したがって、これが気になる場合は、次のサイトに見積もりをリクエストしてください。
特定の取引所であっても、SMART で注文すると、
注文の詳細に応じて手数料と約定のメリットが得られます
タイプなど
このトピックに関する以前のコメントをアーカイブで検索してみるとよいでしょう。
おそらく6か月以上前だと思います。メール内で簡単な検索を行う
フォルダを見ると、2009 年 6 月 22 日の投稿を含むスレッド「入札/質問がスタックしている」が表示されます。
2009 年 6 月 23 日。しかし、もっと最近のもので、さらに追加されたものがあると思います
観察。何も見つからない場合は (yahoo アーカイブが便利です)
PITA – 独自のリポジトリを持つ方が良い) ポストバックして、別のリポジトリを取得します
見て。私は過去 2 年間、この件に関するほとんどの議論に関与していたことを知っています
または 3 年であれば、検索の別の手がかりが得られる可能性があります。
-カート
[Q] IB の引用符が交差しています (再度)
2015 年 4 月 27 日に追加
TWS のマーケット クロスに気づきました。画面上の相場は数秒間 11.45 x 11.44 として表示されていました…
[A] Mike Smith (ここにあります)
交換には何を指定しましたか? SMART を使用した場合は、クロスマーケットが表示されます。 BAC の場合は、交換に NYSE を使用する必要があります。 SMART は、注文をルーティングするのに最適な取引所を選択するように設計されていますが、市場データに関しては、その銘柄の取引量が最も多い取引所を指定することほど優れたものではありません。少なくともそれが私が実際に発見したことであり、その「理由」は別の問題です。
マイク
- - また - - -
TWS ウィンドウに BAC を入力するだけで、回線ごとに異なる交換を選択すると、何が起こっているかがわかります。 SMART も 1 行に含めます。すべての買値/売値を監視すると、SMART がどの取引所からデータを取得したかがわかります。正確に何をしているのかは不明ですが、そのようにさまざまな取引所から価格を取得すると、間違いなく奇妙な結果が生じる可能性があります。ある取引所では同じ買値/買値が何分間も表示され、別の取引所では豆が飛び跳ねるように跳ね返る場合がありますが、SMART は時折、取引可能な価格ではない「死んだ」取引所から非常に古いデータを提供することがあります。
マイク
—————そしてまた————–
これは、取引所の 1 つが交差していることを意味します。 SMART には、すべてのデータが含まれます。
彼ら。 1 つの取引所を通過すると、「最良」の取引所も通過します。
マイクが言ったように、取引所ごとに市場データ ライン (または API リクエスト) を作成する
どれが交差していて問題を引き起こしているのかがわかります。ほとんどの場合
場合によっては、不良データがマイナー交換の 1 つから発生しているか、少なくともそうでない場合があります。
プライマリ交換から。
-カート
[Q] スナップショット市場データと「リアルタイム」データ。
スナップショット市場データは正確性や信頼性が低いなどと言っている人を見たことがあります。なぜそれが劣っていると考えられるのかについて、もう少し詳しく知りたいと思っています。
ストリーミング サービスは正常であったのに、スナップショットが間違ったデータまたは少ないデータを提供していることをどこで観察しましたか?
スナップショットにはすべてのフィールド (入札、売値、オープンなど) が提供されない場合がありますか?
スナップショットとリアルタイム データのレイテンシーについて何か議論はありますか?たとえば、ティッカー価格が 19.10 ドルから 19.11 ドルに更新された場合、スナップショット リクエストはリアルタイム ストリームからどれだけ遅れるでしょうか?
[A] リッチ・ホロウザック (別名「Prof. H.」)
2016 年 8 月 16 日に追加
reqMktData を使用する場合、スナップショットとストリーミングの違いは、各フィールド (入札価格、売値、入札サイズ、売値サイズ、最終価格、出来高など) に値が提供されるとスナップショットが完了し、リクエストが事実上キャンセルされることです。前に、フィールドが過去 11 秒以内に更新されていない場合、スナップショットでエコーバックされないという注意点を指摘しました。
http://interactivebrokers.github.io/tws-api/top_data.html#md_snapshot
すべてのフィールドが必要な場合、またはエコーバックされる値を 100% 確実に取得する必要がある場合は、フィールドが値を取得するまでストリーミング データをリクエストし、その後自分でリクエストをキャンセルする必要があります。
これに代わる方法は、5 秒ごとに一連のデータを取得するリアルタイム バーを取得することです。
reqMktData を使用する場合、スナップショットとストリーミングの違いは、各フィールド (入札価格、売値、入札サイズ、売値サイズ、最終価格、出来高など) に値が提供されるとスナップショットが完了し、リクエストが事実上キャンセルされることです。前に、フィールドが過去 11 秒以内に更新されていない場合、スナップショットでエコーバックされないという注意点を指摘しました。
http://interactivebrokers.github.io/tws-api/top_data.html#md_snapshot
すべてのフィールドが必要な場合、またはエコーバックされる値を 100% 確実に取得する必要がある場合は、フィールドが値を取得するまでストリーミング データをリクエストし、その後自分でリクエストをキャンセルする必要があります。
これに代わる方法は、5 秒ごとに一連のデータを取得するリアルタイム バーを取得することです。
[Q] スナップショットをリクエストすると市場データが停止します。
特に次のような質問がありました。
こんにちは、
マーケットデータの取得に時々問題が発生することがあります
特定の値に「固執」し、実際には変更しているにもかかわらず変更しない
変化。
今日、「ES」で1時間以上これが起こりました。
あるシステムでは値がスタックしてしまい、毎回市場データをリクエストすることになります。
分（スナップショット）、毎分同じ応答を受け取りました。
別のアカウント、同じコードを持つ 2 台目のコンピューターでは、この問題は発生しませんでした。
今回もそうでしたが、その後にも起こりました。
また、私が受け取った応答の順序を誰かが説明できますか。
価格、価格、価格、サイズ、価格、価格、価格、ジェネリック、ジェネリックが表示されます。
ありがとう、
レベッカ
[簡単な回答]スナップショットは使用しないでください。
[A1] 議論を参照:
https://groups.io/g/twsapi/topic/4047462#32976
[A2] カート著
私はスナップショットをあまり使用したことがありませんでした。一度遊んでみたら本当に見えました
奇妙なこと。私が彼らに報告すると、rwkはこう答えました。
メッセージ履歴を隠す
2010 年 9 月 17 日午前 6 時 12 分に、「rwk2095」< rwk2095@… > は次のように書きました。
> スナップショットが機能していないようなので、スナップショットの問題を解決することはできません
> 私にとっては。
私が抱えていた問題の詳細を知りたい場合は、
スナップショット、私の投稿を参照してください
「[TWS API] 今日は AAPL に「最後」はありませんか?」 2010 年 9 月 16 日に
たぶん、それらは機能しないだけです！
===
ただし、他の人はそれらを使用していて問題がないようです。多分
スナップショットは特定の機器ではうまく機能しませんか?
この件については IB に電話してみます。本当は自分で電話すべきだった
手遅れになる前に。最近も何度か繰り返されているように
特定のサーバーに起因する問題が報告されています。
プール。これはあなたの報告内容と「ある程度」一致していますが、一致している可能性があります。
別の展開。しかし、差し迫った問題がそれに関連している場合は、
接続している「ファーム」内の特定のサーバーを呼び出す必要があります。
マーケット時間中および接続が失われる前に IB、それ以外の場合は不要
診断することができます。
>また、私が受け取った回答の順序を誰かが説明できますか。
> 価格、価格、価格、サイズ、価格、価格、価格、ジェネリック、ジェネリックです。
ティック番号の値がなければ、これはあまり意味がないので、再投稿したほうがよいでしょう。
そうすることで、人々は考え直すことなく答えられるようになります。
そして、明確にしておきます（私はそうではありませんでした）ティック番号とは、BID、ASK、LASTなどを意味しました。
価格、サイズ、ジェネリックは二次的な情報であり、一度知ってしまえば冗長です。
BID/ASK/LAST などを指定したため、ここでそのように報告すると、
いくつかの情報が戻ってきました。については以前にも議論がありましたが、
ダニが到着する順序とそれが何を意味するか。その一部は、
いわゆる「サンプルコード」（実際にはライブラリ）、自分で読むことができます。
つまり、tickPriceとtickSizeが呼び出される場所はソースからです。
コードベースの一部である IB によって提供されるコード。
-カート
[Q] reqRealTimeBars と reqMarketData – リアルタイム バーを取得するにはどうすればよいですか?
[A] byカート
reqHistoricalData では 3 分足を使用できますが、提供できるのはバックフィルのみです。
reqRealTimeBars が必要です。ただし、3 分のオプションはありません。バーが来る
購読すると 5 秒ごとに。それらを合体させる必要があります。
5 秒足を 3 分足に変えるのは十分簡単です。
ただし、リアルタイムに問題があるという人々がここに投稿していることは知っています
バー。詳細は思い出せないのでアーカイブを見てください。一部
重要なのは、人々はバーがストリーミング データと一致することを期待しているということです。
しません。しかし、私は他の問題を覚えているようです。
そうであってはなりません。
リアルタイム バーに問題がある場合は、独自のバーを構築するという別のオプションもあります。
ティック データ (reqMarketData) からのバー。
さらに別のオプションは、先ほどと同じように、タイマーで reqHistoricalData を呼び出すことです。
示唆している。ただし、次のことを行う必要があるため、レイテンシーはさらに悪化する可能性があります。
リクエストを行う前に、最後のバーが完全に完了するまで待ってください。
そうしないと、最後のバーが切り捨てられます。 (おそらくロジックを持っているはずです
「終了」レコードの終了時刻に基づいて切り捨てられたバーを検出するには、
必要に応じてリクエストを再発行し、タイミング ロジックを調整して最小化します。
切り捨てられずにレイテンシを短縮できます。) reqHistoricalData を使用すると、次のことができます。
単一のバーをリクエストします (私がテストした場合)。
-カート
[Q] IB の取引可能なすべての契約のリストを取得するにはどうすればよいですか?
[A]シェーン・クソン 著
今週末は少し時間があったので、クローラーを起動しました。引き下げる
商品ページには224の取引所の216,000件の契約が掲載されています。
私はこれを「IBContractExtractor」と呼び、GPL の下でリリースしました。ここから入手できます:
http://sourceforge.net/projects/ibcontractextra/
Shane はそれを GitHub ( https://github.com/shanecastle/IbContractExtractor ) に移動しました。
これは C# で書かれており、HtmlAgilityPack を使用します。パックはすごいですね
ライブラリは、HTML の解析からあらゆる面倒な作業を取り除き、完全な OO を提供します。
HTML のコンテンツへのインターフェイス。今はただ引っ張り出すだけです
契約書のある時点で、他のすべての詳細を抽出するようにします。
未来。結果のテキスト ファイルは約 12 MB ですが、圧縮すると 3 MB になります。
Mac/Linux で実行できるかどうかはまだわかりませんが、.net 4.0 を使用しました。
特徴。実行するには .net 4.0 が必要です。
ぜひ試してみてください。どのようにうまくいくか教えてください。
–シェーン・クッソン
[Q] lastSize=0になる場合があります。なんと？
[A] by mikesmithv (ソーススレッド:ここ)
好奇心が勝ったので、デバッグ ログをオンにしてコードを確認しました。私の言ったことは正しいことが分かりました。 lastSize イベントを無視するとデータが失われますが、それは複雑です。少し前に書いたコードを思い出して記憶を更新する必要がありましたが、あまり変わっていないようなので、その価値について詳しく説明します。
まず、サイズイベントと累積ボリュームイベントの両方の在庫について、すべてのサイズに 100 を掛ける必要があります。ここで述べたことが機能するには、コード内で拡張された数値を保持することが重要です。
次に、1 (または 100 倍) より大きいサイズ イベントについては、同じサイズのサイズ イベントの直後に発生し、かつそのサイズ イベントの前に価格イベントが発生した場合は無視します。これは、何年も前から存在する悪名高い「サイズ重複バグ」です。これを無視しないと、現在の合計サイズが IB によって報告される累積ボリュームを徐々に上回ることになります。
最後に、奇妙な工夫として、最後のサイズがゼロの場合、それを無視してはなりません。これらのゼロサイズのイベントは、前述したように 100 未満の取引を表します。すべては 100 で除算されるため、送信される前にゼロに丸められます。サイズがゼロの異なる価格で複数の取引を行うことができます。つまり、価格は変動していましたが、累積出来高のレーダーの下にあった出来高であったため、累積出来高デルタだけを見るとこれを見逃してしまいます。たとえば、価格 $100、サイズ 10、価格 $101、サイズ 20、価格 $102、サイズ 30 の取引がある場合、サイズ 0 の価格イベントが 3 つ表示され、10+20+30 が以下であるため累積出来高は変化しません。 100 は、累積ボリュームを 1 つ増やすのに必要な値です。これは私が言及している IB の累積ボリュームであり、あなたの累積ボリュームは 100 倍です。
したがって、株式のサイズがゼロである場合 (ちなみに先物では決して起こりません)、その価格である程度の出来高が発生したことになります。問題はいくらですか？わかっているのは、それが 100 未満であるということだけです。私は、20 が適切な平均であることがわかりました。これは、マーケットプロファイルの合計を一致させるのにうまく機能し、少なくとも私が考え出したより複雑なスキームにもうまく機能しました。この数字を考える際には、いくらでも創造力を発揮できますが、サイズが 0 の場合は、最終価格で一部の数量を掲載することが重要です。株価が 100 未満の出来高で取引されたことを示すため、これは少なくとも 1 である必要があります。
[Q] 新しいバーの正確な開始はいつですか? (ティックデータから) 手作りしたバーは、IB から受け取ったものとまったく同じバーになりますか?
[A] by Kurt ( src )
IB のバーに関する私の記憶は、新しいバーの始まりであることを知っていることです。
サンプリングされたデータ フィードの反対側にいる私たちができるときに起こります。
特定することは期待できません。実際、新しいバーが始まる瞬間は
サンプリングされたデータ フィードにティックとして *存在*します。それで、あなたが得ているのは
基本的に「エイリアシング」と同等です。価格がその「前」に跳ね上がった場合、
あなたは新しいバーだと思うポイントですが、IB のバーのタイミングはその瞬間があったと考えています。
新しいバーが開始された*後*、間違ったバーに正しいデータが表示されることになります。
タイムスロット。ほんの1/10秒のタイミングの違いだったかもしれないが、
しかし、間違ったポイントでサンプリングすると、まるまる 1 秒であるように見える可能性があります。
オフ。したがって、今回は時間が歪むことが予想できます。それが最後のプロットです。
示しているようです。
- また -
IB のバーが基づいているという情報はありません。
サンプリングされたデータ。
「ティックデータ」については、 2 つの別々の接続で取得されると聞きました。
異なるサンプリング。したがって、（すでに明らかではなかったとしても）次のように思われます
IB のシステムは、サンプリングされていないデータにアクセスできます。彼らは使うだろうと思います
このような非サンプリングデータを使用して履歴バーを生成します。
重要なのは、履歴バーがサンプリングされていないデータからのものであっても、
バーという意味では、サンプリングされた「ティック データ」と一致するとは期待できません。
サンプリングされたティック データから再現できます。
–カート
- また -
確かに、IB はサンプリングされていないデータ ストリームから入力を取得するに違いありません。
また、IB は、少なくとも外国為替では 300 ミリ秒ごとにサンプリングされると言いました 。
明示的ではなかった。
私は彼らがそれをサンプリングして、ティックを1秒あたり3に減らすのではなく、
ライブフィード上のランダムな量。
このことからわかることは、(a) あなたが言及したことは、あらゆるものの実際の O と C についてです。
結果として得られるデータセットのバーは架空のものであり、(b) H と L はより低い可能性があります。
または、それぞれ実際の H と L よりも高い値です (もちろん (c) H と
L は、特定の時点のどちら側のバーにも表示される可能性があります)。
–アダム・ハーディ
[Q] IB が単純なリアルタイム ティック ストリームではなくサンプル データを使用するのはなぜですか?別名、tickSize イベントの「ファッジ」要素。
[A] リチャード・L・キング著
見る：
https://groups.io/g/twsapi/topic/34510650
https://groups.io/g/twsapi/message/8821
実際、IB は何も蓄積しません (総量を除く)。 スロットル。彼らはすべての取引やすべての入札と質問を報告しているわけではありません。 以下のような興味深い内容が見つかるかもしれません。いくつかの投稿を合成したものです ここ数か月で私はここで作成し、いくつかの非常に集中的な内容に基づいています 数年前に私が取り組んだ、IB データ フィードがどのように機能するかについての研究 ( 私が見る限り、それは今日でも同じように機能します）。 IB データ フィードは、市場のニーズに確実に対応できるように最適化されています。 市場がどんなに忙しくても。この結果、IB はすべてのレポートを報告するわけではありません。 あらゆる取引所でのあらゆる金融商品の取引、またはあらゆる入札や要求。 これを達成するために、各製品の価格スナップショットを効果的に送信します。 一定の間隔で楽器を動かします。この間隔は300くらいらしい ミリ秒。買値、売値、最終値のそれぞれについて、現在の価格を比較します とサイズは最後のスナップショットの値になります。値段が違うなら 価格とサイズの両方を送信します。価格が同じでサイズが同じであれば、 サイズのみをお送りします。価格もサイズも同じであれば、 どちらも送信しません。最後のスナップショット以降に取引があった場合、 （累積された）量を送信します（つまり、価格とサイズが送信されていない場合） 変更されましたが、1 つ以上の取引がありました。これは次の方法で検出できます。 ボリュームが増加します）。 これにより、IB は各ティッカーに必要な最大帯域幅を把握し、 したがって、顧客ごとに（ティッカーの数が限られているため）、 その負荷に対処できるようにサーバーのサイズを調整できます。市場になったら 非常に忙しいですが、それでも更新を送信するだけなので違いはありません たとえ100回の取引があったとしても、1秒間に3回程度 その一秒の間に。これにより、他のすべてのデータ フィードが発生する問題が回避されます。 混雑時にはデータが市場に大きく遅れることがあります。 (これまでに使用した他のベンダーでは、データが 市場より最大 2 ～ 3 分遅れる可能性があります)。 この手法には腹立たしい副作用があり、それが代償です。 スナップショット間の移動はまったく報告されない場合があります。たとえば、 スナップショット 1 の最後の価格は 100 で、その後価格は 102 まで上昇し、その後 スナップショット 2 までに 101 に戻ると、スナップショット 2 で報告される価格は 101 になります。 102 の価格はまったく報告されません。これにより、時折 バーの高値と安値が不正確ですが、まれに 1 ティック以上の差があります。 それが重要であるかどうかは、使用される取引戦略に大きく依存します。 私の経験では、不正確さがある場合の数は、 重大な影響は無視できるほど小さいですが、それは当然のことです。 部分的には私が使用していた特定の戦略の関数ですが、次の点に注意してください。 1分足から積極的に取引し、非常にタイトなストップを使用したため、 不正確さに非常に敏感になると思うかもしれません。それに、時々、 不正確さはあなたに不利に働き、時にはあなたを助けることもあるので、全体として私は かなりバランスが取れていると思います。 上記は完全な説明ではありませんが、基本的なメカニズムを説明しています。あ ただし、注意してください。これは正確な科学ではありません。できたらいいですね 私が言ったことはそれがどのように機能するかを正確に説明したものですが、奇妙に感じるでしょう 事前のサイズを指定せずにボリュームを更新するなど、時々発生すること ボリュームの増加が正確な倍数ではないメッセージ 最近のサイズ メッセージ、または同時に送信された複数の最後の価格/サイズ メッセージ 時間メッセージ、または以前よりも小さいボリュームのメッセージ!しかし ほとんどの場合、私の説明は正確です。 もう 1 つの重要な点は、スナップショットが異なる時点で取得されることです。 さまざまな TWS セッションの時間。これはIBの観点からすると賢明です それは、何千ものすべてのユーザーに更新を送信する必要がないことを意味するためです。 ユーザーを一度に。しかし、これには興味深い副作用があります。 TWS のコピー (同じアカウントへの異なるログインなど) がわずかに得られます スナップショットが行われていないため、それらとは異なるデータ 同時に。 ちなみに、上では触れなかった注意点が 1 つあります。それは、両方の価格が サイズメッセージが (単一の TICK_PRICE ソケットメッセージで) 送信され、TWS も送信されます。 別の TICK_SIZE メッセージでサイズを再度送信しますが、ボリュームは 正しく更新されたのは 1 回だけです。この重複の理由は次のとおりだと思います バージョン 2 の TICK_PRICE メッセージが導入される前は、メッセージには サイズフィールドがあるため、価格とサイズは常に個別に送信されます: TWS が送信しなかった場合 重複したサイズを送信してから、別の TICK_SIZE に依存するプログラムを送信します。 メッセージは修正されない限り正しく機能しなくなり、 再コンパイルされました。 バックテストには、常に IB リアルタイム データを使用してきました。 SQL データベース、私はそれに完全に満足しています。事実は、 バックテストは、特に戦略が立てられている場合には、ほとんどが近似値にすぎません。 あらゆる種類の指値注文を使用します。成行注文または逆指値注文では、 注文は完了しているはずですが、どのくらいの価格になるかわかりません 一方、指値注文では、少なくとも最悪の価格を知ることができます。 満たされていただろうが、完全に満たされていたかどうかは確信が持てない （価格が実際に制限を超えない限り） – そしてあなたの戦略は次のとおりです 注文があったかどうかに応じて、その後の動作がまったく異なる 満たされているかどうか。 収集したデータをバックテストに使用する代わりに、次のことが考えられます。 代わりに、IB が提供する履歴データを使用してください。それが反映されていると思います。 取引所から送信された完全な情報。ここでの問題は、IB が リアルタイム データが維持されている期間であっても、履歴データは常に完全であるとは限りません。 データフィードは大丈夫でした。を収集するハイブリッド アプローチを試すこともできます。 リアルタイム データを作成し、後で任意の履歴データで更新します IBから入手できます。しかし、私の考えでは、これはやりすぎです。 リチャード |
また、株式データはすべて 250 ミリ秒でサンプリングされ、オプション データはすべて 100 ミリ秒でサンプリングされます。
[Q] レベルIとレベルIIのデータの違いは何ですか？
この スレッド で[A]が見つかりました
以前のスレッドカウント市場データイベントを参照して、私は次のことを行いました。
レベル 1 アップデートとレベル 2 アップデートの数を数える小さな分析
インサイドマーケット。
私の先物取引プラットフォームは現在の買値/売値に依存しています。
通常はレベル 1 アップデートから派生します。
しかし、私の分析によると、レベル 2 (DOM、マーケット デプス、ブック)
インサイドマーケットであるポジション 0 をその約 5 倍のレートで更新します。
したがって、入札サイズは 1 分間に約 200 回程度更新される可能性がありますが、
DOM 上の内部入札の更新が 1000 件ほどある可能性があります。
一見すると、それはおそらくレベル 1 よりも最新の情報です。
アップデート。うーん、うーん…… 🙂
したがって、これをさらに使用できるようにコードをレビュー/アップグレードする必要があると思います
(派生) レベルの最新の「最新」値としての頻繁な DOM 更新値
1 ビッドまたはアスク価格。どう思いますか？
【Q】リクエストIDはどれを使えばいいですか？
[A] by カート
あなたの質問に答えられる人は、おそらく単純に次のようなことをする人です。
あらゆる可能性を試した。一度やりましたが、スキャナー用ではありませんでした。しかし、思い出してみると、
各タイプのリクエストには、リクエスト ID 用の独自のスペースがあります。だからあなたはおそらく
たくさんの自由があります。しかし同時に、IDを選択することもできます
自分自身の追跡に便利です。
そのために、すべてのリクエストに対してグローバルに一意の ID を使用します。
リクエスト タイプ *注文を除く*。これには、注文に固有のメソッドを使用します。
同じリクエストが他のリクエストに使用されているかどうかを無視するオーダー
種類。しかし、それは単なる開発上の偶然です。
他のものは、異なる範囲で一意のリクエスト ID を使用します。
リクエストの種類を識別するため、リクエスト ID から直接、リクエストの種類を知ることができます。
関連付けられていたリクエスト。
だから好きなことをすればいいのです。しかし、あなたの元々の問題に関しては、私には何もありません
アイデアですが、リクエスト ID の一意性に関する問題が発生したことを覚えています。
マルチスレッドコーディングの問題、クリティカルセクションの問題、あるいはそうでないもの
コード内の適切な位置でインクリメントします。それが当てはまるかどうかはわかりません
あなたへ。
-カート
[Q] 歴史はどこまで深く遡ることができますか?
[A] ドミトリー著
通常は -1 年しか遡れませんが、さらに支払う (または取引する) と、最大 -4 年まで遡ることができ、2010 年 1 月のどこかに戻ります (希望する 2000 年からはかなり遠いです:(
このページからの引用:
- 同時リアルタイム市場データ行の数に応じて、履歴データのリクエストは 1 暦年以上遡ることができます。
市場データ行の数 | 歴史的なデータ リクエスト制限 |
499未満 | 1年 |
500 – 749 | 2年 |
750 – 999 | 3年 |
1000 | 四年間 |
市場データのラインは、毎月の手数料額、株式の額、および Quote Booster サブスクリプションに基づいて増やすことができます。
[A2] by souqMate
履歴データのその表は株とFXのみのものです。
先物契約は決済されてから 2 年後に IB のデータベースから削除されます。
したがって、たとえ十分な料金を支払ったとしても、2年を超えることはできません。
オプション（先物または株式）は決済後すぐに削除されます。
スークメイト
[Q] 歴史のバグ？値段はするけどボリュームがない、その他の歴史的な「穴」！
[A] by カート
過去のデータに欠けているものとしては、たとえば特定のバー サイズが考えられます。
特定の楽器の「what」パラメータの特定の値
私が引用した GLD の例のような特定の機器など。そうだと思います
オプションのインプライド・ボラティリティは、GLD では決して利用できません。
十分に長く取り組んでみると、IB の「提供物」がいっぱいであることがわかります。
穴の。時間の穴ではなく、製品の一貫性の穴です。
何が取得できるのか、何が取得できないのかについてのドキュメントはありません。
IB が提供するか提供しないかのどちらかです。多くの場合、エラーはありません
というメッセージが表示されますが、単にデータが不足しているだけです。
-カート
[A2]ロン・ヒンチリー 著
株式では、取引が行われないときにデータの欠落が発生します。私は時々 1 秒のデータをダウンロードしますが、NASDAQ-100 銘柄によっては、一日の始まりに 1 ～ 6 秒、場合によっては 1 時間欠けているものもあります。毎晩実行するときは、2 週間 SQL に戻って穴を探し、30 分以内に 5 秒を超えるデータがあれば、欠落しているデータを再リクエストします。データが欠落したままのようですが、確認していません。取引の開始には 1 ～ 5 秒のギャップがあることがよくあります。
–ロン
[Q] オプションのヒストリカルデータは？
[A] by カート
IBはオプションの1日データを提供していないと思います。同じ結果が得られます
あなた。ただし、1 時間足をリクエストするとデータを取得します。しかし、そうはなりません
あなたを1年前に戻します。 2ヶ月くらいは戻れそうです。 TWS
チャートも同様に動作します。
IB の履歴データへようこそ。まあ、あなたは新人ではないので、何とも言えないかもしれませんが、
ハンドルから確実に。 （人々に自分の名前に署名してほしいと思います、特に
複数のメールアドレスを使用している人。もう十分大変ですよ。）
-カート
【Q】履歴データはどのように保存するのですか？
[A] Dmitry著(この スレッドから)
2017 年 5 月 25 日に追加
アレックス、
1 回のリクエストで 2000 個の 1 秒バーをリクエストできます (33.3 分をカバー)。次のリクエストを固定時間だけ進めるだけでは機能しません。市場のオープン時間近くにリクエストすると、IB は 2000 バーを送り返します。そのうちの一部は 1 日のもので、一部は前日のものです。さらに、リクエストが週末/休日に近かった場合 (たとえば、別の endDateTime がたまたま月曜日の午前 9 時 40 分だった場合)、2000 バーのうちの一部は月曜日に属し、一部は金曜日の午後 3 時 45 分から午後 4 時ごろに属します。
N 日間の継続的な履歴を取得するには、基本的に次の 3 つの手順を実行する必要があります。
1) 関心のある期間の終わりを指す endDateTime を指定して reqHistoricalData を送信します
2) 2000 個のバーを取得すると (historyalDataEnd())、最も古いバーが取得されます。
十分な時間があるかどうかを確認します（つまり、最も古いバーのタイムスタンプが取得しようとしている時間範囲の開始よりも古いかどうか）。
3) 十分でない場合は、endDateTime 引数をステップ #2 の最も古いバーのタイムスタンプに設定して別の reqHistoricalData() を送信し、ステップ #2 にループします。
上記の 3 つの手順により、リクエスト間で重複のない、最大限に連続した適切なバーのセットが作成されます。完全な 2000 バーをそれぞれ永続ストレージ (DB など) に保存しておくことをお勧めします。これにより、その時点の履歴データに興味があった場合に再利用でき、再度リクエストする必要がなくなります。 , ただし、履歴バーに永続ストレージを追加するにはさらに作業が必要です。潜在的な問題について少し説明します。
[保存された 1 週間分のデータが継続的かつ完全であるかどうかをどのようにして確認しますか?]
1 週間のデータに対してバックテストを再実行したいとします。簡単にするために、特定の機器について以前に保存されたデータはありません。ステップ 1、2、3 をループします (レート制限に達しないように、リクエスト間に 10 秒のスリープを挟みます)。 1 RTH=true 日は、取引日あたり 6.5*60*60 = 23400.0 バーとなり、これは 23400 / 2000.0 = 11.7 の過去のリクエストに相当し、リクエスト間に 10 秒のギャップがある場合、1 日を 1 回ダウンロードするには約 120 秒 = 2 分になります。 (または、異なるポートの同じボックスで実行されている紙のアカウントと実際のアカウントから履歴を同時にダウンロードすると、2 倍の速度になります。)
1 週間のデータには約 5 x 2 = 10 分かかります。したがって、10 分以上後にループが終了し、バックテストが何度も実行され、満足することになります。
プラットフォームを再起動した翌日、さらにいくつかのアイデアをテストするためにまったく同じ時間範囲でプレイを続けたいと考えていますが、問題は次のとおりです。要求された 1 週間の期間に完全なセットがあるかどうか、プラットフォームはどのようにして知るのでしょうか。覆われていないギャップはありますか?実際には 23.4,000 バー未満になる場合もあるため、1 日あたりのバーの正確な数に依存することはできません。また、取引日の半分が早い時間に取引が終了したり、休日が重なって長い週末があり、丸一日が欠けてしまうこともありますが、それでも 1 週間は連続しているため、何もリクエストする必要はありません。すべての 1 週間の保存バーが IB から入手可能な 1 週間のバーと同じであることを確認するためにさらに 10 分待つことは意味がありません (ちなみに、IB 側で調整される場合があるため、完全に同じセットにはなりません) 1週間のバー!-))
[既存の「連続体」を新しいデータと適切にマージするにはどうすればよいですか?]
しかし、後で 1 週間ではなく 2 週間のデータが必要だと判断した場合、そのデータが、すでに保存されている 1 週間のデータと重複してしまいます (前の手順を参照)。あるいは、より複雑なケースでは、より大きな期間 (たとえば 1 年間のデータ) が必要になります。これは、貯蓄期間内のあちこちの既存のまばらな週と重複します。 「すでに持っているデータに対して IB を再リクエストしない」という課題をどのように解決しますか?ご覧のとおり、これらのケースでは、単純な手順 1、2、3 がより複雑なものになる可能性があります。
考えられる簡単な解決策の 1 つは、保存されているバーを「完全な日」の精度までマークすることです。次に、単なる「バー」テーブルとは別に、商品/契約ごとに、「完了日」という唯一の列を持つ別のテーブルを追加する必要があります。その後、時間を 1、2、3 ステップ逆方向にループしている間、いつでもチェックできます最も古いバーがたまたま「完全な日」の領域の 1 つに偶然到達し、DB での重複/重複を避けるために 2000 件のリクエストをトリミングした場合、そのトリミングされたサブセットを保存し、「完全な日」の朝まで早送りします。ヒットしたばかりです (または、1 つずつ連続して実行し、すべてが「完了」状態になっている場合は、数日スキップすることもできます)。
このソリューションでは、5.5 日分の履歴が保存されている場合、5 日分は「完了」としてマークされ、0.5 日分はマークされません。そのため、次回より広い履歴範囲が要求された場合は、不完全なデータを破棄し、再実行する必要があります。その日をもう一度（完了するまで）リクエストしてください。
「完全性」をより詳細に可視化するために私が実装したもう 1 つのアプローチは、タイムスタンプの 2 つの列「from」と「to」を含む 2 番目のテーブル「continuum」を用意することです。 2000 バーを取得するたびに、それはすでに確実に連続したものになっており、2000 バーの開始と終了を指す「from」と「to」を使用して、2000 バーを新しいレコードとともに「連続」テーブルに保存します。より完全な履歴データのリクエストを進めるにつれて、連続体の既存のレコードを更新するだけで、1 週間の取得期間の終わりまでに、23400 * 5 = 117000 のバーが 1 つのテーブルに保存され、さらに「連続体」テーブルに 1 つのレコードがポイントされます。最初のリクエストに使用される開始時刻 (「午前 0 時」など任意の時刻を指定できます) とその週の終了時刻 (最も古いバーのタイムスタンプを指します。ここでは「午前 0 時」を使用できません。それ以降にどのようなデータがあるかわからないためです)残りの人生を RTH=true 内に留まることを約束しない限り、最後に要求された範囲です:)。次に、2 つの連続体が重なり始めたらすぐにそれらをマージするロジックを考え出すだけです。現在、拒否されるリクエストは 1 件もありません。こんなに簡単なんですね！-)
乾杯、
ドミトリー
[Q] reqHistoricalData: ボリュームとカウント?
Jason Jones著<jasonjonesa11@hotmail.com>オンラインで表示/返信 (#42484)
2019 年 5 月 27 日に追加
reqHistoricalData の後に Bar データで返される Volume 値と Count 値の違いを説明していただけますか?
IB では、これらのプロパティについて次の定義を提供しています。
出来高: バーの取引高
カウント: バーのタイムスパン中の取引の数
私は出来高を「取引された株の総量」と考えており、これは「取引数」と同じであると予想します。ただし、ボリュームとカウントの値は異なることがよくあります。
1 秒の履歴データをリクエストした後に返されたボリュームとカウントのサンプル値をいくつか示します。
ボリューム、カウント
72、44
0、0
2、1
1、1
46、25
304、135
20、1
113、51
3、3
[A] by rwkオンラインで表示/返信 (#42485)
昔（つまり 20 世紀）には、通常、取引終了後、さらには翌朝まで出来高が得られませんでした。一部のトレーダーは、契約の数に関係なく、取引ごとにカウントが 1 ずつ増加する「ティック ボリューム」に従いました。ティックボリュームには価値がないと考えるトレーダーもいましたが、何もしないよりは[わずかに]良いと考えるトレーダーもいます。ボリュームのリアルタイム レポートが利用可能になると、ティック ボリュームと区別するために「ライブ ボリューム」と呼ばれることが多くなりました。特に株式では、ティックボリュームはもうあまり使われないのではないかと思います。
(Nick による更新): カウントされるのは注文ではなく取引です。 100 株の 1 回の取引 (買いと売り) は、出来高 100、カウント 1 です。
【Q】バックテストはどうやって行うのですか？
[A] Kevin Zhu、Groups.Io 経由<Z_kvn= yahoo.com@groups.io >オンラインで表示/返信 (#1531)
2018 年 6 月 6 日に追加
バックトレーダーを試してください。私がこれまでに見つけた最高の純粋な Python バックテスト オープン ソース ソリューションであり、優れたドキュメントです。
私は insync を使用してデータをダウンロードし、バックトレーダーにフィードします。
https://github.com/backtrader/backtrader
[Q]ティックプライスの高値、安値、終値フィールドは?
[A]ヴィシュルス著
IB への私の Qn: リアルタイム データ アクセスにおいて、高値と低値はどのような意味を持ちますか? Bid、Ask、Last/Closeのみを取得する必要があります。それは違いますか？
IB:
高値 – その日の高値
low – その日の安値
上記では、主に情報として使用されます。通常、ユーザーは取引分析のための情報を取得します。
IB への Qn: また、この API 呼び出しによって返される最終価格と終値の違いは何ですか?
IB:
Last – 契約が取引された最後の取引価格
終値 – 昨日の終値。
[Q] ティックサイズ()ティックプライスイベントのシーケンスは何ですか?
「サイズ イベントを取得した場合、次に価格イベント、次にサイズ イベント、
価格を関連付ける必要があるかどうか知っていますか?
前のサイズイベントですか、それとも後続の価格イベントですか?」
関連項目も参照してください: [Q] ある程度正確な累積量を取得するにはどうすればよいですか?
関連項目も参照: [Q] ライブ取引の構築
[A0] IB のディスカッション掲示板より:
変更のみを送信し、確認する順序は次のとおりです。
買値、売値、最終値、買値サイズ、売値サイズ、最終サイズ、高値、安値、出来高、終値
したがって、あなたの質問に答えると、価格イベントを関連付ける必要があります
後続の NEXT サイズ イベント (価格は前に送信されるため)
サイズ）
価格はサイズの前に送信されます
[A1] ドミトリー著:
むしろ、IB API ソースを読んで、API がこれらのイベントをコードにいつどのように送信するかを確認することをお勧めします。これはより明確で、読む必要があるのは約 100K バイト以上の C++ コース コードだけです。
[A2] blackbox_tws_api blackbox_twsapi@btinternet.com>
EReader コードを使用すると、内部で何が起こっているかを確認できます。
最新バージョンは 3 以上 (現在はバージョン 7) になるため、IB サーバーから送信される価格「ティック」には次の情報が含まれます。
1. TICK_PRICE のバージョン (>=3)
2.ティッカーID
3.ティックタイプ
4.価格
5.サイズ
6.canAutoExecute
したがって、API が受け取る価格ティックには、価格と出来高の両方の情報が含まれます。 API は、tick_price メソッドと Nick_size メソッドを順番に呼び出します (これら 2 つのメソッド呼び出しの間に API が再度 Nick_size を呼び出すことは不可能であるため、tick_price の直後にある Nick_size 情報は常にそのティック価格に関連していることに注意してください)。
価格が変更されていない場合、IB は現在のサイズ情報のみを送信することで帯域幅を節約します。サイズ「ティック」には次のデータがあります。
1.TICK_SIZEのバージョン
2.ティッカーID
3.ティックタイプ
4.サイズ
したがって、任意のサイズのティックは、同じタイプのこの以前の価格ティック価格 (たとえば、入札) に関連します。
以下のコードからわかるように、リーダーは 2 行目から 13 行目でティック データを解析し、14 行目で NickPrice メソッドを呼び出します。
そのメソッド呼び出しから戻った後、 4 行目から読み取ったTickType が価格ティック (1-Bid、2-Ask、4-Trade) かその他のものであったかどうかをチェックします。それが価格ティックの場合、EReader は 30 行目で TICK_SIZE 関数を呼び出します。
コードからわかるように、EReade から読み取られた同じティックは、TICK_PRICE メソッドと TICK_SIZE メソッドの両方を呼び出します。
たとえば、これは edemo を使用して SPY で受信したいくつかのティックの生データです (日曜日にストリーミング データが必要な場合)。
msgId 1 1 2 1 2
バージョン 6 6 6 6 6
ティッカーID 1 1 1 1 1
ティックタイプ 4 2 0 2 3
サイズ 2 32 48 30 30
価格 188.88 185.95 185.75
canAutoExecute False True True
msgId: 1=TICK_PRICE、2=TICK_SIZE
TickType: 0=買値サイズ、1=買値、2=売値、3=売値、4=最終価格、5=最終サイズ、8=出来高
ご覧のとおり、TWS/IBG によって受信されるデータは、サイズ ティック、またはサイズと価格のティックを組み合わせたものです。
これがティック価格とティックサイズのデータで実際に何が起こっているのかを明らかにするのに役立つことを願っています。
-BB
1 ケース TICK_PRICE: {
2 int バージョン = readInt();
3 inttickerId = readInt();
4 intticType = readInt();
5 二重 価格 = readDouble();
6 int サイズ = 0;
7 if (バージョン >= 2) {
8 サイズ = readInt();
9 }
10 int canAutoExecute = 0;
11 if (バージョン >= 3) {
12 canAutoExecute = readInt();
13 }
14 eWrapper()。tinyPrice (tickerId、tickType、価格、canAutoExecute);
15
16 if (バージョン >= 2) {
17 int sizeTickType = -1 ; // ティックではありません
18 スイッチ (tickType) {
19 ケース 1: // 入札
20 sizeTickType = 0 ; // BID_SIZE
21 休憩 ;
22 ケース 2: // 質問する
23 サイズTickType = 3 ; // ASK_SIZE
24 休憩 ;
25 ケース 4: // 最後
26 サイズTickType = 5 ; // LAST_SIZE
27 休憩 ;
28 }
29 if (sizeTickType != -1) {
30 eWrapper()。tinySize (tickerId, sizeTickType, size);
31 }
32 }
33 休憩;
34 }
35 件の TICK_SIZE: {
36 int バージョン = readInt();
37 inttickerId = readInt();
38 intticType = readInt();
39 int サイズ = readInt();
40
41 eWrapper().tickSize(tickerId、tickType、size);
42 休憩;
43 }
[Q] マイナスの見積もりやゼロの見積もりが届きます。なんと？
[A] by カート
おそらく、ゼロまたは負の引用符は無視する必要があります。
コンボを交換しない限り。あなたのコードはおそらく次のように動作するはずです。
ロジックが不在の検出に依存していない限り、見積は受信されませんでした
たとえそうであっても、診断目的で試すのは悪いことではありません。
おそらく、否定的な引用符が問題を引き起こし、否定的な引用符を無視した場合
引用、あなたの問題は解決します。もしそうなら、それはそうではありません
リクエスト率の問題。の割合になる可能性は非常に低いと思います。
あなたのリクエストにより、IB はゼロまたは負の引用符を送信することになります。
マイナスの引用符とゼロの引用符は、IB 引用符の「有効な」条件です。
ストリーム。これは営業時間外の通常の状態であり、場合によっては営業時間外の場合もあります。
取引時間中に流動性が失われる（米国オプションでは珍しいことではない）
コンボ）。参考に、サイズフィールドも確認するとよいでしょう。
オプションコンボを取引している場合は、これらの条件の曖昧さを解消してください。
場合によっては、コンボの 0 または -1 の価格が実際の価格である可能性があります。 （しかし
入札と質問が *両方* -1 になることはありません。)
また、リクエストとリクエスト ID をログに記録すると、次のことがわかるかもしれません。
同じ ID で複数のリクエストを送信しているかどうかをすぐに確認できます。
これが表示されたら、バグがあることがわかります。もちろんロギング（特に
画面上のログ ウィンドウに表示される)、データ速度が遅くなり、問題が隠れる可能性があります。
-カート
一つ訂正。マイナスの入札をすることもできます。私はオプションをスキャンするアルトをいくつか書いていますが、遠く離れたオプションの途中で、値が 0 とマイナス 1 になることがよくあります。マイナス1の値は、twsがそれらを評価するため、私を際限なく悩ませ、突然、通貨の将来オプションのポジションで数百万ドルを稼いだり失ったりしました。
よろしく
クリスチャン・グロス
[Q] 特定のティッカーと有効期限のすべての権利行使価格を取得するにはどうすればよいですか?
[A]
> まず、reqContractDetailEx(…) を呼び出す必要があります。
> すべての関連オプション製品を入手するには
> reqContractDetailEx(…) を呼び出すときは、
> コントラクトパラメータが空の場合、空の属性はワイルドカードとして機能します。
> したがって、すべての有効な組み合わせ製品が返されます。
> 指定されたシンボル。たとえば、有効なすべての情報を取得したいとします。
> IBM 7月オプションのストライキ。この特定のケースでは、
> 契約オブジェクトの下のフィールドをゼロに設定します。そうすれば、これは
> 7 月の有効なストライクをすべて返します。例を参照
> 以下のパラメータ:
>
> シンボル = IBM
> SecType = OPT
> 有効期限 = 201007
> ストライク = 0
> 交換 = スマート
> 通貨 = 米ドル
>
> 情報はContractDetail(…)イベントで配信されます。
>
> レイムンド
> IB テクニカル サポート
[Q] セキュリティ定義が見つかりません。
[A] by blackbox_tws_api <blackbox_twsapi@…>
必ず IB Contract Information Center にアクセスして、選択した契約に関連するフィールドがあることを確認してください。
http://www1.interactivebrokers.ch/contract_info/v3.8/index.php
関連するコントラクトを見つけたら、conid を使用してコントラクトの詳細をリクエストします。その後、どのような修正が必要かを判断できます。
下記のご要望につきましては、有効期限の問題も考えられます。一般に、IB は 1 年以上前の履歴データを提供しません。
その他の修正:
メッセージ履歴を隠す
Contract.m_symbol="QQQ";
Contract.m_secType="OPT";
Contract.m_expiry= "20131018"; << YYYYMMDD 形式の、より新しい契約を使用した例
契約.m_strike= 42;
契約.m_right = "C";
Contract.m_exchange="CBOE"; << 要件に応じて、「SMART」も機能する可能性があります
上記といくつかの日中バー サイズ設定 (例、duration = "1 D"、barSizeSetting = "5 mins") を使用すると、以前のセキュリティ定義が見つかりませんというエラーではなく、CBOE OPT に対する市場データのアクセス許可がありませんというエラーが表示されます。
これがお役に立てば幸いです。
-BB
[Q] reqMarketData(): ほとんどの株では最終価格を取得できますが、一部の株では入札しか取得できません。
[A] by カート
まあ、それは時々起こります*。特に非常に少量の株式については
ビッドまたはアスクが消えて、数秒後に戻ってくるのを見たことがあります。
しかし、これは私の経験ではかなり異例であり、米国株では見られません
通常の取引時間内。通常の取引でも見かけると思います
一部の米国ETFオプション（ネイティブ）スプレッドについても同様です。
しかし、私は、「最後」が存在しなかった場合を除いて、常に「最後」があるべきだと思います。
その日、その銘柄でまだ取引している、つまり出来高が 0 であれば、あると思います
最後ではありません。 TWS自体は終値を「C」で表示します。
その状況では追加されますが、API はこれを行いません。
もちろん、入札がないという実際のシナリオも考えられます。
1 つは買いです – 満期が近いオプションの場合のように、市場はありません
それはお金からは程遠いものです。
-カート
[Q] reqMarketData(): 価格が-1のtickPriceイベントが返されることがあります
[A] by カート
IBですら、どのような値が返されるのかわからないような印象があります。
価格フィールド。 -.99、-1.0、0、そして
時間外は価値が送信されません。 IB はデータを直接渡すと言っています
（一般的に言えば）取引所であり、それを制御することはできません。それであなたは
数時間後には、やり取りが続くと、あらゆる種類のナンセンスが得られるでしょう
彼らのシステムを使って。価格がアウトかどうかは自分で判断する必要があります
範囲の。取引時間中であっても、取引所は非流動的な買値/売値を提示する場合があります。
見た目は非常に良い値ですが、実行されません。このため、一部の人は
市場データを単一の大量取引所に限定する
彼らは依然として SMART を使用して取引を行っているにもかかわらず、株式には @SMART を使用しています。
FXの場合は当てはまりません。
コンボの場合、マイナスの価格が有効になる場合があるため、常に有効です。
現実性を確認するために、すべての脚の見積もりを調べます。ネイティブのビッド/アスク
コンボは常に、加算/減算によって計算される値の中にある必要があります。
レッグに対して取得した見積もり。いつ買値/売値を交換するかを忘れないでください。
負の重み (比率)。
IB から得られる市場データ フィードは、いわば無料のものです。がある
何でもあり。価格は本物であるか、そうでないかのどちらかです。そうでない場合は、そうではありません
実行する。 😉
-カート
[A2] by クライモン6
IDEALPRO の営業時間は、日曜日から金曜日の 17:15 ～ 17:00 (ET) です。
入札価格 = -1.0 になった時点で市場は終了しました
http://interactivebrokers.com/en/trading/exchanges.php?exch=ibfxpro&showcategories=FX&ib_entity=llc
[Q] conIdとは何ですか？
[A] by カート
conId は、IB がコントラクトを識別する方法です。それを IB 独自の中心と考えてください。
少なくとも私の知る限り、それは他人のシステムとは何の関係もありません。
conId がコンテキストを識別する唯一の方法であるコンテキストは数多くあります。
契約。契約構造を介して契約を指定すると、次のようになります。
conId を取得するためだけに契約の詳細をリクエストする必要がある場合があります。
必要な場合に使用してください。そのような場所の 1 つはコンボを構築するときです。見て
ComboLeg では、レッグを指定する方法は他にないことがわかります。
conId によって。
他に絶対的なコンテキストがあるかどうか思い出せません
*必須* conId。
ただし、コントラクトを永続化するためにそれを使用したい場合もあります。
たとえシンボルが
コントラクトが変更されても、conId は変更されません。 （これはなくなります
以前は米国オプションの問題でしたが、株式でも同様のことが起こる可能性があります。
まあ、もっと稀なことですが）
-カート
Kurt による[A2] (実際の回答は他のスレッドから取得しましたが、この特定の回答は conId に関するものです):
OPの質問に対して、あなたの指摘は基本的に正しい可能性が非常に高いです。もし
コントラクト ID を 0 に設定しても問題なく動作したため、(直ちに) 設定する必要はありません。
それを指定してください。 (おそらく今、IB はあなたが指定していないことをチェックし始めています
契約 ID と他の契約フィールドの両方?)
いずれにしても、OP で完全な例が示されていれば興味深いでしょう。
失敗した場合は、それを見てみましょう。
ただし、契約 ID が次の場合にのみ関連するという点には同意しません。
コンボ。
あいまいな契約に関する問題を回避するための役立つテクニックの 1 つ
requestMarketData または
placeOrder は、完全な契約フィールドのみを指定します。
requestContractDetails からコントラクト ID を取得し、それを使用します
市場データを要求するための契約 ID (他の契約フィールドなし)
履歴データと注文を行うため。
最近、さまざまな人々が特定の問題に遭遇しています。
以前機能していた、または現在も機能している契約仕様書
requestContractDetails ですが、requestMarketData または placeOrder ではありません。使用する
契約 ID (他の契約フィールドの代わりに)
possible はこの種の問題を回避し、IB 時の奇妙な驚きを回避します。
placeOrder (またはその他) が他のものを解釈する方法を定期的に混乱させます。
契約フィールド。
契約 ID を使用すると、シンボルの変更を行うこともできます 。
夜間に発生します (OSI 以前のオプションでは定期的に発生していました)。
昨日開いたポジションを、
同じ契約フィールド。
そしてもちろん、あなたが言ったように、コンボを指定するときにそれを使用する必要があります。
しかし、それは他の多くの理由と関連しています。
-カート
[Q] 音量がおかしいのですが？
[A] by souqmate@yahoo.com
米国株の出来高には、TWS と API で暗黙の係数 100 があります。履歴データとリアルタイム データ (bidSize または askSize) の場合は true。
[Q] インデックスの過去の価格を取得するにはどうすればよいですか?
[A] by orionn2 <no_reply@yahoogroups.com>
インデックスには買値も売値もありません。したがって、（売値）中間データは利用できません。代わりに、インデックス価格を提供する TRADES を使用してみてください。
[Q] リアルタイム損益を取得するにはどうすればよいですか?
[A] by カート
> 皆さんこんにちは:
>
> 実現損益と未実現損益を把握するのに非常に苦労しています
>IBより。接続を確立した後、reqAccountUpdates(true, ""); を呼び出します。
> ソケット上で、updateAccountValue() コールバック メソッドが呼び出されます。
> 頻繁に呼び出されますが、updatePortfolio() はほとんど呼び出されません。ありますか
> 何か足りないのでしょうか？
データを注意深く見ていないし、週末なので見ることができない
本当に行ってみてください。したがって、あなたの問題が何であるかわかりません。
私の記憶では、これらは定期的に、おそらく数回ごとに呼び出されます
秒。それは私の好みには十分ではないことがよくあります。 (あなたも分かると思います
取引後の更新がより迅速になります。）
個人的にはリアルタイムで損益を見るのが好きですが、これらの更新はリアルタイムではありません。
今のところ、IB が提供するポジションとコストベースを使用しますが、残りは無視します
そして、ポジション、コストベース、ティックデータから損益を自分で計算します。
TWS 自体も同じことを行うことができましたが、そうではありません。それは愚かに思えます
ライブデータがそこにあるだけの場合に遅延損益値を表示する
無視されました。 TWS が遅延損益データを使用する唯一の理由は、
IB ティック データを取得していない場合はフォールバックします。ただし、API を作成している場合は、
アプリであれば、その言い訳はありません。ティック データをどこで入手しても使用できます。
損益計算に使用されます。
また、自分で行う場合は、損益をどのようにすべきかについて独自のポリシーを設定できます。
計算される。 IB は、期限内に固定された最後の価格を使用していると思います。
ビッド/アスク範囲。おそらく一般的なアプローチとしては合理的ですが、そうでない場合もあります
「最後の」価格であるため、一部の人々の好みにとって十分に安全な指標となる
二度と起こらないかもしれない。数秒遅れるとさらに悪いことになります。
-カート
[Q] reqRealTimeBars() – 「whatToShow」文字列?
somebody765@yahoo.comより
最近、「whatToShow」文字列に複数のエントリを含めることができるか、それとも単一の値になるのかと尋ねた人がいました。「TRADES、BID、ASK、MIDPOINT」。Kurt さんは、エントリは単一の値でなければならないと親切に指摘してくれました。
新しい reqRealTimeBars() コマンドによってオーバーライドされるまで、リアルタイム バー データはこのフィールドに最後に設定された内容を継続すると正しく想定していますか?そして、人はたった 1 つの 5 秒足の間に取引と売り買いのデータを正常に取得できるでしょうか。しかし、データを正常に取得するには、この間隔内で 3 つのリクエストを指定して迅速に行う必要がありますか?
言い換えれば、株式の 5 秒足のすべてのデータを取得できるでしょうか?また、これはどのように行われるのでしょうか?
ランドール
[A] by Ed news1000@edshome.net
はい、一度リクエストすると、5 秒ごとに自動的に応答が返されます。
各リクエストには独自の ID があるため、複数のリクエストを同時に実行できます。
データ制限 (デフォルトでは同時市場データ要求は 100) に依然として制限されていますが、これがリアルタイム バーにどのように適用されるかは正確にはわかりません。少数のシンボルを監視するだけの場合は問題ありませんが、数千のシンボルを監視する場合は問題になります。
–エド
[A2]カート・ビグラー著 kkb@breathsense.com
各リクエストは、ある意味では reqMktData と同じようにサブスクリプションです。 TRADES、BID、ASK の更新が必要な場合は、3 つのリクエストを行います。通常、ユーザーは 1 つのバーに対してではなく、継続的な更新を取得するためにリアルタイムのバー リクエストを行います。 3 つすべての最初の結果が同じ小節期間内に始まるという保証はありません。ただし、それらは継続され、最終的には 3 つすべてから継続的なアップデートを取得することになります。
-カート
[Q] reqRealTimeBars() – 利用できるバーは 5 秒のみですか?部分的なバーですか？
【A】 …5秒足から計算できます。 5 秒足から他の足を計算したり、市場データから足を計算したり、単に過去の足を定期的にリクエストしたりすることもできます。これにより、 endDateTime="" をリクエストしたときに進行中の部分足を取得することもできます。
-カート
[Q] tinyPrice(): canAutoExecute フィールド – なんと?
このフラグに関するドキュメントは次のとおりです。
価格ティックを自動実行に使用できるかどうかを指定します。可能な値は次のとおりです。
• 0 = 自動実行の対象外
• 1 = 自動実行の対象となる
「自動約定」とは「注文を出す」ことを意味するのでしょうか？もしそうなら、対象外のティックを送信する意味は何でしょうか?
[A]ソース
自動実行についての私の理解は、それがハイブリッド以前の時代から保持されているフィールドであるということです…。ニューヨーク証券取引所では、以前は 2 つの執行プラットフォームがあり、1 つはフロアのスペシャリストによる手動執行で、もう 1 つはコンピュータ システムによる自動執行でした。コンピュータ ベースの注文は一定量しか処理できませんでした。そのため、自動執行されヒットする注文はありませんでした。自動化システムにはトレーダー用のタグが付けられました。
しかし、2007 年に彼らは自動システムをアップグレードし、すべてをそのように移行したので、ブックに投稿された注文の 99 ～ 100% は自動的に実行できるはずだと思います (入札したりオファーを受けるのに人間の介入は必要ありません)。
–では、それはレガシーとして無視してもよいのでしょうか？
–はい、心配することはありません。
【Q】履歴データをリクエストすると「ステップが無効です」と表示されることがよくあります
どうすればいいですか？
[A] 「無効なステップ」とは、実際には、ステップ (バー サイズ) とリクエスト期間の無効な組み合わせを意味します。通常、必要なバーのサイズは疑問の余地なくわかっており、機能する最大持続時間を使用するため、「バーのサイズに対して無効な持続時間」の方が賢明です。しかし、IB は、API エラーとドキュメントの両方において、これに関して一貫して反対の考えを持っているようです。
[次のページの表を参照]
私は このリストに掲載されている次の表を随時参照してきましたが、その結果、 無効なステップ エラーが発生したことはありません。
http://www.tradingsoftwarelab.com/jtwsdump/table.html
Kurt Bigler著 kkb@breathsense.com yahoogroups.com経由
最大数のバーを生成する持続時間の値を青にマークします(1 つの生の中で複数のマークが付けられています - 同じ結果が得られる、別名「同じ良好」を意味します)
2020 年 10 月: 重要な更新: IB が履歴データのリクエスト速度の制限を変更 (改善) したようです。 IB のドキュメントにはまだ記載されていません。 この投稿で Richar の調査結果を参照してください。 |
2021 年 2 月 16 日: リチャードは発見についてさらに詳細を共有しました。ありがとう、リチャード！ 「オンラインで見る/返信する (#46534)」から引用させていただきます。 マイク
API で許可されているバーのサイズごとに、最大の「甘い」期間があるようです。その期間を超えると、履歴データのリクエストが完了するまでにかなりの時間がかかります。これは技術的な制限ではなく、ポリシーによる決定である必要があります。
以下は、コードからそのまま抽出した表で、バー サイズごとに使用する最大継続時間をまとめています。これらの期間は基本的に試行錯誤によって決定されました。決定的なものであるかどうかはわかりませんが、私にとってはうまく機能しているようです。もちろん、IB がいつでも適切と思われる方法で実装を変更することを妨げるものは何もないため、これが永久に有効であり続けるという保証はありません。実際、このテーブルは、10 年以上前に初めて履歴データ API を使い始めたときに作成した同様のテーブルとは大きく異なります (そして比較にならないほど優れています)。
テーブル内のエントリのいくつかはあなたを驚かせるかもしれません。たとえば、Microsoft などの 50 年分 (はい、年) 分の毎日のデータを 1 回のリクエストでリクエストでき、そのデータは 5 秒以内に返されます。 Microsoft は設立されてそれほど長くないため、IB が保有しているすべてのデータは 1986 年に遡ります。これが 1986 年 3 月 13 日の最初のバーです。
バーの日付=19860313;始値=28.00;高値=29.25;安値=25.50;終値=28.00;出来高=35826;WAP=28.002;ティックボリューム=1;
以前は IB の履歴データ サーバーを悪口していましたが、今ではそのパフォーマンスに非常に感銘を受けています (API 自体は怪物だと思いますが)。
表は次のとおりです。
' バー サイズ 最大持続時間 ——– ———— ' ' 1秒2000秒 ' 5 秒 10000 S ' 10秒20000S ' 15秒 30000S ' 30秒 86400S ' 1分86400S ' 6D ' 1W ' 2分86400S '10D ' 2W ' 3分86400S '10D ' 2W ' 5分86400S '20D ' 3W ' 10分 86400S '50D '8W ' 15分 86400S '50D '10W ' 20分 86400S '50D '10W ' 30分 86400S '50D '10W 3M ' 1時間86400S '50D '10W 3M ' 2時間 86400S '50D '10W 3M ' 3時間 86400S '50D '10W 3M ' 4時間 86400S '50D '10W 3M ' 8時間 86400S '50D '10W 3M 「1日86400S」 ' 365D 12分 '52W 50年 ' 1W 86400S ' 365D 12分 '52W 50年 ' 1M 86400S ' 365D 12分 '52W 50年
リチャード |
\ 間隔 \ \ \ バーのサイズ\ | Y | M | W | D | S |
1年 | 86400 | ||||
3ヶ月 | 86400 | ||||
1ヶ月 | 5 | 86400 | |||
1週間 | 5 | 12 | 52 | 60 | 86400 |
1日 | 5 | 12 | 52 | 60 | 86400 |
1時間 | 1 | 4 | 34 | 86400 | |
30分 | 1 | 4 | 34 | 86400 | |
15分 | 2 | 20 | 86400 | ||
5分 | 10 | 86400 | |||
3分 | 10 | 86400 | |||
2分 | 10 | 86400 | |||
1分 | 10 | 86400 | |||
30秒 | 1 | 86400 | |||
15秒 | 30000 | ||||
5秒 | 10000 | ||||
1秒 | 2000年 |
jTWSdump ホームページに戻ります。
例: バーのサイズ = 30 分をプルしたいのですが、継続時間を「D」単位で指定します。継続時間にはどの値を使用すればよいですか (つまり、最大許容値は何ですか?)。テーブルでは「34」と表示されるため、reqHistoryData() の期間パラメーターの答えは「34 D」になります。
34 営業日は 34 暦日より長いことに注意してください。
注: 34 営業日は、「1 W」または「86400 S」を指定するよりも長くなります。
(todo: これらのクエリをすべて実行し、バー サイズ != 継続時間単位の場合に返される実際のバー数をテーブルに追加し、最大バー数を生成する継続時間の値を青にマークします)
Riggster:バーサイズを 1 ～ 15 秒に指定する場合、durationStr を日ではなく秒で指定する必要があるとは知りませんでした。そのため、'23400 S' は使用できますが、'1 D' は使用できません。ただし、1 日は 23400 秒です。
[A2] orionn2 著 (2015 年 12 月 18 日):
jTWSdump Web サイトの表を更新しました: http://www.tradingsoftwarelab.com/jtwsdump/table.html
1M (1 か月)、1W (1 週間)、および 1 日バーでは 5 Y (5 年) の制限が増加し、5 分、3 分、2 分、および 1 分バーでは 10 D (10 日) の制限が増加していることを示しています。これらの制限は 1 つのデータ リクエストに対するものです。別の API リクエストの終了日時を今から 5 年より前の日付に設定すると、さらに多くのデータをダウンロードできます。 jTWSdump では、これは「クエリ数」フィールドを使用して簡単に管理できます。
ヘッズアップしてくれた Richard L King に感謝します。
バーのサイズ設定に関する次の Q/A も参照してください。
[Q] 履歴データリクエストの有効な期間とバーサイズの設定
[A]このページ からの引用 :
次の表に、API 履歴データ リクエストの有効な期間とバー サイズの設定を示します。これらは単なるガイドラインであることに注意してください。
間隔 | バーのサイズ |
間隔 1Y | バーのサイズ 1日 |
6メートル | 1日 |
3M | 1日 |
1メートル | 1日、1時間 |
1W | 1日、1時間、30分、15分 |
2D | 1時間、30分、15分、3分、2分、1分 |
1D | 1時間、30分、15分、5分、3分、2分、1分、30秒 |
14400 S (4 時間) | 1時間、30分、15分、5分、3分、2分、1分30秒、15秒 |
7200S (2時間) | 1時間、30分、15分、5分、3分、2分、1分30秒、15秒、5秒 |
3600S (1時間) | 15分、5分、3分、2分、1分30秒、15秒、5秒、 |
1800S（30分） | 15分、5分、3分、2分、1分30秒、15秒、5秒、1秒 |
960S（15分） | 5分、3分、2分、1分30秒、15秒、5秒、1秒 |
300S（5分） | 3分、2分、1分、30秒、15秒、5秒、1秒 |
60秒（1分） | 30秒、15秒、5秒、1秒 |
[Q] reqMktDepth()呼び出しを使用してTWSのようなデプスブックを開発することは可能ですか?
hyeungsf@yahoo.com より
[A] by barnstws <no_reply@yahoogroups.com>
プライマリ交換フィールドを指定してみてください。 reqContractDetails は、正確なパラメータを取得するのに役立ちます。外国為替は無料で、自分が正しくやっているかどうかを簡単に確認できます。
(2021 年 2 月 4 日更新) ただし、注意: 標準の 100 行サブスクリプションでは、一度に実行できる reqMarketDepth サブスクリプションは 3 つだけです (100 個ではなく 3 つのシンボルのみ)。
[Q] 実装メモ: reqMarketDepth
[A] ドミトリー著
2021 年 2 月 4 日に追加
「isSmartDepth」が何のためにあるのかは明確ではありませんでした: ドキュメントのもう 1 つの問題は次のとおりです: 「このリクエストはスマート ルーティングではなく交換に直接ルーティングする必要があります。」 <– これは問題になる可能性があります。これは、SMART ルーティングを使用しており、正確な交換を知りたくない/知る必要がないためです (多くの場合、たくさんある可能性がありますよね?) (また、SMART 経由の注文は直接経由の注文よりも安いため、SMART にこだわる必要があります)。 グーグルで検索: tws API isSmartDepth (私のお気に入りのフォーラムで)この素晴らしいディスカッションを明らかにしました これは、引数に関する次のメモにつながります (バージョン 974 のリリース ノートから)。
フォーラムには別の素晴らしいメモもあります:
素晴らしい！したがって、常に「mkdDepthOptions = null」および「isSmartDepth = true」を維持します。これにより、直接ルーティングを気にする必要がなくなります。万歳！ 次に、投機プラットフォームの ApiController.java ファイル (このファイルは IB によって実装されています) を見ると、次のことがわかります。 1) reqDeepMktData() を送信するだけです (これをチェックしてください – コード内の特定の行番号へのリンクを作成することもできます!! 行 648 ) 2) updateMktDepth () とupdateMktDepthL2 () の両方からの応答は、実装する必要がある唯一のハンドラーに送られます (関数 updateMktDepth() はインターフェイス IDeepMktDataHandler の唯一のメンバー) それです！ ここで必要なのは、IB API から受信した結果コールバックを保存することだけです。 これらを 2 つの HashMap の「テーブル」、bid_table と ask_table に保存することにしました (したがって、更新の順序は任意であり、テーブルの中央からレコードを「削除」する場合はギャップがあっても問題ありません。これは完全に可能です)。 SimpleArrayList ではそうすることはできません。現在、位置はハッシュマップのキーであり、値はすべての入力引数をまとめて保持するクラス (「構造体」と読みます) です (そして、この行がいつあったかを正確に知るために、そのコンストラクターにタイムスタンプを追加しました) (「ミリ秒」分解能で))。 |
[Q] 営業時間外に reqMktData() を実行するとどうなりますか?
[A]ドミトリー著
サブスクリプションが成功した場合、tickType=CLOSE (基本的に最新の価格 (出来高なし)) を指定した 1 つの tinyPrice() イベントを取得します。
または
error() イベント (契約の説明が何らかの破損がある場合、または以前のサブスクリプションと同じtickerIdを設定した場合、またはその他のエラーの場合) のいずれかを取得します。
例:
[時間外サブスクリプションが成功しました]
05:18:20 PosixTestClient.cpp:739 reqMktData():
05:18:20 PosixTestClient.cpp:746 契約の市場データを要求しています:
条件ID: 0
記号：FB
秒タイプ: STK
有効期限:
ストライク: 0
右：
乗数:
交換：スマート
プライマリExchange:
通貨: 米ドル
ローカルシンボル:
取引クラス:
期限切れを含む: いいえ
秒IDタイプ:
秒ID:
コンボ脚の説明:
comboLegs: 脚が見つかりません
05:18:20 PosixTestClient.cpp:247ティック価格():
ティッカーID: 0
ティックタイプ: CLOSE (9)
価格：55.44
canAutoExecute: 0
[営業時間外のサブスクリプション試行が不適切]
05:23:15 PosixTestClient.cpp:739 reqMktData():
05:23:15 PosixTestClient.cpp:746 契約の市場データを要求しています:
条件ID: 0
記号：FB
秒タイプ: STK
有効期限:
ストライク: 0
右：
乗数:
交換：スマート
プライマリExchange:
通貨: CAD <– – これは問題を引き起こします
ローカルシンボル:
取引クラス:
期限切れを含む: いいえ
秒IDタイプ:
秒ID:
コンボ脚の説明:
comboLegs: 脚が見つかりません
05:23:15 PosixTestClient.cpp:232エラー():
ID:0
エラーコード: 200
errorString: リクエストのセキュリティ定義が見つかりませんでした
または、次のような他のエラーもあります。
エラーコード: 322
errorString: リクエスト処理エラー:-'vc': 原因 - ティッカー ID が重複しています
[Q] IB独自のヒストリカルデータ修正（ヒストリーオブヒストリー：）
2015 年 4 月 27 日に追加
[A] by Kurt (ここにあります)
それについて言及されているのを聞いたことはありましたが（IBでも信じています）、一度も見たことがありませんでした
IB の履歴データでは、時間の経過とともに実際にどのような変化が起こっていますか。
歴史の歴史。
今日、1 分 USD.CHF BID_ASK バーで次のことを観察しました。時代
表示されている時間は米国太平洋時間です。
5 月 30 日のある時点で、前日からこのバーをダウンロードしました。
20110529 22:52:00 O 0.85215 H 0.85225 L 0.8521 C 0.85225
しかし、今日（6/5）同じバーをダウンロードすると、次のように変更されていました。
20110529 22:52:00 O 0.85215 H 0.85215 L 0.8521 C 0.85215
^ ^
これを 1 秒のデータと比較して、どのように変化するかを確認することはできませんでした。
関係します。この件でそのために必要なデータを取得したことはありません
場合。
(余談: これらは BID_ASK バーなので、始値と終値には通常のバーがありません。
意味。ただし、それらは時間加重平均であるはずです。
彼らはあまりにも正確であると疑われるほどだ。おそらくIBが出てきたのだと思います
平均を最も近いティックに四捨五入します。これにより、当然のことながら、平均が
精度が低くなります。私はこれを観察したと思いますが、他にもいくつか観察しました
正確な観察を妨げる可能性のある問題。
自分のアーカイブ データを無意識のうちに丸めてしまう (C 形式の %g に丸める)
生成します）。それを修正して以来、OPTION_IMPLIED_VOLATILITY が観察されました。
履歴データには、四捨五入された時間加重平均がありません。しかし、
もちろん、ボラティリティに適用される minTick 値はありません。)
また、一部の BID バーと ASK バーが画面から消えている証拠も見ました。
記録。これらは営業時間外のバーだったのかもしれません。手元に情報がない
今これについて。
重要なのは、私は今、歴史における実際の変化を見てきたということです。
歴史的なデータですが、以前はこれは私にとって単なる推測でした。私
上記の変更がいつ行われたのか正確にはわかりません。
1週間前にもう一度確認しました。
これについては最終的に詳しく見ていきますが、他にはどうなるのか気になります
この問題に関してはそうしてください。
考えられる戦略の 1 つは、一定期間 (数日?) 待つことです。
ダウンロードする前に、履歴変更の「大部分」が解決されるようにします。
現在まで意図的にダウンロードしていない人がどれくらいいるのか気になります。
この理由のための瞬間。その場合、データが安定するまでどれくらい待ちますか?
回答する場合は、どの証券または証券の種類を示してください。
一緒に働く。
ご意見ありがとうございます。
-カート
[Q] reqTickByTickData は遅延ティックを取得できますか?
[A] by joshオンラインで表示/返信 (#44949)
2020 年 7 月 28 日に追加
遅延データを含むさまざまなデータ型は、reqMktData 関数でのみ使用できます。
reqTickByTickData は、ほとんどの商品で市場データのサブスクリプションが必要なライブ データでのみ使用できます。
0 件のコメント :
コメントを投稿