English Русский 中文 Español Deutsch Português
Meta COT プロジェクト - MetaTrader 4 における CFTC レポート分析の新たな展望

Meta COT プロジェクト - MetaTrader 4 における CFTC レポート分析の新たな展望

MetaTrader 4 | 22 4月 2016, 13:37
7 443 0
Vasiliy Sokolov
Vasiliy Sokolov

はじめに

市場価格の変動は主観的なエリオット波動、ギャンライン、フィボナッチレベル、テクニカル インディケータによって生じるものではありません。それらには、OHLCV 形式の価格チャートと比較して新しい情報ビットはなにもありません。価格変動は需要と供給の基本法則によって決定されるものなのです。それがどれほど些細なものに見えても、需要と供給が価格を決定するのです。

価格は買い手と売り手の相互作用の結果です。トレーダーの多くはそのことをわかっていますが、それを利用する人はほとんどいません。この包括的な市場法の実用は、あえて将来の価格を予測したことのある人ならだれにもひじょうに有用なものです。本稿は、経済の理論的公準から先物市場や商品市場で取引にそれを応用するまでの、『指導書』のようなものです。

経済理論は、市場に『買い過ぎ』と『売り過ぎ』の局面が存在する可能性について述べます。こういった局面は市場にとって重大なものです。『買い過ぎ』ゾーンでのさらに上方値動きをするのはむつかしくなります。それは供給の競争が激化するためです。『売り過ぎ』ゾーンにおける、さらなる下方値動きもますます困難になりますが、これは需要の圧力が増すためです。どちらの場合でも、市場は長期逆転に近づきます。こういう主張は、経済理論がこういった市場局面を決定する方法を提案してこなかったため、単純で役に立たないように思えます。ただ、こういった方法は存在し、よくあることですが、成功したトレーダーによって昔に作成されたものです。

歩行は理論と実践の橋渡しをし、読者の方々に、著名なトレーダー Larry Williams によって書かれた"Trade Stocks and Commodities With the Insiders: Secrets of the COT Report"で説明されているシンプルなインディケータを基にした市場局面決定方法を紹介します。にもかかわらず、、この本はあまり人気が出ず、資料は広く活用されませんでした。その理由の一つには、この本で紹介されているコンセプトがすべて理論に留まっているためです。

ロシア語の翻訳版ができて 2 年以上になりますが、ロシアでもっとも一般的なトレードプラットフォームである MetaTrader4 でのコンセプト利用のためのユニバーサルで便利でオープンなソフトウェアは提案されていません。本稿はこのギャップを埋めるものです。今では誰もが自分の MetaTrader 4 クライアントターミナルを使用することで Larry Williams の理論を検証し、実践に利用することができるのです。

トレーダー レポートのコミットメントを使った現市場分析の方法はファンダメンタル分析と見なされています。ファンダメンタル分析自体はトレーダーにとっての幅広い応用法を発見することはありませんでした。トレーダーのほとんどが現実の取引でテクニカル分析を利用しているのは周知の事実です。これはファンダメンタル分析が経済ニュースの発表に関連していることが多いためですが、ニュースで市場反応を予想するのは不可能です。

次に、この分析はパラメータ化されておらず、そのため非常に主観的なのです。

さらに次に、ファンダメンタル分析は潜在的にエンドレスです。それは、市場に影響を与える経済効果の一部だけを分析することができ、その他の部分はトレーダーによって常に考慮されるとは限らないが、市場によっては考慮される、ということです。CFTC レポートの利用により、自動的にファンダメンタル分析の弱点をすべて払拭し、Larry Williams のこういうレポート分析に対する方法は、技術に対するテクニカル分析の最高の機能を提供するのです。これは、第1に有意な経済効果がすべて市場参加者3人の行動を観察することで間接的に考察できることを意味します。

第2に、その観察はすべて簡単なテクニカルインディケータにすることができ、主観性やあいまいさを削減します。

取引に対してシンプルなファンダメンタル分析を利用する Expert Advisor を作成することは可能です。本稿ではそのような作成方法の一つが紹介されます。それは、取引に CFTC レポートを利用しおうと思う人なら誰にでも有用であると、私は思います。


本稿のパート1は、需要と供給の経済理論についてです。簡単な例を用いて市場モデルを説明し、異なる市場フェーズの存在可能性を証明します。パート 2 は、現在の市場局面を決めるために必要なデータ分析方法についてです。売り手と買い手の相互作用を分析するのに必要なインディケータセットについても説明があります。ほとんど、こういったインディケータの実用が詳細に示されている、Larry Williams の著書を基にしています。パート3は、Meta COT プロジェクトの技術的実装についてです。Expert Advisor 使用についての詳細情報、プロジェクトに入っているインディケータのやスクリプトの使用、必要情報のダウンロード方法です。パート4は最終パートです。Expert Advisor および本稿で紹介されているコンセプトの効果を考察します。最終結論を出し、いくらか建設的な提案をします。



1. 価格のバランス機能としての市場

1.1需要と供給の法則

市場は特定商品、サービス、リソースの買い手(『需要』)と売り手(『供給』)を集める制度またはメカニズムです。[3]

上記以上に市場の的確な定義はありません。事実、開かれている市場の主要なタスクは売り手と買い手を集めることです。売り手と改訂の関係は需要と供給の法則で調整されます。この基本法則が株式価格の上昇、下降を産み出し、それにより トレーダーが将来価格と現価格の価格差から利益や損失を出すのです。トレーダーは需要と供給の間のバランス変化のメカニズムを知る必要があります。そのため以下のテーブルを考察します。

供給合計

価格/ブッシェル (U.S.)

需要合計/週

利益 (+) または欠損 (-)

12 000

5

2 000

+10 000

10 000

4

4 000

+6 000

7 000

3

7 000

0

4 000

2

11 000

-7 000

1 000

1

16 000

-15 000


テーブル 1-1 コーンの市場需要と供給(単位:千ブッシェル)

ここには、価格と引き渡し量の面でコーンの売り手と買い手の関連があります。売り手はできるだけ高く商品を売りたいと願い、書いてはできるだけ安く解体と願います。この場合、ブッシェルあたりコーンのコスト $ 5 で、それを売りたいと思う売り手が数多くいます。その供給合計は 12,000 ブッシェルになります。売り手の問題は、そのような高額で買うつもりの買い手がそれほどいないことです。そのような高額だと 2,000 ブッシェルしか買うつもりのない買い手ならいます。残りの 10,000 ブッシェル(12,000 - 2,000 = 10,000)は買われないままとなり、売り手からの商品余剰、買い手からの商品不足を引き起こします。市場では、この価格が留まることはできません。売り手の多くは商品の売れ残りをなくすためだけに価格を下げ、手にするのは少額ですが生きたお金です。彼らは競合相手を先取りしようと思っているその他の売り手に加わります。売り手間の競争が始まると、それは価格を下げることになります [3]

それでは逆の場合を考えます。このとき、コーンの価格はひじょうに低い-ブッシェルあたり $ 1 、と想定します。そのようなコーン価格は買い手にとってはひじょうに魅力的で、それを買いたいと願う買い手は数多く存在します。その需要合計は 16,000 ブッシェルです。ただしその価格で売りたいと思う売り手はもっとずっと少ないことでしょう。供給(販売)合計額は1,000 ブッシェルで、15,000 ブッシェルの学での買い手間で再び商品不足が起こり、売り手の黒字となります。また、この価格も市場に留まることはできません。買い手の中には、必要な商品を獲得するため、もっと高い価格でコーンを買う人もいるでしょう。こういった買い手は他の買い手に加わり、のちの価格上昇を予想し、比較的安く買う先頭集団の中にいようと思うのです。買い手間の競争が始まり、それが価格を上げることとなります [3]。

それを明確にするためにグラフに需要と供給の機能を書きます。


図1-2 価格の機能としての需要と供給

図1-2 価格の機能としての需要と供給

これまで需要と供給の極端な分布だけを考察してきました。第1のケースでは、価格は落ち、第2のケースでは、価格は上がります。両方、需要と供給が等しくなる一定の平衡点になります。この時点では、買い手間で商品不足はない、または売り手の黒字にはなりません。われわれのテーブルでは、その点は3ドルのところにあります。その価格では、供給合計と需要合計共に 7,000 ブッシェルとなり、この価格で、売られずに残っている商品はなく、赤字の現れない買い手と売り手の平衡交換が存在することとなります。

現実には、需要と供給は、基本的な理由からランダムなイベントの範囲で、多くの要因の影響で変化します。いずれの場合でも、需給の交点は1点のみ存在します。この点が現在の市場価格となるのです。

供給が不断の需要で増加する例を考察します(図1-3 a の点 A-B)。この場合、商品は安くなり売り手間の競争が始まるため、価格は落ちます(p1<p2)。一報、より良い価格で消費を購入したいと思っている買い手の数が増えます(q3>q2)。

次に供給が減る場合を考察します(図1-3 a の点 A-C)。これは価格を上げることとなります。というのも、商品数が減り、買いt間の競争が始まるからです(p3>p2)。確実に、より高い価格で買いたいと思う買い手の数は減ります。



図1-3a 一定の需要における供給の変化

需要にとっても同様です。需要が増えると(図1-3 a の点 A と B)、価格は上がり始め、高い価格で売りたい者が多くなり、それは供給合計が増えることにつながります(q3>q2)。逆のケースでは、需要が落ち始めると、価格が落ち、売り手は低い価格で販売したい売り手は減少し、そのため供給の累積数が減少します(q1<q2)。


図1-3b 一定の供給における需要の変化

ここから需要と供給が同時に変化する場合を考察します。そのようなケースは以下のように 4 とおりあることが明らかとなっています [3]。


1. 需要が減少し、供給が増加する。このような要因はすべて別々に低価格につながり、その結果、総価格の下落は個別に各要因により引き起こされるものより さらに大きくなります。

2. 需要が増加し、供給が増加する。この要因は、需要の伸びが価格上昇につながり、供給の伸びが価格下落につながるため、互いに補いあいます。一般的に、価格変動はより強い要因により決定されます。

3. 需要が減少し、供給が減少する。前出のケース同様、結果は不明瞭です。需要の増加により、価格は下落し、一方、供給の減少が価格上昇につながります。一般的に、価格変動はより強い要因により決定されます。

4. 需要が増加し、供給が減少する。供給減少が価格上昇につながるケースとまさに同じく、需要の増加は価格上昇につながります。結果、総価格上昇は各要因個別におこるものよりずっと大きくなります。

現実の市場では、需要と供給は毎秒変化し、上記4とおりのケースは値の実際の市場価格に反映されます。そのため、需要と供給の交点は価格とボリューム チャート上を異なる位置にある異なる期間で『動きまわり』ます(図1-4 参照)。

図1-4 需要と供給の力学

最も重要なことながら、需要と供給の交点は低価格で高ボリューム(すなわちチャートの左上位置にくる)とはならず、それは低ボリュームで高価格(すなわちチャートの右下の位置にくる)にならないのとまったく同様です。もっと明確にするため、図 1-5 を、見ましょう。

図1-5 市場のフェーズ

上述のとおり、供給者は低価格で高ボリュームを提供すること(薄利多売)はいやがります。また買い手は高価格での高需要(高額で多くを購入)を呈することは拒むものです。したがって任意の市場のモデルを構築することが可能です。図 1.5 はあるモデルを示しています。点線は需要と供給の平均的な交点です。完全な市場サイクルは3つの期間またはフェーズに分けることができます。

1. 低価格フェーズ 低価格、低ボリュームが特徴です。現実ではあるが、実現されていない買い手からの市場需要は高く、一方、市場供給は制限されます。買い手の間で商品不足とまだ知られていない売り手からの商品余剰があります。それは買い手の競争を発生させ、それが最終的に価格上昇につながります。

2. 平均価格フェーズ このフェーズには、十部高いボリュームで許容できる価格が存在します。買い手の不足も、売り手の余剰もありません。ここには価格とボリュームの平衡点が存在します [3]。図 1.5 ではそれは点で示されています。

3. 高価格フェーズ  稿価格、稿ボリュームが特徴です(Q)。商品の生産者からの実供給が高く、一方、買い手需要は制限があります。買い手が高額商品を買うことを望まず、生産者が高額商品を販売したいことで生産者の競争が発生します。それは最終t的には価格下落につながるものです。

すなわち、需要と供給の法則はリターン・アンド・トレンド市場動向を決定するのです。中期的(時間尺度は約1~1.5年)には、市場は低価格フェーズから高価格フェーズに、または逆に行きます。よってトレンドが存在することとなります。長期(1年以上)では、市場は高または低価格フェーズに動き、買い手または売り手の抵抗に会い、そのアクション下で逆戻りするため、フラットとなります。市場動向は呼吸に例えることができます。一杯に吐き出したら、肺の中にはそれ以上吐き出すほんの少しの空気も探すのは困難です。

半面、横隔膜と肺の間の圧力は外気より低くなり、空気が肺に入ってきやすくなります。完全に呼吸すると、肺の容積はすべて使われ、それ以上ほんの少しも吸い込む可能性はありません。このとき、横隔膜と肺の間の圧力は外気より高くなり、余分な圧力が肺から空気を押し出そうとします。この手順が何度も繰り返されるのです。市場でも同様の手続きが起こります。買い手の競争(ネガティブな圧力)が起こることで、市場は価格上昇を余儀なくされ(空気を吸い込む)、一方売り手の競争(ポジティブな圧力)が市場に価格下落(空気を吐き出す)を起こさせます。

上で見たように、商品不足と過剰供給状況が市場では可能です。ただし、市場では同量が売買されることも真実です。よって、市場が上昇トレンドのときブルで、または下落トレンドでベアに支配されるというテクニカル分析の一部結論は、正しいものではないのです。市場にはつねに等しい数量のブル(買い手)とベア(売り手)契約があります。しかし、低価格では、市場で販売される商品数には限りがあります。商品所有者の大半はそのひょうな時期を待ってやり過ごすものです。


すなわち、 小麦であれば、倉庫に留まり、通貨の場合は銀行に留まるのです。そうすると、買い手は望む量の商品を買うことができません。標準駅な言葉で言えば、この状況は『買われ過ぎ』と呼ばれます。逆の場合、価格が高く、市場に売り手の商品余剰だらけの場合、それは『売られ過ぎ』と呼ばれます。のちに、それを買われ過ぎ、売られ過ぎのケースとして参照します。


1.2価格は需要と供給方程式の第1変数です。

低価格と高価格の例を説明するために、砂糖の週刊バーを考察します。

図1-6 砂糖、週刊バー


比較的低価格では、売りたい人はほとんどなく、そのため市場に出回る商品ボリュームも比較的小さいことが解っています。逆に高い市場価格では、商品ボリュームは増えます。価格自体は商品の過剰供給または不足の可能性を示します。この仮定は往々にして粗い予想です。商品価格とボリュームが相関関係にあっても、そこに直接の直線関係はありません。

比較的高い価格で、比較的小さい商品ボリュームがあることは可能で、一方同時に比較的高いボリュームで比較的安い価格が可能です。これは需要と供給の関数がほとんど線形ではなく、ほとんどつねに需要の価格弾力性と供給の価格弾力性両方の対象となっているためです[5]。価格によって市場のボリュームを決定する第2の問題は、そのような方法の『相対性』です。どの価格が高く、どの価格が低い、とどのように決定することができるのでしょうか?

長期では市場は逆トレンドでないことはわかっています。市場の買われ過ぎおよび売られ過ぎのインディケータを作成してはどうでしょうか?それを市場が高価格に到達したらショートポジション、低価格になるとロングポジションを開始するために利用するのです。市場特性をすべて同時に利用することで、トレンドのとき、また逆トレンドのとき利益を得るに違いありません。

過去50年間、数多くのテクニカルインディケータが開発され、市場の買われ過ぎ、売られ過ぎ状態を明確化しようと試みています。しかしそのすべてにはある深刻な問題があります。需要と供給のある変数1つだけに基づいていることで、その変数とは価格なのです。需要と供給のバランスが変化したのち、最後におこるのが価格変動です。

結果的に、価格に基づくなんらかのインディケータ、あるいは価格そのものを利用しているトレーダーは、せいぜい変化する価格に追いつくことが最後となり、決して先取りすることはできないのです。簡単なコンピュータテストがこの方法の矛盾を示しています。

以下は RSI インディケータに基づく基本システムの利益チャートです。

図1-7 RSI インディケータに基づくExpert Advisor の利益変動2000~2009 の EURUSD についての日次バー

このシステムは基本的なものです。期間 7 の RSI が80 パーセントに到達すると、それは売りディールをオープンします。RSI が 20% に到達すると、買いディールをオープンします。カスタム期間はより多くのディールをオープンすることを選択しました。ストップは 100 ポイントで、トレード条件からのエグジットは 200 ポイントの利益です。テストは EURUSD について 2000~2009 で日次バー使用で行われました。全ディールについての取引ロットは一定で 0.1 でした。

結論は明確です。価格データのみ使用するのでは、市場フェーズを判断するのに十分ではありません。需給方程式には第2の変数、市場ボリュームが必要なのです。



1.3建玉は需給方程式の第 2 変数です。

多くの市場にとって、オープンしている建玉値を分析することで1契約までボリュームを知る機会があるのは驚くべきことです。

建玉は先物および/またはオプションマーケットの契約数で、ディール、デリバリー等では補償されません。建玉はロングポジションまたはショートポジションすべての合計です [1]。たとえば、市場におけるロングポジションの合計が1,000契約であれば、それは、同一マーケットのショートポジションの合計も1,000契約に等しく、1,000契約の建玉も同じであることを意味します。以下は建玉の式です。

小麦の先物1契約の買い手と売り手は建玉値に1ユニットを追加します。

建玉と市場ボリュームの違いを理解することは重要です。たとえば、一日に100万契約がトレードされたとしても、それは100万契約分の商品があるということではありません。日次ボリュームを増やしながらも、ほんの1日で手から手へ渡すのはもっと小さい可能性があります。1日の終わりには、ポジションがすべてクローズしておらず、その多くが翌日にロールオーバーされるのです。オープンしている契約数は建玉インディケータです。商品の生産者は長期先物を購入することでリオスクをヘッジすることに目を向け、そのため実際の商品引き渡しの約束をするのです。それは建玉値に現れます。ある意味、建玉は市場における商品ボリュームの尺度でありえます。

建玉は全先物市場で各セッションの終わりに日次で計算されます。この情報は公開され、通常先物取引所の公式ウェブサイトで利用可能です。建玉に関する同様のデータは e-Signal のような有料シグナルに定期購読することでも入手可能です。MetaTrader ユーザーにとっては、ここで紹介されている Meta COT の一部であるインディケータ «Meta COT: Net Position» によって 40 を超える市場の建玉データが取得可能です。その利用に関して詳しくは本稿のパート 3 を参照ください。

残念ながら、建玉に関する情報(本稿で述べられているその他のデータタイプすべて同様)は、そのストラクチャや特性により、現金取引市場や株式市場では利用ができません。ただ、現金取引市場と先物市場の強い相関関係により、同一先物市場での需給動向によって導かれる現金取引ではトレードが可能となります。たとえば、スポットで EURUSD を取引しつつ、EURO の先物について建玉変動を分析することは可能です。しかし、より正確に表現するには先物チャートのみ使用します。

ここから長期にわたる金についての建玉変動を見ましょう。

図1-8 金、週次チャート

図1-8 には、 2003~2009の金先物についての価格チャート(上側)と建玉チャート(下側)が表示されています。建玉値が以前の値にと比較して相対的に高いとき、市場は下降に向かい始めたのが解ります。同時に、建玉値が低いとき、市場は上昇し始めています。週次チャートでは、最近の激しい変動を含む長期間であるためそれはよく確認されません。

金に対して真であることは、他のすべての商品にとっても真であり、需給の法則はあらゆる市場で有効なのです。


図1-9 大豆、週次チャート

図1-10 米国債、週次チャート

ごらんのとおり、相対的に低い建玉値は市場が伸びる可能性を示し、一方、相対的に高い建玉値は価格下落の可能性を示します。市場は、建玉が最小値、最大値のときかならずしも反転するとは限らず、建玉の極値が即時の市場の反転を指し示すものではありません。建玉は魔法の市場『切り替え器』ではありませんが、それにより二次元-市場ボリュームを測定し、市場の現在フェーズを推定することはできます。


ここに第1ルールがあります。それは需給法則から形作られるものです。

建玉が極端に高いレベルであれば、ショートポジションを開くようにする。

建玉が極端に低いレベルであれば、ロングポジションを開くようにする。



2. 市場ストラクチャ

われわれが見出したのは、市場は機関やメカニズムであり、それは特定の商品やサービスの買い手と売り手を集めてくる、ということです。それではこのグループを詳細に考察します。

2.1ヘッジャーや投機家は市場ストラクチャの一部です。

市場はつねに需要と供給の交点を見つけさします。この交点は商品価格の合意価格です。すなわち、売り手が一定のボリュームの商品を売ろうとしており、買い手がこのボリュームの商品を買おうとしている価格です。毎回需要と供給は基本的、政治的、ランダムなまたその他要因の影響下で変化しています。需給の法則に基づき、商品価格も変化しています。結果として、将来価格は現在価格より上がるか下がるかどちらかの可能性があります。時間とともに価格が変動すると、その価格は将来不確実なものとなります。そのような将来的な価格の不確実性はリスクと呼ばれます。 [6]。

よって商品の所有者はすべてが将来不利な価格変動のリスクを抱えているのです。ただ価格変動は上昇であり下降であります。価格が下向きに変動すると、現市場価格と比べ、将来に低い価格で販売することから生じる損失を意味します。逆に、商品価格が上昇すれば、所有者は追加利益を得ることとなります。一般的には、商品の主な所有者は生産者です。

その製品が小麦であれば、その所有者は General Mills 社かもしれず、それが金であれば Barrick Gold 社であるかもしれない、などです。価格変動のリスクが高く、これら企業の主要収入が生産コストと販売価格の差で得ているなら、そういう企業は商品を所有することから生じるリスクを減らすことに興味を示すものです。それには、製造者は商品および金融市場でヘッジ操作を行います。実際、製造者は自分のリスクをそれを買いたい他社に販売します。リスクに加え、価格が好ましい変動をする場合、買い手は追加利益を得る機会(リスクプレミアム)も手にします。

そのため交換は集中市場だけではないのです。交換はリスクやそれに対するプレミアムを売買する集中場所でもあるのです。

商品やそれに伴うリスクの買い手は投機家と呼ばれます。投機家の主な目的は現在価格と将来価格の差から利益を得ることです。投機家は製品製造者とエンドカスタマーの間の『接着剤』のようなものです。投機家が価格の円滑な変化によって、市場に高い流動性をもたらします [4]。

ヘッジ操作はリスクをゼロに縮小することはあまりありません。それはリスクと利益の間の合理的なバランスを見出す方法なのです。あとでわかるように、ヘッジ能力があれば投機機会を利用することができます。ヘッジされたポジションの動きをモニターすることで、取り組んでいる市場のことをほとんどなんでも知っている製造大手のグループの投資に参加することが可能です。

実際、この見解には意味があります。そういった企業は、取引所で取引されている商品の直接の提供者であります。製造者でなければ、だれがビジネスのこの分野で起こるすべてを知るのでしょうか?そういう企業は参加者の目や耳から隠された情報を持っているのです。他の誰も知らないことを知っているのです。さもなければ、毎日何百万ドルも取引を行い、何十年間も彼らが為替で成功したプレーヤーであることにどのような説明がつくのでしょうか。

投機家をモニターすることにも意味があります。投機家の購入レベルは市場が『加熱している』、すなわち第3フェーズ、または冷めた(第1フェーズ)(パート1参照)の場面であることを示します。最後に、投機家は通常、商品の主要な買い手であります。それはロングポジションを最大まで構築し、もうそれ以上買う可能性があにとき、市場は下方へ反転することを意味するのです。


2.2商品先物取引委員会レポート分析

『商品先物取引委員会』-CFTC、と呼ばれるアメリカの政府機関のおかげで、だれにでもヘッジャーや投機家のポジションを観察する機会があります。こういった取引のボリュームが委員会によって指定されているレベルに到達したり超過すると、個人や法人を問わず商品取引所での契約にのっとった取引について報告書を提出しなければならないのです。委員会はトレーダーのポジションをまとめて一週間に一度報告をします。

各レポートは以下の公式ウェブサイトで発表されます: www.cftc.gov。このレポートは毎週火曜日の状態を対象としており、モスクワ時間では金曜日の夜遅く公表されます。レポート自体は複数形式で提供されます。それは、Excel テーブル、CSV テキストファイル形式、また簡単な表形式のテキストです。また、長期履歴レコードを Excel 形式や CSV 形式でダウンロードすることもできます。レポートは先物予約と先物、またオプション取引について作成されます。レポートには簡潔フォームと拡張フォームがあります。拡張フォームには追加の統計と一部作物の収穫高データがある点で簡潔フォームとは異なります。実質上、CFTC レポート分析には Excel または CSV ファイルが利用されます。2009年8月4日の小麦に関する簡潔なレポートを見てみましょう。


テーブル 2-1 2009年8月4日の小麦に関するレポート (先物のみ)

レポートの一番上には、作物名があります。この場合は、シカゴ商品取引所で取引される小麦です。レポートタイプは先物のみのポジション、日付は2009年8月4日です。行列はの主要な4 列で構成されています。列はそれぞれトレーダー3グループのショートポジションとロングポジションをまとめたものを表示しています。トレーダーの最初のグループは主要投機家を含むものです。レポートは非商業トレーダー(NON-COMMERCIAL)と呼ばれます。2009年8月4日、大口投機家は75 933契約を持っていたことがわかります。一方でショートポジションでは97 574契約です。これはそのトータルまたはネットポジションがショートで、それが -21 641 契約だったことを示しています。通常、それは投機家にとって一般的状況ではありません。

すべてではありませんが、市場のほとんどで彼らは純粋な買い手であり、ということは彼らのロングポジションがつねにショートポジションよりも高いのです。分析に1件のレポートのみ使用しては、この市場でこれが一般的な状況か判断することはできません。いかなる場合でも、ここでもっとも重要なパラメータは、ロングポジション、ショートポジション個別ではなくグループのネットポジションであることを覚えておいてください。このネットポジションはトレーダーレポート分析の指標の大半を計算する際使用されます。もう一度言います。トータル、またはネットポジションはロングポジションとショートポジションの差に等しく、それは正でも負でもあり得ます。以下がその式です。

ここで、NetPosition はトレーダーの純ネットポジションまたは総ネットポジション、i は主要な非商業トレーダーまたは大規模な商業トレーダーといったトレーダーのカテゴリーです。

次は、非商業トレーダーについての主要な契約数で、いわゆるスプレッドやカバレッジを言われるものです。

Larry Williams はそれについて次のように著しています。「非商業トレーダーがユーロ/ドルの先物で2 000 のロング契約、1 500 のショート契約を保有していれば、500 契約が『ロング』のカテゴリーに、1,500 契約が『カバレッジ』に入る。 [1]。単純にカバレッジはロング契約、ショート契約双方の数を示します。

ところで、ロッキングを意味しているのではないことに注意することがン重要です。たとえば、トレーダーは先物契約で引き渡しの異なる月に対して逆方向に同一商品を、または先物とオプションで同一商品について逆方向保有することができます。レポートでは、オプションのポジションを持っており、そのようなケースは考慮されています。

2番目のグループは ヘッジャー のポジションを反映しています。彼らもまたオペレータ商業トレーダー(COMMERCIAL)と呼ばれます。必ずしもというわけではありませんが、一般的に、オペレータは純粋な売り手です。というのも、そのほとんどは小麦、金、豚などの商品生産者だからです。商業トレーダーは、たとえば、綿菓子やパンなどの生産のベースに商品を使用する別の製造者でもあります。必ずしもというわけではありませんが、一般的に、彼らは売り手です。すなわち、かれらの契約がショートの側にあるのです。

一般的に価格が低いレベルまで下落するとき、オペレータは販売を最低限まで減らしています。なぜなら安く商品を販売することは利益につながらないからです。同時に、独自の製品を生産するオペレータは、逆にロングポジションを増やします。よってオペレータのネットポジションロングで、オペレータのネットポジションを基にした指標は上のゾーンにあることとなります。


小麦のレポートを例にとって、特殊なケースを考察します。オペレータのロングの側には 166,518 契約が、一方ショートの側には 130,979 契約があります。そのネットポジションは 35,539 契約、すなわちロングです。これは、オペレータが買うよりも少なく売っているため、商品の価格が低いレベルにあることを意味することが多いものです。どんな場合でも、正確な状況を判断するには、長期についてのオペレータのネットポジションのチャートを使用する必要があります。

«Total» の列には商業トレーダー、非商業トレーダーのとりまとめられたロングポジション、ショートポジションが一式入っています。あまり実用的に興味深いものではありません。

«Nonreportable Positions» 列には分類しきれないトレーダーのロングポジション、ショートポジションが入っています。実際、この列は小規模な投機家のポジションが入っており、そういう人たちのポジションは少なすぎて投機家グループに入れることができません。こういったポジションは合成計算によって計算されます。具体的には、建玉値(OI)から、報告されるトレーダーのトータルのロングポジションとショートポジションが差し引かれます。われわれの場合、OI は322,431 契約で、一方ロングは 279 239 契約、これは29 194 契約が分類できない人たちのロング側ということです(322,431 - 279,239)。同様の計算がショート側に対しても行えます。322,431 - 279,339 = 43 092 契約です。

ここでは、前回のレポートと比べると、各グループの契約数に変化があります。以下は建玉での各カテゴリーのシェアと、数字に一番下はトレーダー数です。こういったデータは実際には使用されません。

上で述べたポートに追加して、オプションのポジションを含むレポートがあります。オプションのポジションはすべて同等の先物に変換され、先物のポジションに直接追加されています。小麦についても同様のレポートですが、オプションと先物のまとめられたポジションは以下のようなものとなっています。

テーブル 2-2 小麦の短報、先物およびオプション(2009年8月4日)

数量は異なるものの、どちらのタイプのレポートもポジション変化のダイナミクスの類似チャートを提供します。とはいえ、オプションのポジションに関する情報を持つレポートが市場ボリュームをより完全考慮するので、それを利用する方が好ましいものです。『スプレッド』列の増加した値を見ます。この行の値は非商業トレーダーについてのロングポジションとショートポジションの比較が入っています。これは商業トレーダーがほとんどの場合先物ポジションを上回るオプションのポジションを利用するためです。


次に、同じ小麦に関して先物とオプションのポジションを持つレポートの拡張形式を考察します。

図2-3 完全な小麦の先物とオプションのレポート(2009年8月4日)

ごらんのように、このレポートにはトレーダー3グループの古いポジションも含まれています。これらレポートはすべて長期間での変動を分析しているので、この情報はまったく興味を引くものではありません。

2.3大規模なヘッジャーのポジション観察

ヘッジャーの売買に関する統計をコンパイルし、長期間でその活動をモニターします。たとえば、オペレータのロングポジションとショートポジションを表示するインディケータを伴い、すでに紹介済みの小麦価格チャートを使用します。チャートは週次バーで構成されており、2001年半ば~2009年の期間におよぶものです。

図2-4 小麦、ロングポジションとショートポジション、週次バー

ここでグリーンの線はオペレータのロングポジションを表示し、赤はショートポジションに対応しています。ポジションはすべて絶対的指定され、記号はありません。赤色の線はショートポジションの絶対額、グリーンの線はロングポジションの絶対額を表示すると仮定することが必要です。一般的に、2004年春まではオペレータのショートポジションが支配的で(グリーンの線の上にある赤色の線)、その後、オペレータは売りより買いをしました(赤色の線の上にあるグリーンの線)。そのチャートは主要なブレイクポイントを表示していません。それでは、同じチャートですが、オペレータの総ネットポジションのインディケータで見ます。

図2-5 オペレータの総ネットポジション、週次バー

ここでは、もっと面白い場面を見ることができます。市場が上昇していくらかすると、オペレータのネットポジションが相対的に高くなったことに注意します。同時に、オペレータのネットポジションは市場が下方に行って少しすると、相対的に低くなっています。もちろんインディケータ予測がすべて正しいとは限りませんが、少なくとも1つ正しいポイントでエンターをすれば、それは大きな利益となるかもしれません。

2005年末のオペレータの極端に高いネットポジションに注目します。後にも先にもオペレータはそのような高いネットポジションの値を持ちませんでした。次に、その後市場に何が起こったか見ます。避けられない情報への変動を始めました。それは 2 年以上も続きました。結果、価格は 700 米ドル以上上昇したのです!他に投機への良い機会を示す瞬間がいくらかありました。

たとえば、2007年末に激しい価格下落の後、多くの人がブルトレンドは終わるであろうと考えたものです。明白にオペレータはそのようには考えませんでした。ロングポジションを減らそうとする人がいる(トレーダーレポートからわかっています)一方で、オペレータは市場を買い占めたのです!上昇はすぐに訪れました。最高価格が更新され、それからパニックが始まりました。この間4か月、価格はもう400米ドル上昇したのです!オペレータから出された売りシグナルはあまり説得力がありませんでした。それでもなお、簡単なトレーリングストップのテクニックを使っていれば、多くの場合にトレーダーは市場を無事に逃れることができたのです。いずれにしても、損失はすべて1件の良いディールによって補填することが可能です。

ここでのキーワードは『その後すぐに』です。この指標は価格を使って計算されるものではにことを忘れないでください。価格からはまったく独立しています。価格ハートを削除することはできるでしょうが、オペレータのネットポジションの指標はまだ同じ値を示していることになります。価格は最近の市場の変化です。まず変化するものは、需要と供給の力のバランスです。でもその以前に市場参加者の心理が変わります。オペレータのすることを観察し、早い段階で市場の進化を目撃します。そのときはまだ価格変化が出現していません。将来の蒸気機関車のもう一つ別の半分空のトレーラーで起こるユことは、ユニークな利点を提供してくれます。変化が始まるとき、多くの人はそこへ来るのが遅すぎますが、委員会レポートを利用しているトレーダーはそうではありません。

オペレータのプリズムを通して、金と銀を観察しましょう。

図2-6 金とオペレータのネットポジション週次バー

金価格のチャートは投機にとって好ましい機会にあふれています。かならずしも超過利益につながるとは限りませんが、その多くは相当な収入をもたらしてくれます。長年継続する主要なブルトレンドとエントリーポイントを相関した場合、このトレーダーは大勝利です。みなさんに思い出していただきたいのです。われわれはオペレータのネットポジションが十分高い瞬間、これらポイントが買いの潜在的ポイントであることを考察しました。同じことが売りにも当てはまります。相対的に低いネットポジションを探し、空売りをしようと売る機会をうかがっているのです。

2008年末の金に行った狂気に注意が必要です。9月初旬に終わった激しい下落後、予想外の上昇を始めたのです。事実、1日で金価格は90ドル上昇しました。それから9月末まで高値でしたが、それはあまり長くありませんでした。この後まもなく新たな下落があり、10月末には金はその年の最低価格を更新しました。

部分的にでもそのような動揺を予想できたでしょうか?トレーダーのポジションレポートによってそれを予測することは可能でした。ブルフライデー(金の価格が『突然』90ドル上昇した日です)の少し前、オペレータが金を売ることを止めたことに注意します。

彼らはこの市場のプロデューサーで、ここずっと買いが売りを上回る週は1週もありません。実際、彼らが売らないと金のブルにパニックがもたらされました。価格を挙げた金属の不足があったのです。

価格が長期間そんなオリンポスに留まらないものの、そこで最後に価格のピークに応答したオペレータは金のブルに対していくらか自分達の金属を売りました。のちに金価格は落ち始め、その後、オペレータは4年の最低値まで(かれらのネットポジションは増加しました(チャート参照))。さらにわれわれは売り手の競争の効果も確認しました。商品不足は価格上昇を始め、これはお金を稼ぐには良いアイデアかもしれません。

それでは銀のチャートに目を転じましょう。


図2-7 銀とオペレータのネットポジション週次バー

ふたたび、ここで金と同じことを確認します。ネットポジションが相対的最大値に到達すると必ず、銀価格は太陽身向かって新たな跳躍をしました。相対的に低いレベルは銀の上昇トレンドでの布教を示していました。

以下が結論です。貴金属の市場は小さなプロ集団によって大きくコントロールされている。そしてこういった市場で利益あるトレードをしたいと願うトレーダーは皆、そのような力の影響を考慮する必要がある。


2.4ネットポジションの指数

しかし、何が『相対的に』高いネットポジションで何が低いか、どのようにわかるのでしょうか?Larry Williams が指摘したように、ある者にとっての床は別の者にとっての天井なのです。よって、われわれのポジションのフェーズを明確に述べる正規化された指標を使用する必要があります。そのような指標は存在し、COT インデックスと呼ばれます。そのインデックスは通常ポジション値に対して計算されるストキャスティックです。

その式を思い出しましょう [1]。

現在価格は3年間の最高価格と比較されます。指数は3年間だけでなく、任意の期間に対して計算が可能です。26週、すなわち半年の指数、より短い期間でない方がよいでしょう。長期のディールでは、156週(3年)の指数が使用されます。指数は、選択された期間と比較した、現在の相対強度をパーセントで表示します。


以下にリストアップされたオペレータに対する指数計算例がありおます。右側の数字は契約数を示しています [1]。


当週値

350

過去3年の最低値

-150

200

3年の最大値

750

過去3年の最小値

-150

600

指数 = (200/600)x100=0.33x100=33%

この場合、オペレータはブルというよりはベアです。指数が極端に低いレベル、すなわち下位20%のレベルにあれば、市場は下落の傾向です。指数がひじょうに高いレベル、すなわち上位80%以内にあると、市場は上向きに反転する傾向にあるのです。

これを検証するために同じ銀のチャートで、156週のオペレータ指数を見ます。

図2-8 銀、156週オペレータ指数、週次バー

たとえば75%や25%など別のレベルも利用可能です。意味は変わりません。インディケータは潜在的な買われ過ぎゾーン、売られ過ぎゾーンを示すのです。

妙なことですが、この指数期間はモニターしているポジションのダイナミクスを変えません。以下は銀についての異なる平均期間での指数例です。

図2-9 銀のオペレータ指数について異なる期間での銀チャート、週次バー

ここではオペレータ指数に対して(上から下に)156週、104週、52週、26週の平均化を行いました。26週指数のみより頻繁な変動振幅を示しています。平均化のその他期間はほとんど同様に見え、インディケータの形に変わりはありません。対象とする平均化期間は個人の好みによります。たとえば、156週平均化期間を採ると、かなり広くポジション変化のダイナミクスを示します。同時に、ブルポジションについて明らかな興味深い結果を出します。

COT インデックスはブルオペレータだけでなく、非商業トレーダー、小規模投機家をモニターするのにも利用されます。


2.5建玉ストラクチャ

パート1で価格における商品ボリュームの影響例を分析しました。市場で商品のボリュームを測定するには、建玉(OI)を利用するのがひじょうに効果的です。経済理論は、相対的に高いレベルの建玉が特徴的な市場はもっとも下落に反転する傾向にある、と予想します。相対的に小さな建玉の市場にも同じことがあてはまります。この場合は、価格はおそらく上向きです。

それではそのストラクチャを調べましょう。トレーダーのディールレポートによると、先物市場の主要なプレーヤーはオペレータ、『非商業トレーダー』-主に大規模商品ファンドを代表する、としても知られるヘッジャーであることは解っています。また、第3のトレーダーの小数派グループ-スキャルパーまたはいわゆる『群衆』、もいます。彼らは行う小さなボリュームで取引を行うため、市場価格には影響を与えることができません。その類の操作ボリュームは間接的に計算され、建玉とオペレータ、非商業トレーダーのオープンポジションの合計との差としてあらわされます。

週次建玉値はレポート CFTC で提供されています。OI はオープン済みのロングポジションとショートポジションの蓄積であるため、つねにそうであるように、そのレベルは2とおりの方法で計算されます。ロングポジションの合計を数えるか、ショートポジションの合計を数えるか、です。

以下が式です。

OI = 非商業トレーダーのロングポジション + 非商業トレーダーのスプレッド + オペレータのロングポジション + 非報告ロングポジション
OI = 非商業トレーダーのショートポジション + 非商業トレーダーのスプレッド + オペレータのショートポジション + 非報告ショートポジション

2009年8月4日のユーロ先物に関するレポートに目を転じ、上記2つの式でこの市場についての建玉を計算します。

テーブル 2-10 ユーロ先物レポート(2009年8月4日)

OI = 61 443 + 946 + 22 984 + 52 864 = 138 237;
OI = 34 337 + 946 + 72 454 + 30 500 = 138 237;

どちらの建玉計算式で計算しても、結果は同じです。見てのとおり、ロングポジションはほとんど大規模な非商業トレーダー(61 337 契約)によって保持されており、一方、オペレータはショートポジションを好んでいます(52 864 契約)。建玉におけるこれら3グループそれぞれのシェア計算は建玉ストラクチャの分析を論理的に継続することとなるでしょう。たとえば、期間でのショートポジション計算書は建玉の 52.4% に達しました(78 454 ÷ 138,237 x 100%)。たとえば所定の期間にたいするオペレータのショートポジションシェアは建玉の 52.4 % になりました(78 454 ÷ 138237 x 100 %)。その値は、『各カテゴリーのトレーダーに対する建玉比率』項に提供されています。

トレーダー3グループそれぞれのシェア変化のダイナミクスを考察することは面白いものです。長期間に対するこの情報を収集すえば、対応するチャートを作成することができます。インディケータ『Meta Cot:OI におけるポジション比率』それはトレーダーの3グループそれぞれに対してこのデータを計算します。

図 2-14 では、日本円の先物について長期チャートが表示されています。オペレータのショートポジションシェアが70%になり、建玉以上になたびに、円は下方反転に近づいています。ショートポジションのオペレータシェアが建玉の30%を下回るたびに、市場は底に近づき、その後変動の中で長期ブルトレンドが開始することが頻繁にありました。そのようなケースは赤の破線で表示されています。上方反転についても同様です。ショートポジションのシェアが建玉の 30% を下回るたびに、いぇは下方反転に近づいています。ショートポジションのオペレータシェアが建玉の30%を下回るたびに、市場は底に近づき、その後長期ブルトレンドが開始することが頻繁にありました。

図2-11 建玉ののオペレータのショートポジションシェア日本円、週次バー

Larry Williams は著書 "Trade Stocks & Commodities with the Insiders: Secrets of the COT Report" [1] の中で、1つのインディケータで建玉値をオペレータのネットポジションと比較することを提案しています。実際、オペレータの相対的なネットp時ションが十分低く、同時にかれらが大きな市場シェアを保持していると、市場はそのピークに近くすぐに折り返すと推測できます。

このインディケータでは以下の式で計算されます。

ストキャスティック オシレータ(ネットオペレータ÷ OI)

すなわち、オペレータのネットポジションは建玉で割るのです。こういったデータは長期間にわたり収集され、ストキャスティック インディケータがそのデータを使って計算します。このインディケータはウィリアムズの商業インデックス、または単に WILLCO と呼ばれます。Larry Williams は26週または6か月平均を利用することを推奨していますが、年平均(52週)、3年平均(156週)など別の平均化タイプを使用することもできます。

その使用はインデックス同様です。その値が80%を超えるときはいつでも市場反転が予想され、その値が20%を下回るときはいつでも市場の反転上昇が予想されます。図 2-15 では日本円に対する WILLCO インディケータが表示されています。赤の点線は同チャート上で Larry Williams によって描画された同じレベルを表示しています。[1]

図2-12 平均化された WILLCO (26週)および日本円、週次バー

見てのとおり、このインディケータがさらに提案するものはあまり正確ではありませんでした。ただし期間を伸ばすことでこの問題を解決します。決平均化期間156週の米国債のチャートと同様のインディケータを見ます。

図2-13 平均化された WILLCO(156週)と米国債、週次バー

ここで極端な高レベルと共に極端な低レベルに印を付けました。そのデータが価格データに基づいていないため、インディケータの精度は驚くほどです。明らかに米国債はオペレータの行動に対してひじょうに微妙なものです。

2.6モメンタム インディケータ

このインディケータは Stefan Brice によって著書«The Commitments of Traders Bible»の中で提案されました。その考え方はシンプルです。現在の COT インディックスと同じインデックスの6か月前の差が表されるというものです。その式は以下です。

COT インデックス(p) – COT インデックス(p-n)

ここで p はインデックスの現在値、n は 6 に等しい期間です。

インデックスデルタは 6 の期間だけでなく任意の期間が可能です。また、このインデックスは先物市場の参加者すべて、また建玉自体に対しても計算できます。このインディケータは動向指数と呼ばれます。それは主に長期トレンドに対する補正完了を確認するために使用されます。その実装はシンプルです。動向指数が40%を超えて上がれば、現在の下方変動は終わりを迎えます。 価格上昇が期待されます。インデックスが40%より下がれば、現在の情報変動は終わりを迎えます。価格下落が予想されます。

このインディケータをユーロの先物に適用します。

図2-14 ユーロ先物についての動向指数

過去数年間ユーロは堅実な上昇トレンドでした。ブルーの矢印は40%のバリアを交差するときを示しています。インディケータの信じられない制度を見てください。40%レベルを交差したあとはつねに、価格修正が完了し、ユーロは上昇を続けています。インディケータの売りシグナルはあまり正確ではありません。ですが、動向指数が -40% の低い境界を交差したあとには頻繁に修正が始まっています。そのようなインディケータの反応は考慮すべきものです。それは一種のCOT のモメンタムバロメーターです。それは明らかに市場の乱流を示しています。そえは特に積極的で長期でないトレードに対して有用です。

次のインディケータは実験的で、これまでどこにも述べられたことのないものです。Larry Williams は、著書の第9章で、 建玉がオペレータの行動によって変化することを調査しています。この関係をどのように利用するかは明確ではありません。例の一部で、Larry Williams は発散/収束を示しています。別の例では、売りの増加またはオペレータの買いは建玉レベルを高める、と結論づけています。指数変動の調査は、建玉レベルの変化によってオペレータのポジションにおける変化をモニターすることができる、という考えを導きました。

以下がもっとも興味を引かれるインタラクション モデルです。

1. 建玉レベルレベルが下がる-オペレータののネットポジションレベルが伸びる。

2. 建玉レベルが伸びる―オペレータのネットポジションレベルが落ちる。

すなわち、市場参加者全員(建玉)とオペレータの行動の間にはいくらか不一致があるのです。そのような変化は、オペレータの指数についての建玉に関して計算された動向指数を基に観察するのにベストです。その差を比較することで、ヘッジャーの行動とそれ以外の市場参加者の行動の発散を判断することができます。

このインディケータはスプレッド・ムーブメント指数は呼ばれ、その式は以下です。

動向指数(オペレータ)– 動向指数(建玉)

一般的に、それは死ぬpルナ動向指数のように見えます。WILLCO が COT インデックスのように見えるのと同様です。おおよその臨界レベル値はそれぞれ60%と -60% です。その分析は通常の動向指数にたいするルール同様に行われます。

ユーロ先物例でこの指数の動きを考察します。

図2-15 スプレッド・ムーブメント指数、ユーロ

その値も重大な転換点と修正完了時点を示していることがわかります。ただしこのインディケータは注意して使用する必要があります。その 効率 はまだ証明されていないのです。


2.7. 大規模ヘッジファンドのポジション観察

大型商品ファンドの主な目標は商品市場での投機的利できです。彼らの取引方法は一般的なトレンドフォローに基づいています。ひとたび価格が一定の n 週高値を超えると、ファンドの一部がロングポジションをオープンします。それにより価格変動にさらなる上昇を招きます。おそらく中期での市場トレンドの主要な理由の一つは、大型商品ファンドの行動です。

一部の推定によると、ファンドはもっとも頻繁に26週の高値/安値を選択します [1]。プロダクツを構築するテクニックによってファンドは徐々に市場に入ります。またファンドの多くはエントリに、より長期戦略を使います。ポジションに対する別のテクニックによってファンドが徐々に市場に入り、またファンドの多くはエントリに、より長期戦略を使います。. たとえば、価格が26週高値に到達すれば、ファンドの一部はロングポジションをオープンします。そうすると、価格はさらに上向きに動き、52週高値に到達するのです。もっと周到なファンドはゲームに参戦し、ロングポジションをオープンします。それと共に、すでにロングポジションに入っているファンドはポジションを追加します。最終的に、価格は156週高値に到達するのです。この時点で、買いたい人はすでに買ってしまっています。以上です。ここではもう買い手はいません。

ファンド全体のトレンド戦略が最大に関与しているのです。市場はひじょうな緊張状態になりました。買い手がもういないことで、価格はすぐに下がることはトレーダーレポートからわかってます。そしてすぐそうなるのです。価格は下方の動きを始めます。この時点では、市場はひじょうに多くの参加者をかかえています(建玉)レベルからそれがわかります)そしてここで参加者はパニックを起こし始めます。

まず、他者より遅れて市場に参入した買い手はロングポジションをクローズし始めます。彼らはまだ長期ポジション保持に必要な利益を十分なレベルまで得られていません。それが余分な価格上昇を招き、速く落ち始めたのです。まもなくパニックは高まり、より多くの参加者がロングポジションをクローズしようとします。だれもが戸口に無理やり押しかけようとするのです。パニックがあまりにも膨らむため、ひじょうに短期間で価格は下落します。

群衆が市場を去ったあと、価格は底にあり、その直後、オペレータがゲームを開始し、再び市場にやってきてロングポジションを追加します。彼らの考え方はシンプルです。財を成すため商品を利用するオペレータは、安い価格で消費を買うことに興味を示します。逆にオペレータは売りを最低限に抑えます。安い価格で商品を売ることは収益的ではないのです。結果、オペレータのネットポジションはひじょうに高くなります。インディケータははこの事実を適切に示します。需要競争が始まり、価格は再び上昇します。円は閉じ、歴史がふたたび繰り返されるのです。

非商業トレーダーのネットポジションに対して適用される3年指数によって上記コンセプトを基に大規模な非商業トレーダーの行動を検証します。

図2-16 非商業トレーダーの家畜先物価格とトータル ネットポジション

家畜の先物例でわかるように、非商業トレーダーの高度は現在の価格トレンドのように見えます。価格が上昇すれば、ファンドが買っている、下落すれば売られる。簡単なことです。ファンドが最大値までポジションを増やすたびに、家畜の価格は下方の動きを始めることに注意します。ファンドのポジションが最低値に近づくと、価格は上がり始めています。

そのようなファンドに投資をしようと決めた投資家の財務上の成功には、私は疑問を感じます。非商業トレーダーの同様の行動は別の市場で同じです。


図2-17 綿花チャートと非商業トレーダーの156週平均ネットポジション

指数の頂点が来たる市場反転を示していると、原則的にその低い値は時期尚早となっています。いずれの場合にも、このチャートは『大物』が買っているときは空売りするのが得策であることを示しています。


2.8投機家のポジション観察

CFTC 仕様書によると、小規模な投機家は、上記2グループに到達するにはポジションが小さすぎる人たちすべてです。合計数はかなり大きいと思われても、その人達の正確な値は不明です。たとえば、シカゴ・マーカンタイル取引所での小麦に関する短報 CFTC に当てはめることができます。

テーブル 2-18 小麦に関する短報での小規模投機家のシェア

レポートからわかるように、主要な市場参加者の合計数は小さなものです。ショート川では 286、ロングでは 304 です。市場参加者の 286 がロングポジション全体の91.8%を、304 のトレーダーがショートポジション全体の88.5%を保持しているのです。こういった主要な市場参加者を群衆と呼べますか?私は呼べないと思います。委員会レポートに数えられていないトレーダーの多くはひじょうに小規模な投機家で、市場の群衆を形成しているのです。

この場合、群衆はロングポジションの8.2%、ショートポジションの11.5%のみコントロールしていルにすぎません。このカテゴリーのトレーダーの売買履歴を観察することはひじょうにすばらしいことになるかもしれません。次に長期間におよぶ GBP チャートを参照しますが今回は小規模な投機家のネットポジション合計について考察します。

図2-19 GBP 先物に関する小規模投機家のトータルネットポジション


群衆のトータルネットポジションが相対的に高いレベルに達するときは必ずしも、市場価格は下方変動を開始するとは限らないないことに注意します。逆に群衆が GBP に落胆し売り始めると、GBP 価格は回復し始めます。特に注目に値するのは、赤色の線で印がついている最後の2点です。ポンドの大暴落後、小規模投機家が底をつき、上方変動が必至であると判断しました。1週間内に、かれらはネットの売り手から買い手に脱出しました。しかし、まだ底には至っていませんでした。ポンドは約2か月間落ち続けたのです。この間、群衆のムードは変わり、ふたたび主に売りとなりました。そして群衆は再び誤っていたのです。ポンドは十分な回復を示しました。

このグループの取引活動の分析のための一般的ルールはシンプルです。群衆と逆に行動してみることです。不明なトレーダーが急激に売りを増やした場合、彼らが買い始めたら買い、空売りをしてみるのです。

3. 技術的解決法

3.1 MetaCOT プロジェクトの目的とストラクチャ

そういうわけで、プロジェクトのインディケータをすべて考察しました。今度はそのストラクチャを検討します。動作原理を明確に理解していると、データ更新や設定についての問題を多く回避することができます。

まず、ソフトウェアの原理について考察します。以下がそれです。

1. 透明性 プロジェクトソースはすべてオープンでだれもが利用できるものです。こういうツールはだれでもダウンロードしコンパイルすることができます。また、その動作原則は本稿で説明しています。よってそれは透明でだれもが理解できるものです。

2. ユニバーサル ソフトウェアには、Larry Williams の著書で述べられている CFTC データ分析ツールがインクルードされています。彼の WILLCO インディケータもその一つです。それはそれ以外のプロジェクトには入っていないものです。また、そのソフトウェアには特別なスクリプトが入っています。それは特殊な方法で情報をグループ化するものです。結果、自動的に異なるツールに結び付け、新しいツールを作成することだってできるのです!その上、プロジェクトの構造は COT プロジェクトを基にした新規インディケータを簡単に作成できるように設計されています。基本のデータは1つの関数で取得できます(希望の日付に対して)。そしてこれらデータは別のインディケータで計算するために簡単に使うことができます。

3. オートメーション CFTC データはひじょうに大容量です。そこには何百という市場の情報があり、各市場の上昇が異なるファイルや年にちりばめられています。Meta COT スクリプトを使用することは今や問題にはなりません。今するべきは、CFTC から最新ファイルをダウンロードし(週に一度)、スクリプトを実行するだけですデータはすべて自動で抽出され、グループ化されて使える状態に準備されます。

4. 簡単 インディケータやスクリプトはすべて MQL プログラム言語を使用して書かれており、第三者の DLL は使用されていません。データ体系化と計算にはもっともシンプルなアルゴリズムを使用してきました。問題の分離を行ってきたのです。よってスクリプトに基づくプログラムはグループ用、結合用、アウトプット用、新規データ作成用プログラムのために開発されました。そしてこういったデータはインディケータ構築のために使用されました。

5. 独立性 取得する情報でもっとも重要な要因の一つはそれが発信する『ノード』数です。上方が発信元から宛先へ直接発信される場合、それが歪められる可能性は、発信元と宛先の間にいくつか仲介物がある場合よりも低くなります。プロジェクトはすべて必要な情報が直接発信元から取り込まれるように実装されており、第三者ベンダーは存在しません。

このプロジェクトにはコンパイルされていない複数のプログラムファイルが一式インクルードされています。各ファイルは適切なディレクトリに入れてコンパイルする必要があります。以下のテーブルにはファイルリスト、その簡単な説明、インストール場所が入っています。

ファイル名

タイプ

宛先

説明

Meta COT Script Build.mq4

スクリプト

..\Meta Trader\experts\scripts\

データ準備用の主要な独立スクリプトCFTC.gov サーバーから利用可能な標準 CSV ファイルからファイルセットを作成します。新規ファイルはそれぞれ商品に関する情報です。作成したファイルに対する名前は商品名に対応しています。

Meta COT Script Concatenate.mq4

スクリプト

..\Meta Trader\experts\scripts\

独立スクリプト履歴に基づき複数ファイルを1ファイルに結合します。たとえば、ファイル "COT - SUGAR NO. 11 - NEW YORK BOARD OF TRADE. CSV" (期間 2005.01.04-2007.08.28 のデータ)とファイル "COT - SUGAR NO. 11 - ICE FUTURES U.S. .CSV"(期間 2007.09.04-2009.09.01 のデータ)はファイル "SUGAR CONCATENATE" に作り替えられます。それは2005.01.04~ 2009.09.01 のデータを持つものです。

Meta COT Script Agregation.mq4

スクリプト

..\Meta Trader\experts\scripts\

独立スクリプト値の総和に基づいて複数ファイルを1ファイルに結合します。たとえば、ファイル "COT - WHEAT - CHICAGO BOARD OF TRADE. CSV"、"COT - WHEAT - KANSAS CITY BOARD OF TRADE. CSV"、"COT - WHEAT - MINNEAPOLIS GRAIN EXCHANGE. CSV" は、3件のファイルすべての値の合計を持つ1件のファイル "WHEAT AGREGATION" に作り替えられます。

Meta COT Script Report.mq4

スクリプト

..\Meta Trader\experts\scripts\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。それはレポートファイル CSV を作成し、インディケータすべてに対する計算を持ちます。平均化期間と商品名はスクリプト設定で定義されます。別プログラムのデータ分析に有用です。

Meta COT Absolute Position.mq4

インディケータ

..\Meta Trader\experts\indicators\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。全カテゴリー内で建玉を含むトレーダーの絶対ポジション を示します。

Meta COT Net Position.mq4

インディケータ

..\Meta Trader\experts\indicators\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。全カテゴリー内で建玉を含むトレーダーのネットポジション を示します。

Meta COT Index.mq4

インディケータ

..\Meta Trader\experts\indicators\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。 全カテゴリー内で建玉を含むトレーダーのCOT インデックスを示します。計算期間はスクリプト設定で定義されます。

Meta COT Percent Position in OI.mq4

インディケータ

..\Meta Trader\experts\indicators\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。トレーダーの各カテゴリーについて、ネットポジションを建玉で割った結果を示します。

Meta COT WILLCO.mq4

インディケータ

..\Meta Trader\experts\indicators\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。それはトレーダーの全カテゴリーについて WILLCOインデックスを示します。計算期間はスクリプト設定で定義されます。

Meta COT Movement Index.mq4

インディケータ

..\Meta Trader\experts\indicators\

このスクリプトにはライブラリ "cotlib.mq4" が必要です。トレーダーのカテゴリーそれぞれについて動向指数と建玉を示します。平均化とモメンタム期間はスクリプト設定で定義されます。

Meta COT Spread Movement Index.mq4

インディケータ

..\Meta Trader\experts\indicators\

このインディケータにはライブラリ "cotlib.mq4" が必要です。トレーダーの各カテゴリーについて、動向指数を建玉で割った結果を示します。

Meta COT Expert.mq4

Expert advisor

..\Meta Trader\experts\

expert advisor にはライブラリ "cotlib.mq4" が必要です。これは履歴データに関して COT インディケータを検証しています。

cotlib.mq4

ライブラリ

..\Meta Trader\experts\libraries\

システムのカーネルです。COT データとその処理方法をインクルードしています。大きな配列セット、定義、使用されるインディケータすべてを計算する関数を持ちます。

ONCATENATE.ini

リスト付ファイル

..\Meta Trader\experts\files\

時間でコンバインされるリストを持つファイルリストです。

COT - * CONCATENATE.ini

ファイルリスト

..\Meta Trader\experts\files\

時間でコンバインされるリストを持つファイルリストです。

AGREGATION.ini

リスト付ファイル

..\Meta Trader\experts\files\

総和でコンバインされるリストを持つファイルリストです。

COT - * AGREGATION.ini

ファイルリスト

..\Meta Trader\experts\files\

総和でコンバインされるリストを持つファイルリストです。

テーブル 3-1 インストールパスを持つ Meta COT プロジェクトファイル

適切なディレクトリにこれらファイルをインストールし、コンパイルする必要があります。そのステップ後、ターミナルは適切な MetaTrader カスタムインディケータ、スクリプト、アドバイザーを受け取ります。


3.2データのロードとレポート作成

ごぞんじのとおり、インディケータデータはすべて非営利団体 CFTC によって提供されます。こういったデータは CTFC の公式ウェブサイトに毎週公表されています。レポートは複数種あります。第1がイプは«Futures Only Reports»と呼ばれるもので、先物ポジションデータのみが入っています。第2タイプは«Futures-and-Options Combined Reports»と呼ばれ、そこには先物とオプションデータが入っています。

そこでは市場に関するより完全な情報が提供されています。使用するには好ましいものです。また、特殊なタイプのレポートがあり、«Commodity Index Trader Supplement»と呼ばれています。その主な違いは、それは農産物市場の限定範囲について作成されており、もっとも重要なことは、そこには第4のトレーダーカテゴリ、いわゆる商品指数トレーダー(CIT)が含まれていることです。

こういったトレーダーは中間位置を占めています。一方の側からは彼らの位置はヘッジャーに属し、彼らは «Futures Only Reports»と «Futures-and-Options Combined Reports» に含まれ、もう一方の側からは彼らの動向は大型ヘッジファンドに類似しています。一般的に、彼らはネットの買い手で、ネットの売り手である従来のヘッジャーとは逆です。このトレーダーカテゴリーは市場にパニックを起こしているという意見があります。激しい下落と上昇は主に彼らの行動なのです。彼らは市場をどんな方向にも動かすに十分な力を持っており、同時にその主な目的は投機的利益を得ることです。トレーダーのこのカテゴリーについてのデータは Exel および CSV フォーマットで2007年から利用可能となっています。彼らの行動の履歴は浅いため、その動向の研究は今後の課題であります。現時点では、この種のレポートはプロジェクトによってサポートされていません。

レポートは複数の形式で公表されます。まず、トレードテーブル自体です。«Commodity Index Trader Supplement»はこの形式ではありません。それは Excel および CSV ファイルでのみ利用可能です。

これらテーブルの形式はおなじみのものですね。


図3-1 Exсel 形式での COT レポートの一部

また、通常の Excel テーブルもあります。そこには従来のレポート同様のデータが入っており、唯一の違いはデータが長期間にわたり収集されたものであることです。このテーブルの一部は図 3-2 に表示しています。

図3-2 Exсel 形式での COT レポートの一部

委員会はレポートを CSV で公表しています。この形式は拡張子 «txt» を持つテキストファイルで表され、データはコンマで区切られています。これは Meta COT が使用する唯一の形式であるため、この形式については詳しく説明します。図 3-4 はこのファイルの一部です。

図3-4 CSV 形式での COT レポート例

その構成は混とんとしているように思えますが、そうではありません。ファイルは行と列で構成されています。列数は 128、行数は商品やレポート期間によって決まります。一般的には、レポートファイルには1年分のデータが入っています。たとえば、2009年9月にこの形式でダウンロードされたレポートは2009年1月~2009年9月(本稿執筆日)のデータを持ちます。1行目には128列あり、それは列名です。CSV ファイルはプロジェクトデータを作成する基礎です。

チャートを作成します。長期間に対する COT データを考察するのが好都合です。2000年から現在までのデータを準備します。アドレスhttp://cftc.gov/marketreports/commitmentsoftraders/CFTC009781.html に行くか、http://cftc.govのセクション Home> Market Reports > Commitments of Tradersに行きます。

以下のような画像が表示されます。

図3-5 データアーカイブ

レポートには2タイプあります。先物のみのレポートと、先物とオプションの合成されたレポートです。2000年からのデータを使用したいと思います。先物とオプションに関する2番目のレポートを使用するのが妥当です(ところで、1995年以前のデータは先物レポートでのみ利用可能です)。それらは同一形式となっており、どちらのレポートタイプも使用することができます。9件のファイルすべてを2009年からダウンロードし、2000年で終わりにします。後に、1995年から2008年までのデータをすべて持つファイルも1件ダウンロードしますが、その場合、数多くの商品があります。図3-5 では参照の1つが赤丸で囲われています。ダウンロードされたファイルは、ディレクトリ ..\ Meta Trader folder \ experts \ files \ で解凍します。

アーカイブ内のファイルはすべて annualof.txt という同じ名前です。よって名前をつけなおす必要があります。ファイル名は任意ですが、そのファイル名は names.ini内にリストアップする必要があります。それはぷふぉジェクトの特殊なコンフィギュレーションファイルです。それはひじょうにシンプルで処理されるファイルの簡単なリストです。

たとえば、2009年について "2009_Futures-and-Options.txt"、2008年について "2008_Futures-and-Options.txt" という名前のファイルなどがあれば、この処理されたファイルリストは以下のようなものとなります。

図3-6 COT プロジェクト用処理済みファイルリスト例

例と同様にダウンロードされたファイルに名前をつけなおす場合、names.ini ファイルを編集する必要はありません。デフォルトでスクリプトはこのファイルセットと連携します。なんらかの理由で、他の名前を使う必要があれば、デフォルトで指定されているものの代わりにn names.ini で新しいファイル名を指定します。

よって図 3-6 のようにディレクトリ \files には10件のファイルがあるはずです。

図3-7 フォルダ MetaTrader\experts\files の内容

names.ini の内容は図 3-6 同様です。ファイル names.ini 内のファイル名順序は重要であることに注意が必要です。ファイル名は降順でリストアップされる必要があります。たとえば、1番目は2009年のファイルで最後が2000年のファイル、というようにです。

これでデータが準備でき、Meta COT Script Build スクリプトを実行するときがやってきました。それは自動モードで動作し、オプションはただ1つです。それはファイルリスト名です。この場合、ファイル名は " names.ini" ですが、変更可能です。それはいくらかの問題を柔軟に解決するために必要です。

たとえば、なんらかの商品について、オプションデータはなしに先物データのみを分析したいとします。同時に、別の商品について先物とオプションのより完全なレポートを使用したいと思っています。ご自分のコンピュータに2タイプのレポートをダウンロードし、ファイルリストを2件作成することが可能です。たとえば、names_option.ininames_futures.iniです。

まず、"names_futures.ini"に等しいパラメータ"names_list" でスクリプトを実行して先物に関するデータを取得します。その後、こえらデータは別のフォルダに保存します。そして、再びスクリプトを実行して必要なデータを取得しますが、今回は "names_option.ini"に等しいパラメータ"names_list" で行います。先物およびオプション用データが作成されます。

スクリプト実行後すぐに、CSV 形式のレポートを持つファイルがたくさん "\files" フォルダに作成されます。そのようなファイルはそれぞれ 『COT - 市場名 - exchange.CSV 名』のような形式になっています。

ファイルの多くは不完全です。市場の一部に関する COT レポートは少し表示され、それから完全に消える特性があります。それでもなお、定期的な報告を持つ十分な数の商品があります。後に詳細なレポートのインスツルメントを考察しますが、ここでは作成されたファイルに注目します。その内の一つを利用して、形式を考えます。"COT - NEW ZEALAND DOLLAR - CHICAGO MERCANTILE EXCHANGE.CSV"のような形式になっています。そこにニュージーランド ドル先物について必要な情報があると簡単に推測できます。


ノートパッドでそれを開いて、中身を見ます。

図3-8 ニュージーランドドル

このファイルには、ある商品、この場合はニュージーランドドル、に関して長期の統計が入っているのがわかります。名前付きの列は空白です。このファイルは列名の必要ないインディケータに対して使用されるのです。それでも、これら数字が何を意味するか理解するために、各列を見ます。

I - 商品名II - レポート日付
III - 建玉
IV - 非商業トレーダーのロングポジション
V - 非商業トレーダーのショートポジション
VI - 非商業トレーダーのスプレッド(カバレッジ)
VII - オペレータのロングポジショ
VIII - オペレータのショートポジション
IX - トレーダーレポートの蓄積ロングポジション数
X - トレーダーレポートの蓄積ショートポジション数
XI - 不明なトレーダーのロングポジション

XII - 不明なトレーダーのショートポジション

COT インディケータ構築に必要なものは以上ですべてです。

この段階では、同一の市場情報は異なるファイルにあります。これは、第1に株式市場の名まえが時間の経過とともに変わるため、第2に委員会が商品名自体を変える可能性があること、もしくは見出しでの単純な誤りの可能性が高いためです。商品名変更、一文字の変更でさえデータ抽出プログラムにとっては重大な違いにつながります。

たとえば商品 "COT - SUGAR NO. 11 - COFFEE SUGAR AND COCOA EXCHANGE" と "COT - SUGAR NO. 11 - COFFEESUGAR AND COCOA EXCHANGE" はプログラムにとっては全く異なるもので、商品ファイルに異なる2つの見出しを作成することとなります。砂糖の例を見てみます。スクリプト Meta COT Script Build の実行後、数多くのファイルの中の \files ディレクトリは以下を取得します。

COT - SUGAR NO. 11 - COFFEE SUGAR AND COCOA EXCHANGE .csv
COT - SUGAR NO. 11 - COFFEESUGAR AND COCOA EXCHANGE .csv
COT - SUGAR NO. 11 - ICE FUTURES U.S. .csv
COT - SUGAR NO. 11 - NEW YORK BOARD OF TRADE .csv
COT - SUGAR NO. 14 - COFFEE SUGAR AND COCOA EXCHANGE .csv

最後のファイルは砂糖の別の分類に入り、ほとんど使えるようなデータはありません。よってこのファイルはすぐに削除されます。名前からわかるように、1番目のファイルと2番目のファイルは、同一商品に対応していますが、委員会はこの商品に関するレポート作成に文法的誤りを伴う場合があります。それが2番目のファイル作成に影響を及ぼすのです。3番目と4番目のポジションには同じ砂糖ですが別の為替についてのファイルがあります。それは "ICE FUTURES" と "NEW YORK BOARD OF TRADE" です。

これらファイルを開くと、砂糖取引の年表を特定することができます。

砂糖ファイル名

取引開始日付

取引終了日付

COT - SUGAR NO. 11 - ICE FUTURES U.S. .csv

2007.09.04

2009.09.01

COT - SUGAR NO. 11 - NEW YORK BOARD OF TRADE .csv

2005.01.04

2007.08.28

COT - SUGAR NO. 11 - COFFEE SUGAR AND COCOA EXCHANGE .csv

2003.02.25

2004.12.28

COT - SUGAR NO. 11 - COFFEESUGAR AND COCOA EXCHANGE .csv

2003.01.07

2003.02.14

テーブル 3-9 砂糖に関するレポートを持つファイル

トレード年表からわかるように、データファイルはすべて同じ製品について述べています。よって、これらファイルすべてを1つの連続レポートファイルにまとめるのが妥当です。そのためにスクリプト Meta COT Script Concatenateがあるのです。このスクリプトには、たとえば、 SUGAR CONCATENATE.ini など列挙を伴う特別なファイルが必要です。単一年表にまとめるのに必要な砂糖ファイルはすべてそこにリスト化されています。砂糖ファイルを作成する作業のためには、SUGAR CONCATENATE.iniのような特殊ファイルが転送されます。それは一連の年代順序にまとめるために、砂糖ファイルをすべてリスト化します。

ファイルリストを持つファイル名は中央のファイルリスト CONCATENATE.ini に入れられます。このファイルには、全ファイル名が入っています。その年表をまとめる必要があるのです。MetaCOT プロジェクトには対応するファイルがあり、それらはつぎの形式となっています。:COT - NAME TOOL CONCATENATE.ini。これら名前はファイルリスト CONCATENATE.ini にリストアップされています。

ファイルリストがすべて準備できたら、スクリプトMeta COT Script Concatenateを実行します。それが短時間で実行した後、ファイルと同名で複合ファイルを作成しますが、形式は SCV となります。

処理理論をよりよく理解できるよう、図 3-10を参照します。ファイル CONCATENATE.ini、SUGAR CONCATENATE.ini、その他の階層は以下のようなものです。

図310 ファイル CONCATENATE.ini のリスト化されたファイルとの関連

3.3新規分析ツールとしての合成レポート

関連する商品は数多くあり、それは CFTC レポートに載っています。たとえば、フィーダーキャトルと生体牛の市場価格は密接に相関しています。小麦は米国の取引所3か所で取引されており、価格は互いにひじょうに密接です。

当然、こういた市場への参加者全員の行動もおよそ同じであると予測されます。それなら、これら市場に関するレポートを1件のレポートにまとめてはどうでしょうか?たとえば、オペレータが成牛市場で 20,100 契約、フィードキャトル市場で 15,200 契約を持っている場合、彼らの牛市場での取りまとめたポジションは 35,300 契約に達するわけです。そのような足し算はすべての市場参加者に対して、ショートポジション、ロングポジション両方で行うことができます。

さらに進んで、一般的なさまざまな市場に対する当事者全員の行動を融合します。通貨先物すべてについてのレポートを1件のレポートにまとめ、われわれ独自のドル指数を持つというのはどうでしょうか?x?もしくは、S&P 500 や Dow Jones 30 からの株式指数すべてのレポートをまとめることもできます。結果できるインスツルメントはずっとボリュームが大きく、特定の市場だけでなく業界全体として参加者の視点が含まれることになるのです。

この考えは実現せずに残すにはすばらしすぎるものでした。想像してください。MetaCOT プロジェクトにはそのようなツールがあるのです。それは Meta COT スクリプト集約と呼ばれます。それは、Meta COT スクリプト連結のように作用しますが、違いはレポートを連結するアルゴリズムにあります。それは連結するのに指定されたインスツルメントのリストが必要で、それらインスツルメントのファイル名は1件のファイルにリスト化されます。ファイル名は同様のファイルすべてのリストと共にファイルリストに追加されます。

われわれ独自の「ドル指数」を作成しましょう。まず最初に作成するのは、"Dollar Index Agregation.ini" ファイルで、そこに通貨市場すべてに関するレポート名を入れます。

COT - EURO FX CONCATENATE.csv
COT - BRITISH POUND STERLING CONCATENATE.csv
COT - JAPANESE YEN CONCATENETE.csv
COT - AUSTRALIAN DOLLAR CONCATENATE.csv
COT - CANADIAN DOLLAR CONCATENATE.csv
COT - SWISS FRANC CONCATENATE.csv

これらファイル自体はスクリプト Meta COT スクリプト連結によってマージされることに注意します。名前がリスト化されると、ディレクトリ MetaTrader/expert/files に "COT - DOLLAR INDEX AGREGATION.ini" という名前のファイルを保存しします。名前はなんでもよいのですが、それを使っていくことになります。それからファイル AGREGATION.ini を作成します。それはわれわれの団体名:COT - DOLLAR INDEX AGREGATION.ini、を指定します。

これでファイルを保存し、スクリプト Meta COT スクリプト集約を実行することができます。このスクリプトにはパラメータは1つしかありません。それは実際処理する必要があるファイルリスト名です。われわれの場合、ファイルリスト名が "AGREGATION.ini" であるため、そのパラメータは同名ファイル同様に設定します。スクリプトはファイルリスト "COT - DOLLAR INDEX AGREGATION.ini" に入っているインスツルメンツすべての値をまとめます。われわれの場合、それは全通貨に関するレポートを持つ6件のファイルを使用し、"COT - DOLLAR INDEX AGREGATION.csv" という名前の新しいファイルを作成します。このファイルには、通貨先物すべてについてのレポートのまとめられた値が入っています。

合計されるファイルレポートのリストはみなさんの思いでのみ制限されます。この力強いツールによって、新しいレポート、新しい種類の情報を作成することができるのです!主に便利なことはすべての活動が自動で行われ、みなさんがマニュアルで値をまとめる必要がないことです。

ただし、レポートの一部には、一般的な処理リストに入っている他のレポートと比べると、所定の期間についてデータがありません。この場合、プログラムはそのような時差を特定し、次のようなメッセージでお知らせします。:『--> 時差が見つかりました: 2004年4月21日』。なにもまずいことはありません。実質上それは一般的で定期的に起こるものです。このシナリオでは、プログラムがその他インスツルメントすべてのデータをまとめ、2004年4月21日のデータを含めてレポートを作成します。空白の日のデータに対しては、その前直近のデータが入ります。これは続行する最初のデータとなります。たとえば、2004年4月21日についてまとめられたレポートでは、4月21日にデータがない場合、2004年4月14日のデータが入ります。

レポート結合の際には注意が必要です。商品の1グループが同様に契約金額であり、別のグループは異なることがあります。簡単な例:レポート上の S&P500 指数と2件の先物契約: E ミニ S&P500 とフルサイズの S&P500 。1件の電気先物契約はインデックス値 *5$ に等しく、フルサイズはインデックス値*25$ に等しくなります。契約の数量について、大きな市場の双子は小さな電気の双子に対して敗北を認めているにもかかわらず、その資本は等しく、フルサイズ S&P500 でさえもっと活用されます。残りの多様な市場の適切な追加に関する問題は未解決ですが、基本の付加ツールはすでに今日で、それは注意して適用されます。

3.4インディケータ

インディケータはすべて一つの原理に基づき作成され、同様のカーナルを持ちます。インディケータ カーネルはすべてのデータをロードし、MetaCOTプロジェクトインディケータすべての値を計算しました。インディケータはすべてそのタスクによって定義された値をただ1つだけ表示しますが、実際にはそのコード内に可能なインディケータすべての値を持ちます。この方法はひじょうに成功を収めています。特に売買ロボットを設計する際にです。ライブラリ cotlib.mq4 がインディケータの可能な値をすべて計算するので、それは最適化パラメータとして指定できるのです。

それは毎回新規に実行するごとに、ロボットが新しいインディケータとその計算期間を使うことを意味します。よってこの方法で、ベストなインディケータをとベストな期間を決められるのです。それは最も適したインディケータとトレーダーグループを見つけるのに役立ちます。

必要なレポートファイルがすべて準備できたら、それらをインディケータにロードする必要があります。インディケータはすべて同様で似かよったパラメータストラクチャをしています。

例としてMeta COT ネットインディケータを考察します。

変数タイプ

変数名

デフォルト値

説明

intperiod

156

インディケータ計算期間それは計算期間を必要とするインディケータに対して使用しました(COT インデックス、WILLCO 等)。通常156週平均化が使用されます。

oolShowNoncomm

真であれば、インディケータは非商業トレーダーのトータル ネットポジションを表示します。

boolShowOperators

であれば、インディケータはオペレータのトータル ネットポジションを表示します

boolShowNonrep

であれば、インディケータは非商業トレーダーのトータル ネットポジションを表示します。

boolShowOI

であれば、インディケータは建玉指数を表示します。

boolload_cot_file

それがであれば、インディケータは名前付きで準備済みのレポートファイルをロードします。そのファイルはcot_file変数
により指定されたものです。

stringcot_file

cot-sample.txt

load_cot_file 変数がであれば、変数にはロードに必要なレポートファイル名が入っています。

stringsettings

settings.txt

インディケータとレポート間の対応についての設定ファイルです。プログラムはファイル内に現在のチャート名を見つけ、同じ名前のレポートを使用します。

図3-11 Meta COT ネットポジション インディケータの変数

まず、平均化を行うインディケータすべてには外部変数 期間があります。デフォルトでは 156(3年平均化)です。

次に、インディケータはすべてブール変数を持ちます。それによりインディケータの描画がカスタマイズできます(たとえば、市場参加者グループを定義することができます)。

そして次に、インディケータには変数が3つあります。load_cot_file、cot_file、設定です。その変数を詳しく考察します。インディケータにはすべて、いわゆる『対応ファイル』があり、デフォルトでは "settings.ini"と名付けられています。選択されたチャートの分析のためダウンロードする必要のあるレポート名を毎回マニュアルで選択するのはきわめて不便です。各商品はそれぞれのレポートが必要です。ファイル settings.ini が現在チャート用にダウンロードしたいレポート種を決めてくれます。たとえば、変数 load_cot_file が偽で、インディケータ Meta COT Net Position をチャート GBPUSD で開始する場合、インディケータにはが自動的に "COT - BRITISH POUND STERLING CONCATENATE.csv" という名前のレポートを選択し、チャートにアップロードしてくれるのです。商品名がレポート名に一致したシンプルなファイルのおかげでそれがすべて可能なのです。

デフォルトでは Meta COT はすでにそのようなファイルを持っています。これは以下のような一般的な CSV ファイルです。

レポートのファイル名、インディケータ名、1番目の商品に対する最初の有意な性質、N 番目の商品に対する最初の有意な性質。

たとえば、自動でレポート COT - SWISS FRANC CONCATENATE.csv をダウンロードしたい場合、インディケータがチャート 6S および USDCHF にアタッチしたあと毎回、ファイルに以下の行を追加する必要があります。
COT - SWISS FRANC CONCATENATE.csv;SWISS FRANC;6S;USDCHF

この場合、シンボル «6S» は異なる実行日のスイスフランの様々な先物に対する集合的な名前です。たとえば、契約 6S_CONT、6SU9、6SU9#I、6SZ9、6SZ9#I でトレードされるスイスフランの例です。このうち1番目のものは戦略バックテストに対する連続先物です。システムにとっては、インディケータ用にすべてのスイスフラン先物について同じレポートを指標するためには、商品の最初の有意な性質を指定するだけで十分です(この場合は 6S)。最終行はある種の『キャップ』です。ファイルの内容がすべて調べられ、必要なレポートが見つからなければ、インディケータは最終レポート名を表示します。この場合、使用されているレポート名の代わりに「商品のレポートは見つかりませんでした」という警告が表示されます。この場合には、変数load_cot_file にかかわらず、変数 cot_fileによって定義された名前のレポートがアップロードされることとなります。

行末のセミコロンがないことに注意してください。ここでは、インディケータはレポート COT - SWISS FRANC CONCATENATE.csv をダウンロードし、インディケータ名は Meta COT Index (156): SWISS FRANC に変更されます。"SWISS FRANC" 名は列の2番目の行から採られます。平均化期間は、括弧内で指定される期間変数によって定義されます。特定のブローカーに連結するよう構成されているファイルの全コンテンツは図3-8 で参照可能です。みなさんのブローカーの商品はこれら名前と異なることにご注意ください。みなさんのブローカーの商品の中で対応する名前を見つけ、上述のルールに従ってファイル settings.ini に追加する必要があります。

商品分析にデフォルト値に対応していないレポート名を持つ指定ファイルをダウンロードする必要がある場合もあります。この場合は、変数 load_cot_file を真に設定し、変数 cot_file 内で必要なファイルレポート名を指定する必要があります。インディケータ名は、ツール名にかかわらず、必要なファイルレポートをロードします。

図3-8 settings.ini ファイルの例

幅広いタスクのために、データ分析に Microsoft Excel のような第三者プログラムを利用することが可能です。その場合には、指定の商品に対して Meta COT によって計算された値を使用し、インディケータ値を第三者プログラムにダウンロートするのが便利です。そのような場合に備え、特別なスクリプト Meta COT スクリプト レポート が作成されています。動作のためにはライブラリ cotlib.mq4 が必要です。それはインディケータと同様のパラメータを持ちます。計算期間(period)と動向指数(movement_index)です。対象としている商品に対して実行したあと、それは \files ディレクトリ内にファイル Meta COT Report REPORT TITLE.csv を作成します。このファイルは、現対象商品に対する基本値と共にインディケータすべての値を持ちます。

これでインディケータがすべて構成され、動作しています。次にレポートをすべて削除します。Meta COT はデータを更新しません。また毎回、データセットを一から作成するか、既存のデータセットに付け足します。それは、スクリプト実行前に古いデータを削除する必要があることを意味します。残念ながら、MetaTrader はファイル削除用の組み込み関数を持ちませんので、マニュアルでするしかありません。一番都合の良い方法は、バッチファイルコマンドまたはバットファイルを作成することです。

このファイルはすでにあり、erase_cot.bat という名前がついています。それは1行のみです。

erase COT*.csv

実行後、それは拡張子 CSV があって COT で始まる名前のファイルをすべて削除します。

削除後、ファイル作成手順が再び繰り返されます。


3.5ソースコード

管理が簡単な修正プロジェクトを作成してきました。それはあらゆる機械的なトレーディングシステムに容易に適応できるものです。

SCV 委員会レポートから取得するデータのメカニズムは独立プログラムMeta COT Script Build に実装されます。アルゴリズムはひじょうにシンプルなプログラムで、それは管理のしやすさとさらなる変更を保証するものです。最初にプログラムは処理対象ファイル名のリストを開きます。ファイル名は単一パラメータで指定されるファイル内にあります(デフォルトでは names.ini です)。1番目のファイル名を読んだら、スクリプトはディレクトリ内の同名ファイルを開こうとします。ファイルが存在すれば、スクリプトが SCV ファイルを列から列へ読み始めます。ファイルの終わりで列カウンターをリセットします。列カウンターが列のリフレッシュを必要としたら(特殊関数で値チェックします)、その値が即宛先ファイルにレコードされ、その後にセミコロンが入ります。

最終ファイルの作成手順について詳しく説明する必要があります。列カウンターが、現時点でプログラムが1番目の列(商品名)に進むことを指定する場合、この名前を読み、同盟のファイルを開こうとします。ファイルが存在しなければ、プログラムはそれを作成し、すばらしいことにファイルの末尾にデータを追加してくれます。そのため、データ現実化の前に毎回既存のファイルを削除する必要があります。後続の列の値はロードされ、このファイルに追加されます。列カウンターがゼロになったら、プログラムは現アウトプットファイルを閉じます。委員会レポートファイルが処理されたら、プログラムはファイルリストで指定された次のファイルを開こうとします。

プログラムは先物の名前やそのグループ化順序を何も知らないことが判明します。原則として、全商品名はラ異なるファイルにンダムに配置される可能性があります。最終結果はつねに同じです。1商品に1レポートファイルです。

以下が Meta COT Script Build のソースコードです。

#property copyright "Copyright © 2009, C-4, All Rights Reserved."
#property link      "vs-box@mail.ru"
#property show_inputs
// Definitions
#define Market_and_Exchange_Names 1
#define As_of_Date_in_Form_YYMMDD 2
#define As_of_Date_in_Form_YYYY_MM_DD 3
#define CFTC_Contract_Market_Code 4
#define CFTC_Market_Code_in_Initials 5
#define CFTC_Region_Code 6
#define CFTC_Commodity_Code 7
#define Open_Interest_All 8
#define Nonc_Positions_Long_All 9
#define Nonc_Positions_Short_All 10
#define Nonc_Positions_Spreading_All 11
#define Commercial_Positions_Long_All 12
#define Commercial_Positions_Short_All 13
#define Total_Reportable_Pos_Long 14
#define Total_Reportable_Pos_Short 15
#define Nonrep_Positions_Long_All 16
#define Nonrep_Positions_Short_All 17

extern string name_list="names.ini";
//string normalize_name;
int a;
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int start()
  {
   int CFileNames,
   cot_file,
   tools_data;

   int column,
   column_now,
   column_string;
   int cot;
   bool IsOldInfo=true;
   string name_cotfile;
   string data,data2,
   normalize_name,
   string_cot;

   CFileNames=FileOpen(name_list,FILE_READ|FILE_CSV);
   if(TrueFileName(CFileNames,name_list)==false)return(1);
   Print("The file list: ",CFileNames);
// Open a file list with reports
   while(FileIsEnding(CFileNames)==false)
     {
      cot++;
      name_cotfile=FileReadString(CFileNames);
      cot_file=FileOpen(name_cotfile,FILE_READ|FILE_CSV,",");
      if(TrueFileName(cot_file,name_cotfile)==false)return(1);
      else Print("File not found");

      // Skip first string
      while(FileIsLineEnding(cot_file)==false)
        {
         column++;
         FileReadString(cot_file);
        }

      while(FileIsEnding(cot_file)==false)
        {
         data=FileReadString(cot_file);
         column_string++;
         if(FileIsLineEnding(cot_file)==true || FileIsEnding(cot_file)==true)
           {
            column_string=0;
            FileWrite(tools_data,string_cot);
            FileClose(tools_data);
            string_cot="";
           }
         else
           {
            if(TrueDataNew(column_string)==true)
              {// check for the comma in the instrument name
               data=NormalizeData(data);
               if(column_string==Market_and_Exchange_Names)
                 {

                  data2=FileReadString(cot_file);        // see comment1!
                  if(CheckValidColumn(data2)==true)      //
                     data=data+NormalizeColumn(data2);   //
                  else column_string++;
                  //data=NormalizeNames(data);
                  tools_data=FileOpen("COT - "+data+".csv",FILE_READ|FILE_WRITE|FILE_CSV);
                  TrueFileName(tools_data,data);
                  FileSeek(tools_data,0,SEEK_END);
                  string_cot=string_cot+data;
                 }
               else
                 {
                  if(column_string==As_of_Date_in_Form_YYYY_MM_DD)data=ConvertData(data);
                  string_cot=string_cot+";"+data;
                 }
              }
           }
        }
      Print("Total lines: ",column);
     }
   Print(a);
   return(0);
  }

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
string ConvertData(string data)
  {
   string c_data="";
   int strlen=StringLen(data);
   int char;
   for(int i=0;i<strlen;i++)
     {
      char=StringGetChar(data,i);
      if(char=='-')c_data=c_data+".";
      else c_data=StringConcatenate(c_data,CharToStr(char));
     }
   return(c_data);
  }
// If the current cell is necessary for combined COT report, it returns true,
// Overwise it returns false. The list of the cells used are set as defines
bool TrueDataNew(int column_string)
  {
   switch(column_string)
     {
      case Market_and_Exchange_Names:
      case As_of_Date_in_Form_YYYY_MM_DD:
      case Open_Interest_All:
      case Nonc_Positions_Long_All:
      case Nonc_Positions_Short_All:
      case Nonc_Positions_Spreading_All:
      case Commercial_Positions_Long_All:
      case Commercial_Positions_Short_All:
      case Total_Reportable_Pos_Long:
      case Total_Reportable_Pos_Short:
      case Nonrep_Positions_Long_All:
      case Nonrep_Positions_Short_All:
         return(true);
      default:
         return(false);
     }
  }

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
string NormalizeData(string file_name)
  {

   int char;
   int strlen;
   string normalize_name="";
   string normalize_name_p="";
   strlen=StringLen(file_name);
   for(int i=0;i<strlen;i++)
     {
      char=StringGetChar(file_name,i);
      switch(char)
        {
         case '/':
         case '\\':
         case ':':
         case '*':
         case '\"':
         case '<':
         case '>':
         case '|':
         case ';':
            break;
         default:
            // If the last symbol of the string is space, delete it.
            //if(char==" "&&i==strlen-1)break;
            normalize_name=StringConcatenate(normalize_name,CharToStr(char));
        }
     }
   return(normalize_name);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
string NormalizeNames(string data)
  {
   int strlen=StringLen(data);
   string n_data;
   data=StringTrimRight(data);
   if(CharToStr(StringGetChar(data,strlen-1))==".")StringSetChar(data,strlen-1,"");
   return(data);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
bool TrueFileName(int handle,string filename)
  {
   if(handle==-1)
     {
      Print("Can't open the file: ",filename," Last Error: ",GetLastError());
      return(false);
     }
   else return(true);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
bool CheckValidColumn(string column_name)
  {
   int strlen=StringLen(column_name);
   if(StringFind(column_name,"\"")!=-1){a++;return(true);}
   return(false);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
string NormalizeColumn(string column)
  {
   string n_column;
   int char;
   int strlen=StringLen(column);
   for(int i=0;i<strlen;i++)
     {
      char=StringGetChar(column,i);
      if(char=='\"')continue;
      else n_column=StringConcatenate(n_column,CharToStr(char));
     }
   return(n_column);
  }
//+------------------------------------------------------------------+

インディケータの動作はより難解です。インディケータはすべてほとんど同じコード-cotlib.mq4 ライブラリ、で構成されています。そのストラクチャは以下のような複数パートに分割されます。

1. 定義 -プロセッサ定数、データテーブル(配列セット)の説明

2. 初期化 -ダウンロードされたデータサイズの計算、配列サイズの配信(関数 init_data ())

3. レポートファイルからのデータロード(関数 load_data ())

4. レポートデータを使用したインディケータ値の計算 (関数 count_data ())

インディケータ値へのアクセスには関数 get_data (int タイプ、int バー) が使用されます。パラメータは2つあります。返されるインディケータ値の数と、インディケータ値を求めたいバーインデックスです。たとえば、現在バー (bar = 0)に対するオペレータのWILLCO インディケータのインディケータ値を求めたければ、関数呼び出しはget_data (WILLCO_OPERATORS, 0)、 "WILLCO_OPERATORS" となります。ここにプロセッサに指定された名前付き整数定数の定義があります。

計算済みインディケータすべてに対する平均化期間は同じで、インディケータ初期化の前に選択する必要があります(入力パラメータの変更後は、自動的にインディケータ初期化が行われます)。読み出しに必要なファイルは関数 void settings_load (void)によって自動で判断されます。それは構成ファイルを開き(デフォルトで settings.ini)、要求されるレポートの商品リスト内で現在の商品(Symbol ())を見つけようとします。レポートがこの商品名と一致していれば、関数はそれをダウンロードします。現行の商品に対するレポートが存在しない場合は、デフォルト(パラメータ:名前)で商品をロードします。

#property copyright "Copyright © 2009, C-4, All Rights Reserved."
#property link      "vs-box@mail.ru"
// Possible "type" of parameter values for function get_data()
#define OI                    0
#define NONCOMM_LONG          1
#define NONCOMM_SHORT         2
#define OPERATORS_LONG        3
#define OPERATORS_SHORT       4
#define NONREP_LONG           5
#define NONREP_SHORT          6
#define NET_NONCOMM           7
#define NET_OPERATORS         8
#define NET_NONREP            9
#define OI_NONCOMM_LONG       10
#define OI_NONCOMM_SHORT      11
#define OI_OPERATORS_LONG     12
#define OI_OPERATORS_SHORT    13
#define OI_NONREP_LONG        14
#define OI_NONREP_SHORT       15
#define WILLCO_NONCOMM        16
#define WILLCO_OPERATORS      17
#define WILLCO_NONREP         18
#define INDEX_OI              19
#define INDEX_NONCOMM         20
#define INDEX_OPERATORS       21
#define INDEX_NONREP          22
#define MOVEMENT_NONCOMM      23
#define MOVEMENT_OPERATORS    24
#define MOVEMENT_NONREP       25
#define MOVEMENT_OI           26
#define OI_NET_NONCOMM        27
#define OI_NET_OPERATORS      28
#define OI_NET_NONREP         29


extern bool   load_cot_file=false;
extern string cot_file="COT - U.S. DOLLAR CONCATENATE.csv";
extern string settings="settings.ini";
string name;
bool error=false;
int column;
bool DrawData=true;
bool LoadData=true;


//**********************************************************************************************************
//                                     COT DATA TABLE
int n_str;                    // number of strings

                              // Array with dates
datetime realize_data[];
// Arrays with absolute positions
double open_interest[];       // Open Interest value
double noncomm_long[];        // Long positions of non-commercial traders
double noncomm_short[];       // Short positions of non-commercial traders
double noncomm_spread[];      // Spread of non-commercial traders
double operators_long[];      // Long positions of operators
double operators_short[];     // Short positions of operators
double nonrep_long[];         // Long positions of unreported traders (crowd)
double nonrep_short[];        // Shortpositions of unreported traders (crowd)

                              // An arrays contain the result of division of the absolute long position 
                              // by short position for each of the category of traders

double oi_noncomm_long[];     // Open Interest / Long positions of noncommercial traders
double oi_noncomm_short[];    // Open Interest / Short positions of noncommercial traders
double oi_operators_long[];   // Open Interest / Long positions of noncommercial traders (operators)
double oi_operators_short[];  // Open Interest / Short positions of noncommercial traders (operators)
double oi_nonrep_long[];      // Open Interest / Long positions of unreported traders (crowd)
double oi_nonrep_short[];     // Open Interest / Short positions of unreported traders (crowd)

                              // An arrays contain the result of division of the total net position by Open Interest
                              // for each of the category of traders, it used for WILLCO calculation
double oi_net_noncomm[];
double oi_net_operators[];
double oi_net_nonrep[];

// Arrays with net positions of several groups of traders
double net_noncomm[];         // Net position of noncommercial traders
double net_operators[];       // Net position of commercial traders
double net_nonrep[];          // Net position of unreported traders

double index_oi[];            // Index of Open Interest
double index_ncomm[];         // Index of noncommercial traders
double index_operators[];     // Index of commercial traders (operators)
double index_nonrep[];        // Index of unreported traders (crowd)

                              // Arrays with Stochastic, calculated on division of
                              // Open Interest by Total net position for each category of traders
                              // Stohastic(OI/NET_POSITION)
double willco_ncomm[];        // 
double willco_operators[];    //
double willco_nonrep[];       //

                              //MOVEMENT INDEX
double movement_oi[];
double movement_ncomm[];
double movement_operators[];
double movement_nonrep[];
//**********************************************************************************************************
//
bool init_data()
  {
   string data;
   int handle_cotfile;
   int str;
   settings_load();
   handle_cotfile=FileOpen(cot_file,FILE_READ|FILE_CSV);
//handle_cotfile=FileOpen("COT - U.S. DOLLAR CONCATENATE.csv",FILE_READ|FILE_CSV);
   if(handle_cotfile==-1)
     {
      Print("Can't load file. The further work is not possible ",cot_file);
      Print(GetLastError());
      return(false);
     }
   while(FileIsEnding(handle_cotfile)==false)
     {
      data=FileReadString(handle_cotfile);
      if(FileIsLineEnding(handle_cotfile) && data!="")str++;
     }
   ArrayResize(realize_data,str);

   ArrayResize(open_interest,str);
   ArrayResize(noncomm_long,str);
   ArrayResize(noncomm_short,str);
   ArrayResize(noncomm_spread,str);
   ArrayResize(operators_long,str);
   ArrayResize(operators_short,str);
   ArrayResize(nonrep_long,str);
   ArrayResize(nonrep_short,str);

   ArrayResize(oi_noncomm_long,str);
   ArrayResize(oi_noncomm_short,str);
   ArrayResize(oi_operators_long,str);
   ArrayResize(oi_operators_short,str);
   ArrayResize(oi_nonrep_long,str);
   ArrayResize(oi_nonrep_short,str);

   ArrayResize(oi_net_noncomm,str);
   ArrayResize(oi_net_operators,str);
   ArrayResize(oi_net_nonrep,str);

   ArrayResize(net_noncomm,str);
   ArrayResize(net_operators,str);
   ArrayResize(net_nonrep,str);

   ArrayResize(index_oi,str);
   ArrayResize(index_ncomm,str);
   ArrayResize(index_operators,str);
   ArrayResize(index_nonrep,str);

   ArrayResize(willco_ncomm,str);
   ArrayResize(willco_operators,str);
   ArrayResize(willco_nonrep,str);

   ArrayResize(movement_oi,str);
   ArrayResize(movement_ncomm,str);
   ArrayResize(movement_operators,str);
   ArrayResize(movement_nonrep,str);

   FileClose(handle_cotfile);
   return(true);
  }

void settings_load()
  {
   int h_set,_column;
   string set,sname;
   if(load_cot_file==true)return;
   h_set=FileOpen(settings,FILE_READ|FILE_CSV,";");
//FileOpen("\Temp\Cot_file.txt",FILE_WRITE,FILE_CSV);
   if(h_set==-1)return;
   while(FileIsEnding(h_set)==false)
     {
      set=FileReadString(h_set);
      _column++;
      if(set==Symbol() && _column!=1){cot_file=sname;return;}
      if(_column==2 && set!="")name=set;    // The second column is the desired indicator name
      if(FileIsLineEnding(h_set)==true)_column=0;
      if(_column==1)sname=set;

     }
   FileClose(h_set);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void load_data()
  {
   datetime data_realize;
   int handle_cotfile;
   string data;
   handle_cotfile=FileOpen(cot_file,FILE_READ|FILE_CSV,";");
   Print("Файл найден");
   while(FileIsEnding(handle_cotfile)==false)
     {
      data=FileReadString(handle_cotfile);
      column++;
      if(FileIsLineEnding(handle_cotfile)==true || FileIsEnding(handle_cotfile)==true)
        {//column=12 - special case
         if(column==12)
            nonrep_short[n_str]=StrToDouble(data);
         column=0;
         if(data!="")n_str++;
        }
      else
        {
         switch(column)
           {
            case 2:
               realize_data[n_str]=StrToTime(data);
               break;
            case 3:
               open_interest[n_str]=StrToDouble(data);
               //Print(open_interest[n_str]);
               break;
            case 4:
               noncomm_long[n_str]=StrToDouble(data);
               break;
            case 5:
               noncomm_short[n_str]=StrToDouble(data);
               break;
            case 6:
               noncomm_spread[n_str]=StrToDouble(data);
               break;
            case 7:
               operators_long[n_str]=StrToDouble(data);
               break;
            case 8:
               operators_short[n_str]=StrToDouble(data);
               break;
            case 11:
               nonrep_long[n_str]=StrToDouble(data);
               break;
           }
        }
     }
   FileClose(handle_cotfile);
   Print("Fil loaded");
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void count_data()
  {
   int    max,
   min;
   double delta;

   for(int i=0;i<n_str;i++)
     {
      index_oi[i]=EMPTY_VALUE;
      index_ncomm[i]=EMPTY_VALUE;
      index_operators[i]=EMPTY_VALUE;
      index_nonrep[i]=EMPTY_VALUE;
      willco_ncomm[i]=EMPTY_VALUE;
      willco_operators[i]=EMPTY_VALUE;
      willco_nonrep[i]=EMPTY_VALUE;
      movement_ncomm[i]=EMPTY_VALUE;
      movement_operators[i]=EMPTY_VALUE;
      movement_nonrep[i]=EMPTY_VALUE;
     }
   for(i=0;i<n_str;i++)
     {
      if(open_interest[i]==0)
        {
         oi_noncomm_long[i]=0;
         oi_noncomm_short[i]=0;
         oi_operators_long[i]=0;
         oi_operators_short[i]=0;
         oi_nonrep_long[i]=0;
         oi_nonrep_short[i]=0;
        }
      else
        {
         oi_noncomm_long[i]=noncomm_long[i]/open_interest[i];
         oi_noncomm_short[i]=noncomm_short[i]/open_interest[i];
         oi_operators_long[i]=operators_long[i]/open_interest[i];
         oi_operators_short[i]=operators_short[i]/open_interest[i];
         oi_nonrep_long[i]=nonrep_long[i]/open_interest[i];
         oi_nonrep_short[i]=nonrep_short[i]/open_interest[i];
        }

      net_noncomm[i]=noncomm_long[i]-noncomm_short[i];
      net_operators[i]=operators_long[i]-operators_short[i];
      net_nonrep[i]=nonrep_long[i]-nonrep_short[i];

      if(open_interest[i]==0)
        {
         oi_net_noncomm[i]=0;
         oi_net_operators[i]=0;
         oi_net_nonrep[i]=0;
        }
      else
        {
         oi_net_noncomm[i]=net_noncomm[i]/open_interest[i];
         oi_net_operators[i]=net_operators[i]/open_interest[i];
         oi_net_nonrep[i]=net_nonrep[i]/open_interest[i];
        }
     }

   for(i=0;i<n_str-period;i++)
     {

      max=ArrayMaximum(open_interest,period,i);
      min=ArrayMinimum(open_interest,period,i);
      delta=open_interest[max]-open_interest[min];
      if(delta==0)delta=1;
      index_oi[i]=(open_interest[i]-open_interest[min])/delta*100;

      max=ArrayMaximum(net_noncomm,period,i);
      min=ArrayMinimum(net_noncomm,period,i);
      delta=net_noncomm[max]-net_noncomm[min];
      if(delta==0)delta=1;
      index_ncomm[i]=(net_noncomm[i]-net_noncomm[min])/delta*100;

      max=ArrayMaximum(net_operators,period,i);
      min=ArrayMinimum(net_operators,period,i);
      delta=net_operators[max]-net_operators[min];
      if(delta==0)delta=1;
      index_operators[i]=(net_operators[i]-net_operators[min])/delta*100;

      max=ArrayMaximum(net_nonrep,period,i);
      min=ArrayMinimum(net_nonrep,period,i);
      delta=net_nonrep[max]-net_nonrep[min];
      if(delta==0)delta=1;
      index_nonrep[i]=(net_nonrep[i]-net_nonrep[min])/delta*100;

      max=ArrayMaximum(oi_net_noncomm,period,i);
      min=ArrayMinimum(oi_net_noncomm,period,i);
      delta=oi_net_noncomm[max]-oi_net_noncomm[min];
      if(delta==0)delta=1;
      willco_ncomm[i]=(oi_net_noncomm[i]-oi_net_noncomm[min])/delta*100;

      max=ArrayMaximum(oi_net_operators,period,i);
      min=ArrayMinimum(oi_net_operators,period,i);
      delta=oi_net_operators[max]-oi_net_operators[min];
      if(delta==0)delta=1;
      willco_operators[i]=(oi_net_operators[i]-oi_net_operators[min])/delta*100;

      max=ArrayMaximum(oi_net_nonrep,period,i);
      min=ArrayMinimum(oi_net_nonrep,period,i);
      delta=oi_net_nonrep[max]-oi_net_nonrep[min];
      if(delta==0)delta=1;
      willco_nonrep[i]=(oi_net_nonrep[i]-oi_net_nonrep[min])/delta*100;
     }
   for(i=0;i<n_str-period-movement_index;i++)
     {
      movement_oi[i]=index_oi[i]-index_oi[i-movement_index];
      movement_ncomm[i]=index_ncomm[i]-index_ncomm[i-movement_index];
      movement_operators[i]=index_operators[i]-index_operators[i-movement_index];
      movement_nonrep[i]=index_nonrep[i]-index_nonrep[i-movement_index];
     }
  }
// Returns one of the COT table values
// defined by "type" variable and bar defined by "bar"
double get_data(int type,int bar)
  {
   double data;
   int i_data=get_cot(bar);
   if(i_data==EMPTY_VALUE)return(EMPTY_VALUE);
   switch(type)
     {
      case OI:
         return(open_interest[i_data]);
      case NONCOMM_LONG:
         return(noncomm_long[i_data]+noncomm_spread[i_data]);
         //return(noncomm_long[i_data]);
      case NONCOMM_SHORT:
         return(noncomm_short[i_data]+noncomm_spread[i_data]);
         //return(noncomm_short[i_data]);
      case OPERATORS_LONG:
         return(operators_long[i_data]);
      case OPERATORS_SHORT:
         return(operators_short[i_data]);
      case NONREP_LONG:
         return(nonrep_long[i_data]);
      case NONREP_SHORT:
         return(nonrep_short[i_data]);
      case NET_NONCOMM:
         return(net_noncomm[i_data]);
      case NET_OPERATORS:
         return(net_operators[i_data]);
      case NET_NONREP:
         return(net_nonrep[i_data]);
      case INDEX_OI:
         return(index_oi[i_data]);
      case INDEX_NONCOMM:
         return(index_ncomm[i_data]);
      case INDEX_OPERATORS:
         return(index_operators[i_data]);
      case INDEX_NONREP:
         return(index_nonrep[i_data]);
      case OI_NONCOMM_LONG:
         return(oi_noncomm_long[i_data]);
      case OI_NONCOMM_SHORT:
         return(oi_noncomm_short[i_data]);
      case OI_OPERATORS_LONG:
         return(oi_operators_long[i_data]);
      case OI_OPERATORS_SHORT:
         return(oi_operators_short[i_data]);
      case OI_NONREP_LONG:
         return(oi_nonrep_long[i_data]);
      case OI_NONREP_SHORT:
         return(oi_nonrep_short[i_data]);
      case WILLCO_NONCOMM:
         return(willco_ncomm[i_data]);
      case WILLCO_OPERATORS:
         return(willco_operators[i_data]);
      case WILLCO_NONREP:
         return(willco_nonrep[i_data]);
      case OI_NET_NONCOMM:
         return(oi_net_nonrep[i_data]);
      case OI_NET_OPERATORS:
         return(oi_net_operators[i_data]);
      case OI_NET_NONREP:
         return(oi_net_nonrep[i_data]);
      case MOVEMENT_NONCOMM:
         return(movement_ncomm[i_data]);
      case MOVEMENT_OPERATORS:
         return(movement_operators[i_data]);
      case MOVEMENT_NONREP:
         return(movement_nonrep[i_data]);
      case MOVEMENT_OI:
         return(movement_oi[i_data]);
     }
   return(EMPTY_VALUE);
  }
// Returns the cell number in array
// It returns an EMPTY_VALUE, if bar hasn't been found
int get_cot(int i)
  {
   datetime tbar=iTime(Symbol(),0,i);
   for(int k=0;k<n_str;k++)
      if(realize_data[k]<tbar)return(k);
   return(EMPTY_VALUE);
  }
// Returns bar with the last COT data exist
int get_lastdata()
  {
   return(iBarShift(Symbol(),0,realize_data[n_str-1],false));
  }
// Returns a string without extension and first 6 symbols
// (before was "COT - FileName.csv", it became "FileName")
string str_trim(string fname)
  {
   int strlen=StringLen(fname)-1;
   int char;
   string str;
   for(int i=strlen;i>0;i--)
     {
      char=StringGetChar(fname,i);
      if(char=='.')
        {
         for(int b=6;b<i;b++) // change to b=0, if it is not necessary 
                              // to delete the first of 6 symbols
            str=str+CharToStr(StringGetChar(fname,b));
         return(str);
        }
     }
   return(fname);
  }
//+------------------------------------------------------------------+

インディケータ自体のコードは問題ではなく、初期化されたバッファ数と関数 get_data () の最初のパラメータが異なるだけです。値はすべて初期化段階で事前に計算されるため、関数 IndicatorCounted () は使用しません。初期化の間、冒頭で、ライブラリcotlib.mq4 から基本関数が呼び出され、それがチャートを構成し、それから関数 start () を開始します。それはすぐに関数 build_data () を一度だけ実行します。これはレポートデータの期間についてインディケータウィンドウ内のデータを表示します。

例として、以下はインディケータ WILLCO のソースコードです。

#property copyright "Copyright © 2009, C-4, All Rights Reserved."
#property link      "vs-box@mail.ru"

#property indicator_separate_window
#property  indicator_buffers 3
#property  indicator_color1  Green
#property  indicator_color2  Red
#property  indicator_color3  Blue

extern int  period=52;
int movement_index=6;
extern bool Show_iNoncomm=false;
extern bool Show_iOperators=true;
extern bool Show_iNonrep=false;

double i_willco_noncomm[];
double i_willco_operators[];
double i_willco_nonrep[];

#include <cotlib.mq4>
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int init()
  {
   if(init_data()==false)error=true;
   if(error==false)load_data();
   if(error==false)count_data();
//if(error==false)count_index(period);
   SetParam();
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int start()
  {
   if(error==true)Print("Can't load data. The further work is impossible");
   if(DrawData==true)build_data();
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void SetParam()
  {
   SetIndexStyle(0,DRAW_LINE);
   SetIndexStyle(1,DRAW_LINE);
   SetIndexStyle(2,DRAW_LINE);
   IndicatorDigits(2);
   SetIndexEmptyValue(0,EMPTY_VALUE);
   SetIndexEmptyValue(1,EMPTY_VALUE);
   SetIndexEmptyValue(2,EMPTY_VALUE);
   SetLevelValue(0,0.0);
   SetLevelValue(1,20.0);
   SetLevelValue(2,80.0);
   SetLevelValue(3,100.0);
   if(load_cot_file==true)IndicatorShortName(StringConcatenate("Meta COT WILLCO (",period,"): ",str_trim(cot_file)));
   else IndicatorShortName(StringConcatenate("Meta COT WILLCO (",period,"): ",name));
   if(Show_iNoncomm==true)
     {
      SetIndexBuffer(0,i_willco_noncomm);
      SetIndexLabel(0,"WILLCO: Noncommercial Traders");
     }
   if(Show_iOperators==true)
     {
      SetIndexBuffer(1,i_willco_operators);
      SetIndexLabel(1,"WILLCO: Operators Traders");
     }
   if(Show_iNonrep==true)
     {
      SetIndexBuffer(2,i_willco_nonrep);
      SetIndexLabel(2,"WILLCO: Nonrep Traders");
     }
  }

void build_data()
  {
   int end_data=get_lastdata();
   for(int i=0;i<end_data;i++)
     {
      if(Show_iNoncomm)
        {
         i_willco_noncomm[i]=get_data(WILLCO_NONCOMM,i);
         if(Show_iOperators)i_willco_operators[i]=get_data(WILLCO_OPERATORS,i);
         if(Show_iNonrep)i_willco_nonrep[i]=get_data(WILLCO_NONREP,i);
        }
      DrawData=false;
     }
//+------------------------------------------------------------------+

プログラムの最もむつかしい部分は、1レポート内のデータをまとめるスクリプト作成です。解決されているべきアルゴリズムの問題が数多くあります。プログラムは古い C スタイルで書かれています。それは関数呼び出しなしで単一ユニットで構成されています。そのような方法は不十分、または誤っているようにさえ思えますが、この場合は、異なる『サブタスク』に分割すうることなく問題を即座に解決するにはベストは解決方法だったのです。

始めの部分で、プログラムはファイルリストを開き、結合するファイル名を読み、そのファイルを1件ずつ開いています。各ファイルには結合されるべきレポートリストが入っています。プログラムはこれらレポートをすべて一度に開き、その値を読み出し、1行ずつ処理しています(フォーマットではSCV 行は1列です)。それから、同じ日付(2列目の値)の値を一緒に追加しています。値の合計は最終ファイルにレコードされます。それには結合するファイルと同じ名前がはいっていますが、拡張子は CSV です。

#property copyright "Copyright © 2009, C-4, All Rights Reserved."
#property link      "vs-box@mail.ru"

#define EQU_NO           0
#define EQU_YES          1

#define DATA            1
#define OI              2
#define NONCOMM_LONG    3
#define NONCOMM_SHORT   4
#define SPREADING       5
#define OPERATORS_LONG  6
#define OPERATORS_SHORT 7
#define ALL_LONG        8
#define ALL_SHORT       9
#define NONREP_LONG     10
#define NONREP_SHORT    11

extern string s_list="AGREGATION.ini";
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int start()
  {
   int      h_list;                    // File list descriptor
                                       // (it contain a file list)
                                       // string   s_list;                    // File name

   int      h_enumeration;             // Descriptor of the enumeration file
   string   s_enumeration;             // Filename of the enumeraton file

   int      h_rezult;                  // Description of the output file
   string   s_rezult;                  // Filename of the output file

   int      h_temp;                    // Temporary descriptor (one for all)
                                       // used for the file counting
   string   s_temp;                    // Temporary string (one for all), 
                                       // used for the file counting

   int      h_file[];                  // Array of descriptors for the output files 
   string   s_file[];                  // Array with the names for the output files

   datetime data[],data_all;
   int      oi[],oi_all,
   noncomm_long[],noncomm_long_all,
   noncomm_short[],noncomm_short_all,
   spreading[],spreading_all,
   operators_long[],operators_long_all,
   operators_short[],operators_short_all,
   all_long[],all_long_all,
   all_short[],all_short_all,
   nonrep_long[],nonrep_long_all,
   nonrep_short[],nonrep_short_all;

   int      str;                       // Count of the result files
   int      n;                         // The current index of the result files
   int      column;                    // Column number
   int      frnz_str[];                // Frozen descriptiors
   double   count;                     // Count the string count for the result file
   string   tmp;                       // A text string for the result file

   h_list=FileOpen(s_list,FILE_READ|FILE_CSV);                    // Открываем список файлов
   if(h_list==-1){Print("File list not found");return(0);}
   while(FileIsEnding(h_list)==false)
     {                            // Reading it string by string
      s_enumeration=FileReadString(h_list);                       // Each string has a filename
      Print("---------------<<",s_enumeration,">>---------------");
      h_enumeration=FileOpen(s_enumeration,FILE_READ|FILE_CSV);   // Try to open enumeration file list
      if(h_enumeration==-1)
        {
         Print("The enumeration file not found ",s_enumeration);
         continue;                                                // If it does not exist, skip it
        }

      s_rezult=StringConcatenate(ConvertName(s_enumeration),".csv");
      h_rezult=FileOpen(s_rezult,FILE_WRITE|FILE_CSV);
      if(h_rezult==-1)
        {
         Print("Can't create a result file: ",s_rezult,"; ",GetLastError());
         continue;
        }
      while(FileIsEnding(h_enumeration)==false)
        {
         s_temp=FileReadString(h_enumeration);                  // Reading string by string enumeration file
                                                                // each string is the name of the final file
         h_temp=FileOpen(s_temp,FILE_READ|FILE_CSV);            // Try to open the result file
         if(h_temp==-1)continue;        // If result file does not exists, skip it
         str++;                                                 // Overwise we increasing by 1 the count of the files processed.
                                                                // Print("--> ",s_temp);
         while(FileIsEnding(h_temp)==false)
           {
            tmp=FileReadString(h_temp);
            if(tmp!="")count++;
           }
         Print("--> ",s_temp," ",count/12);
         count=0;
         FileClose(h_temp);                                    // Closing result file
        }//End While (counting the files with enumerations)
      FileSeek(h_enumeration,0,SEEK_SET);

      ArrayResize(h_file,str);
      ArrayResize(s_file,str);
      ArrayResize(data,str);
      ArrayResize(oi,str);
      ArrayResize(noncomm_long,str);
      ArrayResize(noncomm_short,str);
      ArrayResize(spreading,str);
      ArrayResize(operators_long,str);
      ArrayResize(operators_short,str);
      ArrayResize(all_long,str);
      ArrayResize(all_short,str);
      ArrayResize(nonrep_long,str);
      ArrayResize(nonrep_short,str);
      ArrayResize(frnz_str,str);
      while(FileIsEnding(h_enumeration)==false)
        {
         s_file[n]=FileReadString(h_enumeration);              // Reading enumeration file string by string
                                                               // each string is the name of the result file
                                                               // Print(str,"; ",s_file[n]);
         h_file[n]=FileOpen(s_file[n],FILE_READ|FILE_CSV);     // Try to open the final file
         if(h_file[n]==-1){Print("File not found");continue;}  // It it does not exist, skip it
         n++;
        }// End While( open enumerations file)   
      //for(n=0;n<str;n++){
      //   Print(n,"; ",s_file[n]);
      //}
      // At present time we have the list of the result files(s_file[]) 
      // and their descriptors (h_file[]) which are
      // in the single enumerations file. Now lets combine these files to a single file:
      while(FileIsEnding(h_file[0])==false)
        {
                                 // As a signal of the end of the file there is a end of the first file
                                 // (we assume theat the files are the same)

         for(int i=0;i<str;i++)
           {                     // Reading column by column for each of the file included in the enumerations file.
            if(frnz_str[i]==1)continue;
            tmp=FileReadString(h_file[i]);
            switch(column)
              {
               case DATA:            data[i]=StrToTime(tmp);
               case OI:              oi[i]=StrToInteger(tmp);
               case NONCOMM_LONG:    noncomm_long[i]=StrToInteger(tmp);
               case NONCOMM_SHORT:   noncomm_short[i]=StrToInteger(tmp);
               case SPREADING:       spreading[i]=StrToInteger(tmp);
               case OPERATORS_LONG:  operators_long[i]=StrToInteger(tmp);
               case OPERATORS_SHORT: operators_short[i]=StrToInteger(tmp);
               case ALL_LONG:        all_long[i]=StrToInteger(tmp);
               case ALL_SHORT:       all_short[i]=StrToInteger(tmp);
               case NONREP_LONG:     nonrep_long[i]=StrToInteger(tmp);
               case NONREP_SHORT:    nonrep_short[i]=StrToInteger(tmp);
              }
           }// End For()
         //Print(h_file[0], ";  ",s_file[0]);
         column++;
         if(FileIsLineEnding(h_file[0])==true || FileIsEnding(h_file[0])==true)
           {   // If string has finished - compare the dates for all of the files, is they are equal, combine them
            column=0;
            if(tmp=="")continue;
            for(int k=0;k<str;k++)
              {
               if(data[0]>data[k])
                  frnz_str[k]=1;
               if(data[0]<data[k])
                  frnz_str[0]=1;
               if(data[0]==data[k])frnz_str[k]=0;
               if(data[0]!=data[k])
                 {
                  Print("Time Gap was found: ",TimeToStr(data[0],TIME_DATE),"; ",TimeToStr(data[k],TIME_DATE));
                  continue;
                 }
              }

            for(k=0;k<str;k++)
              {
               data_all=data[0];
               oi_all+=oi[k];
               noncomm_long_all+=noncomm_long[k];
               noncomm_short_all+=noncomm_short[k];
               spreading_all+=spreading[k];
               operators_long_all+=operators_long[k];
               operators_short_all+=operators_short[k];
               all_long_all+=all_long[k];
               all_short_all+=all_short[k];
               nonrep_long_all+=nonrep_long[k];
               nonrep_short_all+=nonrep_short[k];
              }
            FileWrite(h_rezult,ConvertName(s_enumeration),
                      TimeToStr(data_all,TIME_DATE),
                      oi_all,
                      noncomm_long_all,
                      noncomm_short_all,
                      spreading_all,
                      operators_long_all,
                      operators_short_all,
                      all_long_all,
                      all_short_all,
                      nonrep_long_all,
                      nonrep_short_all);
            //Print(TimeToStr(data_all,TIME_DATE),";  ",oi_all);
            data_all=0;
            oi_all=0;
            noncomm_long_all=0;
            noncomm_short_all=0;
            spreading_all=0;
            operators_long_all=0;
            operators_short_all=0;
            all_long_all=0;
            all_short_all=0;
            nonrep_long_all=0;
            nonrep_short_all=0;
           }

        }// End While(summation)

      // Zero results
      FileClose(h_enumeration);
      FileClose(h_rezult);
/*for(int j=0;j<str;j++){
         FileClose(h_file[j]);
         noncomm_long[j]=0;
         noncomm_short[j]=0;
         spreading[j]=0;
         operators_long[j]=0;
         operators_short[j]=0;
         all_long[j]=0;
         all_short[j]=0;
         nonrep_long[j]=0;
         nonrep_short[j]=0;
      }*/

      n=0;str=0;
     } //End While( file enumeration list)

  }// End Programm   
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
string ConvertName(string str)
  {
   string str_cnv;
   int strlen=StringLen(str);
   int char;
   for(int i=0;i<strlen-4;i++)
     {
      char=StringGetChar(str,i);
      str_cnv=StringConcatenate(str_cnv,CharToStr(char));
     }
   return(str_cnv);
  }
//+------------------------------------------------------------------+

日付でレポートを結合するプログラム Meta COT スクリプト結合は同様の方法を用いますが、アルゴリズムはもっと簡単です。

#property copyright "Copyright © 2009, C-4, All Rights Reserved."
#property link      "vs-box@mail.ru"

extern string FilesList="CONCATENATE.ini";
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int start()
  {
   int    h_list,h_file,h_cont,h_rezult;   // File descriptors
   int    column;
   string s_list,s_file,s_cont,s_rezult,   // Strings with file names
   string_cont,string_cont_f;
   h_list=FileOpen(FilesList,FILE_READ|FILE_CSV);      // Open the file list
   if(h_list==-1){Print("File list ("+FilesList+") not found");return(0);}
   while(FileIsEnding(h_list)==false)
     {                  // Read it string by string
      s_list=FileReadString(h_list);                      // Each string is a filename
      Print(s_list);
      h_file=FileOpen(s_list,FILE_READ|FILE_CSV);         // Try open this file
      if(h_list==-1){Print("File "+s_list+" not found");continue;}  // If it does not exists
                                                                    // we skip it
                                                                    // s_rezult="COT - CONT - "+s_list;
      s_rezult=get_rezultname(s_list);
      h_rezult=FileOpen(s_rezult,FILE_WRITE|FILE_READ|FILE_CSV);
      while(FileIsEnding(h_file)==false)
        {
         s_file=FileReadString(h_file);
         //Print(s_file);
         h_cont=FileOpen(s_file,FILE_READ|FILE_CSV,';');
         if(h_cont==-1){Print("Data file "+s_file+" not found");continue;}
         else Print("Loading data file "+s_file+"...");

         while(FileIsEnding(h_cont)==false)
           {
            string_cont=FileReadString(h_cont);
            if(string_cont=="")continue;
            if(FileIsLineEnding(h_cont)==true)
              {
               string_cont_f=string_cont_f+";"+string_cont;
               FileWrite(h_rezult,string_cont_f);
               string_cont_f="";
               column=0;
              }
            else
              {
               //if(string_cont=="")continue;
               if(column==0)string_cont_f=string_cont_f+string_cont;
               else string_cont_f=string_cont_f+";"+string_cont;
               column++;
              }
           }
         FileClose(h_cont);
        }
      FileClose(h_file);
      FileClose(h_rezult);
     }
   return(0);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
string get_rezultname(string fname)
  {
   int strlen=StringLen(fname)-1;
   int char;
   string str;
   for(int i=strlen;i>0;i--)
     {
      char=StringGetChar(fname,i);
      if(char=='.')
        {
         for(int b=0;b<i;b++)
            str=str+CharToStr(StringGetChar(fname,b));
         str=str+".csv";
         return(str);
        }
     }
   return("COT - CONT - "+fname);
  }
//+------------------------------------------------------------------+

4. 理論から実践へ!

4.11分待てば、商品トレーダーは仕事にとりかかる準備が整います。

よって、すべてを一般化します。先物市場には、参加者の主要グループが3つあります。ヘッジャー、大規模商品ファンド、群衆です。第1、第2グループが最も多く資産を持っています。群衆がコントロールするのは市場のほんの一部で、通常は10%にも満たないものです。よって彼らの活動は市場価格に影響することはありません。残りの2グループは数は少ないですが、より力を持ち、需給法則により相互作用を決定します。

非商業トレーダーとオペレータは本質的に逆です。1グループの行動はほとんどもう1グループの鏡に映る像です。レポートの最初の可能な適用は需給法則を基に2グループ間のバランスを観察することです。

へジャーは他のだれよりも市場情報に秀でた参加者です。商品生産にもっとも近いところにいるため、他の参加者よりも早く隠れた市場トレンドを知るのです。この場合、彼らはつねに他の市場参加者に関して内側にいることとなります。この隠れた情報により、ヘッジレベルを調整します。それは CFTC レポートに現れています。2番目に可能な適用はオペレータのポジションにおける迅速な変化を観察することです。

群衆はトレーダーカテゴリの中でもっとも情報に乏しいとみなされます。たいていそれは、群衆の行動がとんでもない噂、群衆心理、欲と恐れで引き起こされることを意味します群衆のネットポジションが急激に変化するのは、多くの場合そういった要因の下で群衆のムードが大きく変わったことを表しています。よって状況が逆に進展するのに準備した方がよいのです。3番目に可能な適用は、迅速な群衆のポジション変化を観察することです。

CFTC レポート自体は市場の特定のエントリやエグジットを指し示すことはできません。この特性は基本的なインディケータのすべてに共通しています。エントリとエグジットのポイントをより正確に判断するには、テクニカル分析の効果的な方法を使用する必要があります。


以下は CFTC 情報を効果的に利用するためのトレーディングシステムを持つ特性の一部です。

1. 収益性がある、または CFTC フィルターを使用しなくても少なくともニュートラルである

2. システムはパラメータを持つべきではない。それを最適化することによってトレーディングシステムの動作、最終利益を変えてしまう。システムの主要な関数はトレードシグナルを確認する必要があります。補助ユニットの最適化は戦略作成にとっては優先事項ではありません。

3. システムは完全に可逆的である。売りシグナルは買いシグナルの鏡でなければなりません。

4. テクニックは現行のローカルトレンドに対してカウンタートレンドである。長いブルトレンド、あるいは少なくとも主要な動きの強い反転で、売りに対する CFTC シグナルが出現します。買いシグナルも潜在的なトレンドの逆となります。

5. テクニックはトレンド反転をとらえることを保証する。転換点はすべて、システムによって市場へのエントリポイントと考えられます。これはもっとも難解ですが、同時に、トレーディングシステムにとって最も重要な条件です。CFTC シグナルが出現するのはひじょうに稀です。インディケータの一部が多くて年に1~2回シグナルを生成するのみです。テクニックがこういう瞬間に市場への参入シグナルを出さなければ、CFTC レポートの利用は意味のないものとなります。

6. CFTC レポート情報を利用する場合、主要な利益は数か月までの長期トレードでたった数件のディールから得るものです。したがって、トレーディング戦略は長期間ポジションがただ変化することを許容しなければなりません。

7. システムは特定市場の特性を利用しない。CFTC レポートは数多くの市場に対して有効です。そのため、システムも同様にレポート作成対象の全市場に対して適用されなければなりません。

この技術はフィルターとしての使用がもっとも有望なものと考えられます。この場合、ディール数や最大ドローダウンが急速に減少し、一方で勝利とその結果としての利益が増加します。

ここで着目すべきもっとも重要なシグナルを考察します。そのようなシグナルは2つあります。建玉レベルと、カテゴリーの一つのネットポジションです。それをオペレータと仮定します。レポート情報すべてを、3年指数で表される次の2つのパラメータにまとめます。

これは主観性を排除し、市場分析をはるかに簡単にします。よって、買いに対して好ましい状況はオペレータの売りが少ない冷えた市場です。冷えた市場とは、現時点での建玉レベルがひじょうにい低く、そのため成長の可能性があることを意味します。また売りに対して逆の状況を探します。市場が十分に温まり( OIのレベルがひじょうに高い)、そこではオペレータが極端に高い売りレベルを示しているのです。

こういった瞬間を特定するため日本円のインディケータに目を転じます。

図4-1 日本円先物についてのオペレータの建玉と指数

ブルーの線は売りに適した瞬間、オレンジの線は買いに適した瞬間を表示しています。建玉が十分に大きく(上のグリーンの線)、オペレータがベア(下の赤色の線)の場合、それは円を売るのに有利な条件です。買いについても同様です。建玉が相対的に小さく(下のグリーンの線)。オペレータがブル(上の赤色の線)であれば、それは円を買うのに有利な条件です。このデータは初期の市場分析に利用できます。価格レベルが必要ないのです。投機に有利なタイミングが見つかった後にだけ、テクニカル分析を用いて市場参入により適したポイントを見つけることができるのです。以下のチャートは同様のインディケータを表示していますが、市場価格が入っています。

図4-2 円についての価格チャートでのオペレータの指数と建玉

ごらんのように、売りや買いのシグナルがかならずしも利益より大きくなっているとは限りません。多くは深刻な損失にさえつながっています。ただし、どんなシステムにもハードストップが使われており、これは例外ではありません。

20% や 80% のレベルに到達していない値をいくつか持つチャートのシグナルがあります。こういったレベルは非の打ちどころがありません。市場はすべて独自の最適レベルを有するものです。インディケータもしかりです。市場すべてに対して最適であるユニバーサルレベル値など存在しません。

市場がどのようにトレーダーの取引記録であるのかという視点で詳細を検討します。定期報告を持つ市場はひじょうに多く存在することを留意すべきです。一定期間(月または年)に表示され、その後永遠に消えるレポートを持つ市場がいくつかあります。トレードが長期間行われていない市場がいくつかありますが、情報は履歴データに存在します。この中には、明確にまた定期的に出されるレポートを持つ市場が60特定されます。以下はもっとも慣性されたレポート(拡張子 CSV なしで指定されるデータファイル名)を持つ市場です。

インスツルメント

CSV データファイル

商品
1LEAN HOGSCOT - LEAN HOGS - CHICAGO MERCANTILE EXCHANGE
2FEEDER CATTLECOT - FEEDER CATTLE - CHICAGO MERCANTILE EXCHANGE
3LIVE CATTLECOT - LIVE CATTLE - CHICAGO MERCANTILE EXCHANGE
4MILK CONCATENATECOT - MILK CONCATENATE
5WHEAT - CHICAGO BOARD OF TRADECOT - WHEAT - CHICAGO BOARD OF TRADE
6WHEAT - KANSAS CITY BOARD OF TRADECOT - WHEAT - KANSAS CITY BOARD OF TRADE
7WHEAT - MINNEAPOLIS GRAIN EXCHANGECOT - WHEAT - MINNEAPOLIS GRAIN EXCHANGE
8OATS - CHICAGO BOARD OF TRADECOT - OATS - CHICAGO BOARD OF TRADE
9ROUGH RICECOT - ROUGH RICE - CHICAGO BOARD OF TRADE
10砂糖COT - SUGAR CONCATENATE
11コーヒーCOT - COFFEE CONCATENATE
12カカオCOT - COCOA CONCATENATE
13COTTON №2COT - COTTON 2 CONCATENATE
14SOYBEAN MEALCOT - SOYBEAN MEAL - CHICAGO BOARD OF TRADE
15MINI SOYBEANSCOT - MINI SOYBEANS - CHICAGO BOARD OF TRADE
16SOYBEAN OILCOT - SOYBEAN OIL - CHICAGO BOARD OF TRADE
17大豆COT - SOYBEANS - CHICAGO BOARD OF TRADE
18BUTTER (CASH SETTLED)COT - BUTTER (CASH SETTLED) - CHICAGO MERCANTILE EXCHANGE
19FRZN CONCENTRATED ORANGE JUICECOT - FRZN CONCENTRATED ORANGE JUICE CONCATENATE
20LUMBERCOT - LUMBER CONCATENATE
金属
21COPPER-GRADE #1COT - COPPER-GRADE #1 - COMMODITY EXCHANGE INC.
22COT - SILVER - COMMODITY EXCHANGE INC.
23COT - GOLD - COMMODITY EXCHANGE INC.
24プラチナCOT - PLATINUM - NEW YORK MERCANTILE EXCHANGE
25パラジウムCOT - PALLADIUM - NEW YORK MERCANTILE EXCHANGE
通貨
26AUSTRALIAN DOLLARCOT - AUSTRALIAN DOLLAR CONCATENATE
27CANADIAN DOLLARCOT - CANADIAN DOLLAR CONCATENATE
28BRITISH POUND STERLINGCOT - BRITISH POUND STERLING CONCATENATE
29EURO FXCOT - EURO FX CONCATENATE
30APANESE YENCOT - JAPANESE YEN CONCATENETE
31MEXICAN PESOCOT - MEXICAN PESO CONCATENATE
32 NEW ZEALAND DOLLARCOT - NEW ZEALAND DOLLAR - CHICAGO MERCANTILE EXCHANGE
33SWISS FRANC CONCATENATECOT - SWISS FRANC CONCATENATE
34 RUSSIAN RUBLECOT - RUSSIAN RUBLE - CHICAGO MERCANTILE EXCHANGE
35U.S. DOLLAR INDEXCOT - U.S. DOLLAR CONCATENATE
指標
36DOW JONES INDUSTRIALCOT - DOW JONES INDUSTRIAL AVERAGE - CHICAGO BOARD OF TRADE
37DOW JONES INDUSTRIAL x5$COT - DOW JONES INDUSTRIAL AVG- x $5 - CHICAGO BOARD OF TRADE
38E-MINI S&P400COT - E-MINI S&P 400 STOCK INDEX - CHICAGO MERCANTILE EXCHANGE
39E-MINI S&P500COT - E-MINI S&P500 CONCATENATE
40S&P500 STOCK INDEXCOT - S&P500 STOCK INDEX CONCATENATE
41S&P400 MIDCAP STOCK INDEXCOT - S&P400 MIDCAP STOCK INDEX CONCATENATE
42NASDAQ-100COT - NASDAQ-100 STOCK INDEX CONCATENATE
43NASDAQ-100 MINICOT - NASDAQ-100 INDEX (MINI) CONCATENATE
44NIKKEY INDEXCOT - NIKKEI STOCK AVERAGE CONCATENATE
45RUSSELL-2000 E-MINICOT - RUSSELL 2000 CONCATENATE
債権
46INTEREST RATE SWAPS 10YRCOT - INTEREST RATE SWAPS 10YR CONCATENATE
47INTEREST RATE SWAPS 5YRCOT - INTEREST RATE SWAPS 5YR CONCATENATE
48U.S. TREASURY BONDSCOT - U.S. TREASURY BONDS - CHICAGO BOARD OF TRADE
4910-YEAR U.S. TREASURY NOTESCOT - 10-YEAR U.S. TREASURY NOTES - CHICAGO BOARD OF TRADE
505-YEAR U.S. TREASURY NOTESCOT - 5-YEAR U.S. TREASURY NOTES - CHICAGO BOARD OF TRADE
512-YEAR U.S. TREASURY NOTESCOT - 2-YEAR U.S. TREASURY NOTES - CHICAGO BOARD OF TRADE
521-MONTH LIBOR RATECOT - 1-MONTH LIBOR RATE CONCATENATE
5330-DAY FEDERAL FUNDSCOT - 30-DAY FEDERAL FUNDS - CHICAGO BOARD OF TRADE
543-MONTH EUROYENCOT - 3-MONTH EUROYEN TIBOR CONCATENATE
553-MONTH EURODOLLARSCOT - 3-MONTH EURODOLLARS CONCATENATE
エネルギー
56CRUDE OIL LIGHT SWEETCOT - CRUDE OIL LIGHT SWEET - NEW YORK MERCANTILE EXCHANGE
57NATURAL GASCOT - NATURAL GAS - NEW YORK MERCANTILE EXCHANGE
58NO. 2 HEATING OIL N.Y. HARBORCOT - NO. 2 HEATING OIL N.Y. HARBOR - NEW YORK MERCANTILE EXCHANGE
変動指数
59ISO NEW ENGLAND LMP SWAPCOT - ISO NEW ENGLAND LMP SWAP - NEW YORK MERCANTILE EXCHANGE

テーブル 4-3 長期間有効な定期レポートを持つインスツルメント リスト

現時点で、委員会が農産物、通貨、金融、その他市場の広い範囲でデータを収集しているのがわかります。テーブルに記載されているファイルはすべてスクリプト Meta COT スクリプト構築 および Meta COT スクリプト結合実行後にに受け取られます。

4.2研究ロボットの作成


CFTC レポート効果研究は、マルチインスツルメンタル最適化同様、テクニカル分析分野における現実の効果的的開発を必要とするむつかしいタスクです。多く経験あるトレーダーがそれを持ち、それについて彼ら独自のノウハウが公開されています。テクニカル分析は本稿の範囲を超える広い分野です。よってここでは基本的でありながらよく知られるアクセス可能なテクニカル分析と市場分析方法に限定します。

トレーダーのレポート分析を基に、市場参入を判断するシンプルな研究ロボットを作成します。みなさんが MQL4 の開発者であれば、テクニカル分析を基にしたトレーディング戦略の追加フィルターとして CFTC データを簡単に利用することができます。することができます。開発者でくてもこの技術に興味があれば、そのようなロボットを利用できる可能性は計り知れません。

戦略オプティマイザを使用すると、インディケータ選択やその最適な平均化期間選択が可能となります。実践により、異なる市場に対して、もっとも収益性があり精度の高いインディケータは、トレーダーの異なるグルーウの動向をに基づくインディケータであることが示されています。おそらく、非報告トレーダーのトータルネットポジションを利用するのた効率的な市場もあれば、オペレータの活動を基にするのがもっとも効率的な市場もあるでしょう。

始めは、市場参入のより正確なタイミングを見つけるためのテクニカル分析にとりかかります。Larry Williams はその著書で移動平均に基づく従来のテクニカル分析を提案しています。われわれもそれを行い、作業に 2 とおりの単純移動平均を取り入れます。一つは長期トレンドに基づくもの、もう一つは短期トレンドに基づくものです。長期移動平均は週次バーに、短期移動平均は日次バーに適用します。低速平均期間はインディケータ計算期間に等しく、高速平均期間は5日とします。

低速平均現在値が2週間前のその値より大きければ、長期トレンドは上向き、小さければ下向きです。同様に5期間移動平均を分析します。現在値が2日前の値より大きければ、短期のブルトレンドを、小さければ短期のベアトレンドを予想します。ひとたび短期トレンドが長期トレンドと一致すればその方向を換えます。COT インディケータの一つをフィルターとして使用します。インディケータが現時点での好ましい値範囲に入ればポジションはオープンされます。

図 4-2 を見てください。

図4-4 ポジションオープンのテクニカル分析シグナル

図4-4 では、EURUSD の日次チャートが表示されています。左上角に表示されているのは同時期での EURUSD の週次チャートのエキスパートです。長期単純平均(ブルーの線)はMeta COT のオペレータ指数インディケータと同じ期間になっています。この場合は26週です。短期平均(赤色の線)はつねに5期間です。2006年10月15日に赤(Ma1)の平均値が2日前(MA2)より高く、また同時に長期平均値は2週間前より高くなっているのが解ります。トレンドは同様です。インディケータ同レベルに対して、オペレータ指数は 100%、買いの好機です(または厳密に言えば、この条件は前日に一致していますが、この組み合わせは図解に使用しました)。

ロボットはストップロスおよびテイクプロフィット値(唯一のエグジットポイントです)を用いて操作をします。レベルサイズは機関インディケータにより、長い期間はストップロスとテイクプロフィットの高い値に対応しています。インディケータの26周期ごとに100ポイントの損失と300ポイントの利益があります。たとえば、そのような場合、156週ごとの平均化について、ストップロス値を 600ポイント、テイクプロフィットを1,800ポイント(単純な推定です)とします。指定されたテイクプロフィットとストップロスレベルはポジションから脱する唯一の方法で、トレーディングシステムが完全に完了したと思います。

ポジションサイズは固定されており、商品契約の0.1に等しくなっています。

原始的ということでなくても、システムは完璧ではありません。一般的に、Meta COT フィルターで使用されているなら、台無しにするにはそれは良い方法です。

ここからロボットのソースコードにとりかかります。動作はインディケータとひじょうによく似ています。ロボットは注文の出し方を知っているそのインディケータのようなものではありません。初期化中、ロボットは現行チャート(ライブラリ cotlib.mq4)用にデータをロードします。そしてそれからインディケータすべてに対して値を計算し、その後そのうちの一つの値を取得します。選択されたインディケータすべてには indicator_type 整数によって決まります。それを 17 に設定すれば、それはオペレータに対して WILLCO インディケータを使用することを意味します。それが22であれば、それは非報告トレーダーの指数となることを意味します。

インディケータ番号を見つけることは簡単です。それらは cotlib.mq4 ライブラリの始めにリストアップされています。平均化期間を定義するには、インディケータの期間値を設定する必要があります。インディケータとその期間の選択は「ストラテジー オプティマイザ」によって手配されます。どちらの値も最適化する値として印がつけられます。期間値は26から始まり、そのステップは26、最終値は156です。indicator_type 値は16から開始され、ステップは1、最終値は26です。それがインディケータすべてと異なる平均化期間を試す方法です。


図4-4 エキスパートの入力パラメータウィンドウ

インディケータの一部は履歴バックテストに含まれていません。市場によって値が選択されるインディケータ同様、オペレータのネットポジションや絶対ポジションなど、このインディケータは明確なレベルを持ちません。たとえば建玉で除算されるオペレータのロングポジションです。いずれの場合にも、インディケータはその効果を推定するには十分すぎまず。考察する戦略は実際の売買ロボットを構築するのに使うには、完璧からほど遠いものです。しかし、例のアドバイザーはプロジェクトから提供される大量の情報をナビゲートし、提供される方法からもっとも効果のあるものを見つけるのに役立ちます。図4-5 にはインディケータを用いた検証の最良結果が表示されています。

結果は以下のテーブルにリスト化され、かなり近似ですが、検証の主要な目的は、利益を最大化することというよりは、もっとも安定したインディケータを見つけることです。最良結果はもっとも収益性が高いことを意味するものではないことにご注意ください。最良結果はディール数(ディール数が多いほど結果は良好)、最大ドローダウン収益性(低いほど良好)、それから最終利益によって決まります。

ご自分のコンピュータでバックテストを行うことができます。テーブルには以下のインスツルメントに対する履歴バックテストが入っています。

インスツルメント

インディケータ

計算期間

トータルディール数

プロフィットファクター

数学期待値

ドローダウン %

利益 $

ユーロ

Index Operators

26

77

1.79

62.31

12.57

4798

英ポンド

WILLCO Noncomm

26

140

1.44

18.64

7.12

2600

日本円

Index Nonrep

52

35

1.37

63.29

14.85

2200

スイスフラン

Movement Index Operators

26

21

3.96

159.71

4.63

3354

AUSTRALIAN DOLLAR

Index Nonrep

26

59

1.98

57.50

5.67

3392

ニュージーランドドル

Index Noncomm

26

20

1.97

59.00

4.13

1180

米ドル指数

Movement Nonrep

26

144

1.20

1.50

1.98

216

Index Nonrep

26

81

1.84

52.09

5.70

4219

WILLCO Operators

26

165

1.85

26.58

4.76

4385

プラチナ

Index Nonrep

26

233

1.77

24.54

6.73

5717

パラジウム

Index Noncomm

26

142

1.23

8.15

10.61

1158

砂糖

WILLCO Operators

26

18

1.89

61.22

6.67

1102

カカオ

Index Operators

26

29

1.96

56.59

6.08

1641

コーヒー

Index Operators

52

113

1.38

19.58

7.59

2212

大麦

Index Operators

26

15

2.24

83.50

8.25

1252

小麦

Index OI

26

53

1.66

53.25

8.91

2822

大豆

Index Noncomm

26

66

2.88

118.72

6.46

7965

オレンジ果汁

Index Operators

26

29

2.75

68.83

2.73

1996

LIGHT SWEET OIL

Index Operators

26

194

1.23

16.53

12.68

3206

E-MINI S&P

Movement Operators

26

32

2.01

75.21

6.66

2406

テーブル 4-5 固定ロット0.1でのCOT フィルター履歴バックテスト最良結果


インディケータの検証結果はひじょうに興味深いものです。まず、 Index Nonrep および WILLCO インディケータに対して、明らかに収益性ゾーンへ移動しています。動向指数インディケータの動きはもっと不明瞭です。インスツルメントの一部については、最大利益が達成され(通常オペレータに対して計算されたインディケータ)、同一インディケータの一定の値に対しては大きな損失を出しています。非商業トレーダーに対して動向指数を使用すると全商品について最大損失となっています(図46 のポイント No.43)おそらくこの現象をもっとよく研究すればそのシグナルを利用できるようになることでしょう。

最適化チャートは以下のように表示されます。

図4-6 インディケータ検証の効果の一般的スキームおよびそのパラメータ

赤色の線は収益性ゼロレベルに対応しています。43 の実行から利益は不安定になっています。

一般的に、最大利益はインディケータに対して平均化に長い期間(104~156週)で達成されています。しかし、ディール数が少ないため、それらはレポートに入っていません。長い平均化期間のインディケータはひじょうに正確で、それを使用することはひじょうに効果的であります。とくに同時に南寿という市場での使用で顕著です。オペレータと非商業トレーダーが一部の市場で鏡に映った像のように似通っているにもかかわらず、オペレータのポジションを能一方のポジション、非商業トレーダーのポジションを使用する方が好ましいのです。群衆の行動もまた興味深いものです。

金市場でのオペレータに従うよりも、群衆とは反対の行動をするとより利益が出ることは注目に値します。

WILLCO インディケータには建玉が入っており、それがひじょうに効果的であるにもかかわらず、建玉自体はあまり効果的ではありません。せいぜいそれを使用することで利益は減ります。IO の適用は追加シグナルであって、メインのソースではないように見受けられます。

一般的に、インディケータは効果的であることが証明されました。そして明らかにそれらはより実質的な利益をもたらし、良い売買システムへの統合の対象となります。

EURO の一般的な最適化チャートは以下に示します。

見てのとおり、正のゾーンへのイベント移動があります(上図赤色の線)。チャートが必ずしもそのような効果的置換を持つわけではなく、数多くの技術的理由により適切に検証を行えないものも多いものです。

ここからフィルター自体の効果を比較します。このため、COT フィルターあり、なしで同一価格にて検証を行います。商品として EURO の先物を取り上げます。

COT フィルターなしのトレーディングシステムの結果は図4-8 に表示しています。

図4-8 COT フィルタなしのトレード結果

ごらんのように、最終利益は 1,897 米ドルで、これはロットサイズ0.1ボリュームでのポイント数とほぼ同じです。同じ時期の最大ドローダウンは30%で、これは明らかに大きなものです。図 4-9を見ます。

同戦略ですが、すでにオペレータの26週指数の値でフィルターにかけられています。

図4-9 COT フィルター使用のトレード結果


図にあるように、ディール数が激しく落ちて、勝利の数学的期待値は増えています。最終利益は初回の検証より大きくありませんが、最大ドローダウンレベルに大きな変化が起こっています。前回よりずっと低い8.6%です。明らかに、COT フィルターは十分効果を発揮し、戦略改善になっています。

CFTC 情報利用の最大効率を判断するためには、詳しい調査が必要ですが、本稿でそれを行うには無理があります。この項での主なタスクは、CFTC データの利用が効果的であることを示すために、シンプルな例によって基本を説明することです。

実取引でこの方法を行うかどうかはみなさん次第です。

4.3継続のあるエピローグ

この話題に関してまだなにも質問がないなら、それは本稿を注意深く読んでいないか、提供されているコンセプトに興味がない、ということです。現時点で数多くの質問をお持ちであることを願っています。その一部に対する解答が以下かにあるかもしれません。実際、以下は概念を用いて多くの問題を解決するのに役立つショート FAQ です。


1. 本稿に述べられているエキスパートのポジションオープンの理論を実践に適用するべきなのでしょうか?

もちろんそんなことはありません。市場参入の正確なポイントを判断するためにより適した技術は簡単に見つけることができます。おそらく、すでにテクニカル分析の分野でご自身の経験がおありでしょう。そのトレーディング戦略に CFTC フィルターを使ってみてください。Meta COT 研究ロボットにご自分のポジション管理技術を追加することは可能です。

2. グループポジションについては、観察しフォローするのがよいのでしょうか?

それに対する明確な解答はありません。Meta COT Expert によって、特定市場でどのグループがもっとも効果的か見つけ出すことはできます。各市場に対してトレーダーグループ3つをすべて試してください。そうしてより正確な予測を出したグループを選択するのです。

3. どのインディケータが利用により適しているのでしょうか?

それに対する明確な解答はありません。事前検証により、WILLCO または動向指数が非常によい選択であることが示されています。まず市場によく相関していること、そしてWILLCO の使用とよく組み合わされていること、そういったインディケータを選択しなければなりません。いずれの場合でも、研究ロボットがトレーディングシステムのプログラム理論により提供される最適なインディケータを判断するはずです。

4. どの平均化期間を選択するのが良いでしょうか?

それに対する明確な解答はありません。たぶん短期トレーダーにとってのベストな選択肢は26期間平均または動向指数のインディケータです。ご自分のポジションを維持したいと思うトレーダーにとっては、もっと長い計算期間のインディケータがより適しています。26期間計算とは大きく異なります。長い期間はそれらの間では違いません。また、26週より短い計算期間は使わないでください。半年間のインディケータでも変動が激しく過度の乱流となります。最適な期間は市場ごとに異なります。また選択した TS とよく相関している必要もあります。最適な計算期間は研究ロボットが力ずくで簡単に見つけ出します。

5. インディケータのどのレベルが重大だとみなされるのでしょうか?

Larry Williams は著書で異なるレベルを持つチャートを表示しています。グラフの中には 25~75%のレベルのものもあれば、20 ~80%もあります。たぶん市場によって、効果的なレベルが広かったり、狭かったりするのでしょう。いずれにしても、効率的なレベルは 0~0% と 70~100%です。最適レベルを判断するのに研究ロボットを使用することができます。低い側のレベルと高い側のレベルの値で変数を2つ作成します。これら返須を最適化に設定します。最適な結果を見つけるため、その値を変えてみてください。

6. 一部の市場でオペレータ(大規模ファンド、群衆)が異常な行動をする理由は何でしょうか?

トレーダーグループの異常な挙動に対する理由として可能性があるのは、商品市場での取引によって彼らが解決するグループ内の構成と問題かもしれません。たとえば、金市場におけるヘッジャーの構成とタスクは、外為のタスクとは大きく異なります。いずれにしても、もっとも効果的なトレーダーグループを使用します(質問2を参照ください)。

7. Meta COT 集積によって複数商品を1つにまとめたいのですが、ユニオンが正しいか確信がありません。商品をまとめたかどうか正確に確認する方法は?

まず、結果できたファイルをインディケータいくつかにダウンロードし、市場反転ポイントの値を視覚的に判断する必要があります。一般原則は守られるべきです。オペレータは市場の下落前にもっとも高いレベルの販売を行った。その他は逆にこのときに買いをしている可能性があります。市場の底では状況は鏡となっています。視覚での確認が正しい値を示したら、その値は研究ロボットで検証可能です。結果が正で、標準レポートを用いて取得した結果を超えていれば、結合は妥当であると考えられ、トレードに入れることができます。

8. レポートは一部の市場で役に立ちません。インディケータがすべてネガティブな結果を出します。

そのような市場では CFTC フィルターなしでトレーディングシステムを使ってみます。結果を比較します。フィルターなしのシステムがフィルターありより悪い結果であれば、たぶんシステム自体に問題があります。その場合は、ご自分のトレーディングシステムを少なくともニュートラルまで改善し、それから CFTC フィルターを追加して再び検証を行います。試してみて、検証し、最適化する。問題を特定し解決するにはこれが一般的な方法です。

9. 市場レポートが見つかりません。

レポートは全市場向けにあるわけではありません。おそらくお選びの市場は収集されたレポートがないものです。本稿パート4の表でご希望の市場を探してみてください。その市場が表になければ、その市場に対するレポートがただ存在しないか完成されていないのです。よって利用はできません。市場が表で明確になれば、それに対応するファイルレポート名を見ます。このファイルをマニュアルでインディケータにロードします。

10. インディケータ(スクリプト、エキスポート)が動作しません。どうすればよいのでしょうか?

本稿パート3をもっと注意して読む必要があります。何かをし忘れているか正しく行えてない可能性があります。注意して読み、ご自身で問題を解決するようにしてください。

11. インディケータが表示されません。

主な理由はレポートファイルの不在です。レポートファイルがダウンロードされていることを確認します。それには、『ターミナル』を開き、『ログ』タブを選んでインディケータをもう一度ダウンロードします。インディケータをがレポートファイルを見つけていないのであれば、「ファイル File_name.scv のダウンロードエラー」という警告メッセージを受け取ります。それ以上の作業は不可能です。ご自身のターミナルで \files ディレクトりに行き、必要なファイルがあるか確認します。ファイルがなければ、バッチプログラム erase_cot.batによってレコードをすべて削除し、再度作成します。必要なファイルが表示されます。

12. インディケータは表示されますが、指定されたように表示されません。インディケータ名の代わりに、「商品が見つかりません」と出ます。

最も可能性が高いのは、現行ツール名がレポート名のどれとも一致していないことです。ファイル settings.ini を開き、自動でロードされるはずのレポートを見つけます。レポートが密ならなければ、自分で設定をします(3.4項参照)。ファイルリストに商品名を追加します。インディケータを再起動すれば、動作するはずです。

13. エキスパートがトレードを行いません。

これに関して可能性のある理由は、エキスパート動作のために必要なレポートファイルが \tester\files ディレクトリにコピーされていないことです。ストラテジーテスタはこのカタログを使用します。よってそこで作業するファイルが必要となります。コンフィギュレーションファイルを含むすべてのファイルを \tester\ ディレクトリにコピーします。エキスパートは動作するはずです。

14. Meta COT を基にして自分のインディケータをを作成することは可能ですか?

もちろんできます。必要な主要関数は get_data です(int タイプ、int バー)。それはタイプパラメータで指定されるインディケータ値を返します。本稿のパート3に、主なコードと例について詳しい情報があります。

15. ポートフォリオ エキスパートの作成方法は?

マルチインスツルメンタル トレードはまだ提供していません。データのダウンロード用にご自分のメソッドを作成する必要があります。代替として、注文したファイルのロードを適用することができます。この場合、データは各商品に対して個別のセクションに格納されます。ただし、すべてさらなる開発を必要とします。

16. スクリプトが設定機能なしで実行します。/必須でないにもかかわらずスクリプト開始前に毎回設定ウィンドウを表示します。

設定呼び出しを定義する #property 命令があります。設定を変更する必要がなければ、ただそれをコメントします。逆に設定をカスタマイズする必要があれば、コメントは削除します。それからスクリプトを再コンパイルします。

17. 記事を読んだ後にもまだ質問がたくさんあります。

Larry Williamsの著書『Trade Stocks & Commodities with the Insiders: Secrets of the COT Report 』を数回再読ください。CTFC レポート分析は大きなトピックです。

参照資料

1. Larry Williams, Trade Stocks & Commodities with the Insiders: Secrets of the COT Report (Wiley Trading)

2. Stephen Briese. The Commitments of Traders Bible.

3. Campbell R. McConnell, Stanley L. Brue. Economics: Principles, Problems, and Policies, 16th edition

4. Todd Lofton, Getting Started in Futures

5. http://www.procapital.ru/forumdisplay.php?f=267 The topic about CFTC report analysis application (in Russian).

6. http://www.aup.ru/articles/finance/1.htm The concept of risk in economic activity article by Valery Romanov.

7. http://www.timingcharts.com Site with COT charts.

8. http://www.ireallytrade.com Larry Williams's site. CFTC レポートに関する情報が入っています。メインのページでは Larry Williams が最近のトレード機会について有用なアドバイスを提供しています。

9. http://commitmentsoftraders.org Steve Briese's site. It's mostly about his book. 有用な分析と追加インディケータが入っています。基本的に PDF です。

10. http://cftc.gov U.S. Commodity Futures Trading Commission site. トレーダーのポジションに関する最近のデータがあります。COT 分析についての主要な情報源です。


MetaQuotes Ltdによってロシア語から翻訳されました。
元の記事: https://www.mql5.com/ru/articles/1573

添付されたファイル |
MetaCOT.zip (51.11 KB)
ニューラルネットワークFANN2MQL のチュートリアル ニューラルネットワークFANN2MQL のチュートリアル
本稿は、FANN2MQL によるニューラルネットワークの使用方法を簡単な例を用いて説明するために書かれました。
開発者諸君、己を守れ! 開発者諸君、己を守れ!
知的財産の保護はいまだに大きな問題です。本稿では MQL4 プログラム保護の基本原則について説明します。これら原則により、みなさんの開発結果が盗難にあわないよう、すくなくとも盗人の『仕事』をひじょうに複雑にして行わなくなるようにします。
ろうそく方向の統計的回帰研究 ろうそく方向の統計的回帰研究
やってくる短い時間間隔に対して、ろうそく足インディケータの定期的な傾向を基に、1日の特定時刻の市場動向を予想することは可能なのでしょうか?まず第一にそのような発生が検出されるなら、可能です。この疑問はおそらくどのトレーダーの心にも浮かんだことのあるものでしょう。本稿の目的は、ろうそく足の方向の統計的回帰に基づき、特定の時間間隔で市場動向の予想を試みることです。
金融証券の重ね合わせとインターフェース 金融証券の重ね合わせとインターフェース
通貨ペアの変動に影響を与える要因が多いほど、その変動を評価し将来を予測するのが困難になります。そのため、通貨ペアの構成要素と時間と共に変化する各国通貨の値をなんとか抽出することができれば、その動向に影響を与える要因数と共に、この通貨を通貨ペアと比較して各国通貨の動きの自由度の範囲を定めることができるかもしれません。結果、その変動推定と将来予測の精度を挙げることになるでしょう。どうすればそれができるのでしょうか?