I. 電子取引システム例
図1は、所定の実施形態が使用され得る電子取引システム100を示すブロック図である。システム100は、クライアントデバイス110と、ゲートウェイ120と、電子取引所130とを含む。クライアントデバイス110は、ゲートウェイ120と通信している。ゲートウェイ120は、電子取引所130と通信している。
本明細書において「と通信している」という言い回しは、直接的な通信および1つまたは複数の中間コンポーネントを介する間接的通信を含む場合がある。
作動中、クライアントデバイス110は、取引可能オブジェクトを買う、または売るための注文を取引所130へ送ってもよい。例えば、ユーザは、クライアントデバイス110を利用して注文を送ってもよい。注文は、ゲートウェイ120を介して取引所130へ送られる。さらには、市場データが取引所130からゲートウェイ120を介してクライアントデバイス110へ送られる。また、ユーザは、クライアントデバイス110を利用してこの市場データを監視し、かつ市場データを基礎として取引可能オブジェクトに関する注文を送るように決定してもよい。
取引可能オブジェクトは、ある量および/または価格で取引されることが可能な任意のものである。例えば、株式、オプション、債券、先物、通貨、ワラント、ファンド派生商品、証券、商品、取引されるイベント、グッズおよびコレクションおよび/またはこれらの組合せ等の金融商品が取引可能オブジェクトであってもよい。取引可能オブジェクトは、「実物」であっても、「合成物」であってもよい。実物である取引可能オブジェクトには、取引所によってリストされている商品が含まれる。合成物である取引可能オブジェクトには、ユーザによって定義され、取引所によってリストされていない商品が含まれる。例えば、合成物である取引可能オブジェクトには、クライアントデバイス110を利用するトレーダによって作成される合成スプレッド等の実際の(または他の合成)商品の組合せが含まれてもよい。
クライアントデバイス110には、例えば、携帯デバイス、ラップトップ、デスクトップコンピュータ、シングルまたはマルチ・コア・プロセッサを有するワークステーション、複数のプロセッサを有するサーバおよび/またはコンピュータのクラスタ等の1つまたは複数の電子コンピューティングプラットフォームが含まれてもよい。例えば、クライアントデバイス110は、論理上は単一のデバイスとして表現されるが、取引する側の端末およびサーバが集合的にクライアントデバイス110である、サーバと通信する取引端末を含んでもよい。取引端末はユーザへ取引画面を提示してもよく、かつ取引画面を介する発注等のユーザ入力のさらなる処理に関するコマンドをサーバへ伝達してもよい。
クライアントデバイス110は、概して、ユーザにより所有され、操作され、制御され、プログラムされ、設定され、または別途使用される。本明細書において、「ユーザ」という言い回しは、人(例えば、トレーダ)または電子取引デバイス(例えば、プロセッサおよびメモリまたはアルゴリズム取引システムを含む)を含んでもよいが、これらに限定されない。一人または複数のユーザは、例えば、オーナーシップ、操作、制御、プログラミング、設定または他の用途に関係するものであってもよい。
クライアントデバイス110は、1つまたは複数の取引アプリケーションを含んでもよい。取引アプリケーションは、例えば、市場データを配列して取引ウィンドウおよびチャートウィンドウに表示することによって市場データを処理してもよい。市場データは、例えば取引所130から受信されてもよい。別の例として、市場データは、履歴データを提供しかつ/または交換をシミュレートするが実世界の取引は実行しないシミュレーション環境から受信されてもよい。この処理は、例えば、ユーザ選好を基礎とするものであってもよい。取引アプリケーションは、例えば、自動スプレッド取引ツール等の自動取引ツールを含んでもよい。1つまたは複数の取引アプリケーションは、クライアントデバイス110のコンピューティングデバイスのうちの1つまたはそれ以上に分散されてもよい。例えば、取引アプリケーションの所定のコンポーネントは取引ワークステーション上で実行されてもよく、かつ取引アプリケーションの他のコンポーネントはワークステーションと通信するサーバ上で実行されてもよい。
クライアントデバイス110は、例えば、電子取引ワークステーション、携帯用取引デバイス、「ブラックボックス」または「グレーボックス」等のアルゴリズム取引システム、内蔵式の取引システムおよび/または自動取引ツールを含んでもよい。例えば、クライアントデバイス110は、イリノイ州シカゴ所在のTrading Technologies International社によって提供される電子取引プラットフォームである、X_TRADER(登録商標)のコピーを実行するコンピューティングシステムであってもよい。別の例として、クライアントデバイス110は、同じくTrading Technologies International社によって提供されるAutospreader(登録商標)および/またはAutotrader(商標)等の自動取引ツールを実行するコンピューティングデバイスであってもよい。
取引アプリケーションは、クライアントデバイス110のコンピュータ読取り可能媒体に格納されてもよい。所定の実施形態において、取引アプリケーションの所定のコンポーネントは取引ワークステーションに格納されてもよく、かつ取引アプリケーションの他のコンポーネントはワークステーションと通信するサーバに格納されてもよい。所定の実施形態において、取引アプリケーションの1つまたは複数のコンポーネントは、クライアントデバイス110のコンピュータ読取り可能媒体へ別のコンピュータ読取り可能媒体からロードされてもよい。例えば、取引アプリケーション(または取引アプリケーションの更新)は、製造業者、開発者または発行者によって1つまたは複数のCDまたはDVDに格納されてもよく、前記CDまたはDVDは、次に、クライアントデバイス110へのアプリケーションのロードを担当する誰かへ、またはクライアントデバイス110が取引アプリケーションを検索する先のサーバへ提供される。別の例として、クライアントデバイス110は、取引アプリケーション(または取引アプリケーションの更新)をサーバから、例えばインターネットまたは内部ネットワークを介して受信してもよい。クライアントデバイス110は、取引アプリケーションまたは更新を、クライアントデバイス110が要求して受信する(「プル配信」)場合もあれば、クライアントデバイス110が要求しなくても受信する(「プッシュ配信」)場合もある。
クライアントデバイス110は、取引可能オブジェクトの買い注文または売り注文を送信するように適合化される。またクライアントデバイス110は、例えば、注文をキャンセルし、注文を変更しかつ/または交換を照会するように適合化されてもよい。別の例として、クライアントデバイス110は、実世界での取引を実行しないシミュレーション環境におけるシミュレートされた取引所へ注文を送信するように適合化されてもよい。
クライアントデバイス110によって送信される注文は、例えばユーザに要求されて送信される場合もあれば、自動的に送信される場合もある。例えば、トレーダは、電子取引ワークステーションを利用して特定の取引可能オブジェクトを発注し、その注文について、注文の価格および/または数量等の様々なパラメータを手動で提供してもよい。別の例として、自動取引ツールは、ある注文に関する1つまたは複数のパラメータを計算し、かつ自動的に注文を送信してもよい。インスタンスによっては、自動取引ツールは送信されるべき注文を準備する場合があるが、ユーザからの確認なしには実際には送信しない。
所定の実施形態において、クライアントデバイス110はユーザインタフェースを含む。ユーザインタフェースは、例えば、取引アプリケーションのテキストベースのインタフェースまたはグラフィカルインタフェースをユーザに提示するための1つまたは複数のディスプレイデバイスを含んでもよい。例えば、ディスプレイデバイスには、コンピュータモニタ、ハンドヘルドデバイスのディスプレイ、プロジェクタおよび/またはテレビが含まれてもよい。ユーザインタフェースは、取引アプリケーションを用いて注文に関するパラメータを指定する、または見直すために、ユーザによって用いられてもよい。ユーザインタフェースは、例えば、ユーザからの入力を受信するための1つまたは複数の入力デバイスを含んでもよい。例えば、入力デバイスには、キーボード、トラックボール、2つまたは3つボタン式マウスおよび/またはタッチスクリーンが含まれてもよい。ユーザインタフェースは、ユーザと相互に作用するための他のデバイスを含んでもよい。例えば、情報は、スピーカを介して聴覚的にユーザへ提供されても、かつ/またはマイクロホンを介して受信されてもよい。
所定の実施形態において、取引アプリケーションは、トレーダが1つまたは複数の市場と相互作用できるようにする1つまたは複数の取引画面を含んでもよい。取引画面は、例えば、トレーダが、様々な取引戦略を実装しながら市場情報を入手して視聴し、注文エントリパラメータを設定し、注文を出しかつキャンセルし、かつ/またはポジションを監視できるようにしてもよい。例えば、取引アプリケーションは、取引所130から情報(買い呼び値、買い数量、売り呼び値、売り数量、過去の販売に関する価格および数量および/または他の市場関連情報等)を受信してもよく、これらの情報は次に、クライアントデバイス110のユーザインタフェースによって表示されてもよい。受信される情報を基礎として、取引画面は、取引可能オブジェクトに関する一定範囲の価格レベルおよびその価格レベルの対応する売買数量を表示してもよい。トレーダに関連取引情報を提供するために、取引画面は、場内市場辺りの価格範囲(および対応する売買数量)を表示してもよい。情報は取引アプリケーションへ絶えず、または定期的に提供されてもよく、これにより取引アプリケーションは、取引画面を現行の市場情報で更新することができる。トレーダは取引画面を用いて、例えば、取引可能オブジェクトの買い注文および売り注文を出しても、別途、表示された情報を基礎として取引可能オブジェクトの取引を行ってもよい。
取引画面は、1つまたは複数の取引ツールを表示してもよい。取引ツールは、電子取引を可能にし、アシストしかつ/または容易にする電子ツールである。例示的な取引ツールには、チャート、取引ラダー、注文エントリツール、自動取引ツール、自動スプレッドツール、リスク管理ツール、注文パラメータツール、注文エントリシステム、市場格子、フィルウィンドウおよび市場注文ウィンドウ、これらの組合せ、取引、取引の準備または取引の管理に用いられる他の電子ツールが含まれるが、この限りではない。
所定の実施形態において、クライアントデバイス110はアルゴリズム取引アプリケーションを含む。例えば、クライアントデバイス110はブラックボックスまたはグレーボックス取引アプリケーションを含んでもよい。別の例として、クライアントデバイス110は、市場データをアルゴリズム的に処理する、但しユーザがアルゴリズム的処理を基礎として手動で発注すること、または自動的に行われた注文を操作することを可能にするユーザインタフェースを提供する取引アプリケーションを含んでもよい。アルゴリズム取引アプリケーションは、所定のアクションを実行するために自動的に処理されるアルゴリズムを含む取引アプリケーションである。即ち、取引アプリケーションは、定義されたアクションを実行するための自動化された一連の命令を含む。アクションは、例えば、市場データを特定の方法で処理すること、発注すること、既存の注文を修正すること、注文を削除すること、発注を控えること、どの取引可能オブジェクトに作用するかを選択すること、発注価格または修正注文価格を決定すること、発注する数量または注文を修正する数量を決定すること、注文が買い注文であるべきか、売り注文であるべきかを決定すること、およびアクションを一定期間遅らせることを含んでもよい。
本明細書において、アルゴリズム(取引アルゴリズムとも称される)は、取引に使用されるべきアルゴリズムを記述する論理式およびパラメータを含む定義によって指定される。論理式はパラメータ間の関係を指定し、かつさらなるパラメータを生成する場合がある。パラメータには、例えば、アルゴリズムの論理式への入力が含まれてもよい。アルゴリズムの定義は、アルゴリズム取引アプリケーションによって少なくとも部分的に指定されてもよい。例えば、アルゴリズム取引アプリケーションは、ユーザが使用されるべきパラメータを予め定義された論理式によってのみ指定できるようにしてもよい。別の例として、アルゴリズム取引アプリケーションは、ユーザが論理式の幾分か、または全て、およびパラメータの幾分か、または全てを指定できるようにしてもよい。論理式がユーザによって指定される取引アルゴリズムは、ユーザ定義取引アルゴリズムである。
所定の実施形態において、クライアントデバイス110からの注文はゲートウェイ120を介して取引所130へ送信される。クライアントデバイス110はゲートウェイ120と、例えばローカル・エリア・ネットワーク、広域ネットワーク、仮想専用ネットワーク、Tl回線、T3回線、ISDN回線、ポイント・オブ・プレゼンスおよび/またはインターネットを用いて通信してもよい。
ゲートウェイ120は、クライアントデバイス110および取引所130と通信するように適合化される。ゲートウェイ120は、クライアントデバイス110と取引所130との間の通信を容易にする。例えば、ゲートウェイ120は、クライアントデバイス110から注文を受信しかつこの注文を取引所130へ送信してもよい。別の例として、ゲートウェイ120は、取引所130から市場データを受信しかつこの市場データをクライアントデバイス110へ送信してもよい。
所定の実施形態において、ゲートウェイ120は、クライアントデバイス110と取引所130との間で通信されるデータの処理を実行する。例えば、ゲートウェイ120は、クライアントデバイス110から受信される注文を取引所130によって受容可能なデータフォーマットへと処理してもよい。同様に、ゲートウェイ120は、取引所130から受信される取引所固有フォーマットの市場データをクライアントデバイス110によって理解されるフォーマットへ変換してもよい。また、ゲートウェイ120による処理は、例えば、クライアントデバイス110からの注文を追跡し、かつ取引所130から受信される約定確認を基礎として注文の状況を更新することを含んでもよい。別の例として、ゲートウェイ120は取引所130からの市場データを融合し、かつこれをクライアントデバイス120へ提供してもよい。
所定の実施形態において、ゲートウェイ120は、クライアントデバイス110と取引所130との間で通信されるデータの処理以外のサービスを提供する。例えば、ゲートウェイ120はリスク処理を提供してもよい。
ゲートウェイ120には、例えば、携帯デバイス、ラップトップ、デスクトップコンピュータ、シングルまたはマルチ・コア・プロセッサを有するワークステーション、複数のプロセッサを有するサーバおよび/またはコンピュータのクラスタ等の1つまたは複数の電子コンピューティングプラットフォームが含まれてもよい。
ゲートウェイ120は、1つまたは複数のゲートウェイアプリケーションを含んでもよい。ゲートウェイアプリケーションは、例えば、注文の処理および市場データの処理を扱ってもよい。この処理は、例えば、ユーザの選好を基礎とするものであってもよい。
所定の実施形態において、ゲートウェイ120は取引所130と、例えばローカル・エリア・ネットワーク、広域ネットワーク、仮想専用ネットワーク、Tl回線、T3回線、ISDN回線、ポイント・オブ・プレゼンスおよび/またはインターネットを用いて通信してもよい。
概して、取引所130は、取引エンティティにより所有され、操作され、制御され、または使用されてもよい。例示的な取引エンティティには、CMEグループ、ロンドン国際金融先物オプション取引所(「LIFFE」)、インターコンチネンタルエクスチェンジ(「ICE」)およびユーレックスが含まれる。取引所130は、コンピュータ、サーバまたは、例えば取引所による取引用に提供される取引可能オブジェクトを買う、または売ることができるように適合化された他のコンピューティングデバイス等の電子マッチングシステムであってもよい。
取引所130は、取引可能オブジェクトの買い注文と売り注文とを整合させるように適合化される。取引可能オブジェクトは、取引所130による取引用にリストされてもよい。注文には、例えば、クライアントデバイス110から受信される注文が含まれてもよい。注文は、例えば、クライアントデバイス110からゲートウェイ120を介して受信されてもよい。さらに、注文は、取引所130と通信する他のデバイスから受信されてもよい。即ち、典型的には、取引所130は、同じく整合されるべき注文を提供する様々な他のクライアントデバイス(クライアントデバイス110に類似するものであってもよい)と通信し合う。
取引所130は、市場データを提供するように適合化される。市場データは、例えば、クライアントデバイス110へ提供されてもよい。市場データはクライアントデバイス110へ、例えばゲートウェイ120を介して提供されてもよい。市場データは、例えば、場内市場を表すデータを含んでもよい。場内市場は、ある特定の時点における一番安い売り値(「一番安い指値価格」とも称される)および一番高い買い値(「一番高い指値価格」とも称される)である。市場データは、市場の深さも含む場合がある。市場の深さは、場内市場における入手可能な量を指し、かつ場内市場以外での他の価格で入手可能な量も指す場合がある。したがって、場内市場は、第1の市場の深さレベルとされてもよい。場内市場以外での1ティックは、例えば、第2の市場の深さレベルとされてもよい。所定の実施形態において、市場の深さは、全ての価格レベルに関して規定される。所定の実施形態において、市場の深さは、全ての価格レベルに関して規定されるわけではない。例えば、市場の深さは、場内市場の内外で最初の5つの価格レベルに関してのみ規定されてもよい。また、市場の深さは、最終取引価格(LTP)、最終取引数量(LTQ)および注文約定情報等の情報も含む場合がある。
所定の実施形態において、システム100は、2つ以上のクライアントデバイス110を含む。例えば、先に論じたクライアントデバイス110に類似する複数のクライアントデバイスが、取引所130へ注文を送信するためにゲートウェイ120と通信していてもよい。
所定の実施形態において、システム100は、2つ以上のゲートウェイ120を含む。例えば、先に論じたゲートウェイ120に類似する複数のゲートウェイが、クライアントデバイス110および取引所130と通信していてもよい。このような配置は、例えば、ゲートウェイ120が故障した場合に冗長性を与えるために用いられてもよい。
所定の実施形態において、システム100は、2つ以上の取引所130を含む。例えば、ゲートウェイ120は、先に論じた取引所130に類似する複数の取引所と通信していてもよい。このような配置は、例えば、クライアントデバイス110が2つ以上の取引所でゲートウェイ120を介して取引できるようにしてもよい。
所定の実施形態において、システム100は、2つ以上の取引所130および2つ以上のゲートウェイ120を含む。例えば、先に論じたゲートウェイ120に類似する複数のゲートウェイは、先に論じた取引所130に類似する複数の取引所と通信していてもよい。各ゲートウェイは、例えば1つまたは複数の異なる取引所と通信していてもよい。このような配置は、例えば、1つまたは複数のクライアントデバイス110が2つ以上の取引所で取引できるように(かつ/または、複数の取引所へ冗長な接続を提供できるように)してもよい。
所定の実施形態において、クライアントデバイス110は、1つまたは複数のコンピューティングデバイスまたは処理コンポーネントを含む。言い替えれば、クライアントデバイス110の機能は、2つ以上のコンピューティングデバイスによって実行されてもよい。例えば、1つのコンピューティングデバイスは、取引所130へ送信されるべき注文を生成してもよく、一方で別のコンピューティングデバイスはトレーダへグラフィカル・ユーザ・インタフェースを提供してもよい。所定の実施形態において、ゲートウェイ120は、1つまたは複数のコンピューティングデバイスまたは処理コンポーネントを含む。言い替えれば、ゲートウェイ120の機能は、2つ以上のコンピューティングデバイスによって実行されてもよい。所定の実施形態において、取引所130は、1つまたは複数のコンピューティングデバイスまたは処理コンポーネントを含む。言い替えれば、取引所130の機能は、2つ以上のコンピューティングデバイスによって実行されてもよい。
所定の実施形態において、ゲートウェイ120はクライアントデバイス110の一部である。例えば、ゲートウェイ120のコンポーネントは、クライアントデバイス110と同じコンピューティングプラットフォームの一部であってもよい。別の例として、ゲートウェイ120の機能は、クライアントデバイス110のコンポーネントによって実行されてもよい。所定の実施形態では、ゲートウェイ120が存在しない。このような配置は、例えば、クライアントデバイス110が取引所130との通信にゲートウェイ120を利用する必要がない場合、例えば、クライアントデバイス110が取引所130と直に通信するように適合化されている場合、に発生することがある。
所定の実施形態において、ゲートウェイ120は、物理的にクライアントデバイス110と同じ場所に位置決めされる。所定の実施形態において、ゲートウェイ120は、物理的に取引所130と同じ場所に位置決めされる。所定の実施形態において、クライアントデバイス110は、物理的に取引所130と同じ場所に位置決めされる。所定の実施形態において、ゲートウェイ120は、物理的にクライアントデバイス110および取引所130の双方から分離された場所に位置決めされる。
明瞭さを期して図示されていないが、所定の実施形態において、システム100は他に、ミドルウェア、ファイアウォール、ハブ、スイッチ、ルータ、取引所固有の通信機器、モデム、セキュリティマネージャおよび/または暗号化/復号化デバイス等の通信アーキテクチャ固有のデバイスを含んでもよい。
先に論じたシステム100のコンポーネント、エレメントおよび/または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび/またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、CD−ROM、DVD、EPROMおよび/またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
II. アルゴリズム注文ビルダ
所定の実施形態は、ビルディング・ブロック・ボタンおよびアルゴリズムを定義するアルゴリズムエリアを提供する。所定の実施形態は、単一の取引セッションの間であってもアルゴリズムのパラメータおよび論理の双方を迅速に調整することを見込んでいる。所定の実施形態は、アルゴリズムが定義されるにつれて式のライブ評価を提供する。所定の実施形態は、構文エラー、不明瞭な論理およびトレーダでないプログラマがトレーダにより指定される通りにアルゴリズムを開発する必要性等の伝統的にプログラムされるアルゴリズムのリスクを、ユーザによるプログラミングコードの書込みを減らす、またはなくすことによって低減する。所定の実施形態は、アルゴリズムの構築、デバッグおよび(実際の市場データを用いる)シミュレーションを全て同時に行うための単一のアプリケーションを提供する。さらに、この単一のアプリケーションは、アルゴリズムを用いる発注の開始にも備える場合がある。
図2Aは、所定の実施形態による取引インタフェース200を示す。取引インタフェース200は、アルゴリズム注文ビルダ(「AOB」)と称されるアルゴリズム取引アプリケーションのための取引インタフェースである。AOBは、トレーダが、行われるべき注文のためのアルゴリズムを生成できるようにする。しかしながら、図示されている取引インタフェース200のエレメントが他の取引インタフェースに組み込まれてもよいことは理解されるべきである。
取引インタフェース200は、インスツルメント選択ボタン201と、市場格子202と、シミュレートされた参考注文の入力エリア203と、オートヘッジ・オプション204と、スクラッチ量205と、変数エリア206と、アルゴリズムエリア210と、ビルディング・ブロック・ボタン215とを含む。アルゴリズムエリア210は、価格エリア211と、数量エリア212と、条件付きエリア213とを含む。
動作中は、1つまたは複数のビルディング・ブロック・ボタン215を利用して価格エリア211、数量エリア212および/または条件付きエリア213に式を構築することにより、アルゴリズムエリア210においてアルゴリズムが定義される。アルゴリズムにおけるユーザ定義変数のデフォルト値は、変数エリア206を用いて指定されてもよい。アルゴリズムが定義されると、式の論理がどのように行動するかを表示するために、シミュレートされた参考注文の入力エリア203が使用されてもよい。次には、取引インタフェースを用いて、定義されたアルゴリズムに従って管理されるべき注文が開始されてもよい。
インスツルメント選択ボタン201は、行われるべき注文が関連するインスツルメント(即ち、取引可能オブジェクト)の選択を準備する。図2Aに示されているように、インスツルメント選択ボタン201は、選択されたインスツルメントの名称がインスツルメント選択ボタン201に表示されているように、既にGEH1−GEM1カレンダースプレッドを選択すべく使用されている。インスツルメントがまだ選択されていなければ、インスツルメント選択ボタン201は「インスツルメントを選択」と表示するか、インスツルメントがまだ選択されていない旨の他の何らかの表示を与える場合がある。
(例えば、ポインタを用いて選択すること、またはタッチスクリーンに接触することによって)インスツルメント選択ボタン201が起動されると、インスツルメントを選択できるようにするインスツルメント選択インタフェースが表示されてもよい。
図2Bは、所定の実施形態によるインスツルメント選択インタフェース220を示す。インスツルメント選択インタフェース220は取引可能な商品のリストを表示し、かつインスツルメントツリーを辿ることによって取引されるべき特定の取引可能オブジェクトをユーザが指定できるようにする。インスツルメントツリーは、ユーザが、例えばインスツルメント、インスツルメントのタイプ(例えば、スプレッドまたは先物)および表示されるべき特定の契約を選ぶことができるようにする。例えば、図示されているように、GEH1−GEM1カレンダースプレッドが選択されている。
再度、図2Aを参照すると、市場格子202は、ある取引可能オブジェクトの市場情報を表示する。取引可能オブジェクトは、例えば、インスツルメント選択ボタン201で選択されたインスツルメントであってもよい。別の例として、取引可能オブジェクトはユーザが選択する別の取引可能オブジェクトであってもよい。市場格子202は、例えば、取引可能オブジェクトの買いおよび/または売り呼び値、買いおよび/または売り数量、最終取引価格および/または数量情報を表示してもよい。例えば、市場格子202は、選択されたインスツルメントの場内市場価格および数量を表示してもよい。
シミュレートされた参考注文の入力エリア203は、アルゴリズムエリア210において定義されるアルゴリズムの運用面を評価するためのフィードバックの生成に備える。ユーザは、式の論理がどのように行動するかを表示するために、シミュレートされた参考注文の入力エリア203を用いて選択されたインスツルメントの売り買いを仮想注文するシミュレーションを行ってもよい。同じくシミュレートされた参考注文の入力エリア203を用いて、仮想注文の価格および/または数量も指定される場合がある。さらに、所定の実施形態において、シミュレートされた参考注文の入力エリア203は、注文が定義されたアルゴリズムに従って管理される場合に、選択されたインスツルメントを売り買いする実際の注文の実行を(例えば、チェックボックスを選択することによって)開始するように設定されてもよい。
オートヘッジ・オプション204は、開始された注文が約定されると反対注文が行われる旨を指定することに備える。反対注文は、約定された注文が買い注文であれば売り注文であり、かつ約定された注文が売り注文であれば買い注文である。反対注文の量は、例えば約定された数量と同じであってもよい。反対注文は、まず、例えば約定された注文の価格から取引可能な1増分(取引所が規定するもの)等の利益のある出口価格で行われる。例えば、約定された注文が数量10を価格100で買ったとすれば、反対注文は、数量10を価格101で売る注文であってもよい。別の例として、約定された注文が数量5を価格100で売ったとすれば、反対注文は、数量5を価格99で買う注文であってもよい。
スクラッチ量205は、オートヘッジ・オプション204によって用いられる。市場における反対注文の価格レベルでの数量が指定されたスクラッチ量205より下がると、反対注文の価格レベルは、対応する約定された注文の価格になるように変更される。この場合、約定された注文は「スクラッチされた」と言われ、その取引に利益はない。所定の実施形態において、反対注文は、損益に関わりなくポジションを閉じる価格で出されてもよい。
変数エリア206は、アルゴリズムエリア210で使用されるユーザ定義変数を指定しかつ修正することに備える。変数エリア206は、各変数の名称およびその値を表示する。変数エリアは、変数の名称および/またはその値を変更するために選択されてもよい。
変数は、アルゴリズムのパラメータと称される場合もある。
アルゴリズムエリア210は、注文を管理するためのアルゴリズムを定義することに備える。アルゴリズムエリア210は、価格エリア211と、数量エリア212と、条件付きエリア213とを含む。各エリアは、アルゴリズムの異なる態様に対応する。
ビルディング・ブロック・ボタン215は、アルゴリズムを定義すべくアルゴリズムエリア210において式を構築するために使用される。式は、アルゴリズムエリア210の各エリアの値を決定するために評価される。式は、ビルディング・ブロック・ボタン215によって指定される1つまたは複数の要素を含む。以下、ビルディング・ブロック・ボタン215の使用についてさらに詳しく述べる。
アルゴリズムエリア210においてアルゴリズムが定義されると、取引インタフェースによって買い注文または売り注文が開始されてもよい。例えば、仮想注文の開始に備えることに加えて、所定の実施形態では、シミュレートされた参考注文の入力エリア203もまた実際の注文を開始することに備える場合がある。別の例として、後述するものに類似する取引インタフェースが注文の開始に使用されてもよい。すると、開始された注文は、定義されたアルゴリズムに従って管理される。
価格エリア211は、管理されている注文の発注価格を決定するために評価される。価格エリア211は、価格を表す数字を評価する。価格エリア211が空白であれば、シミュレートされた参考注文の入力エリア203で指定された価格が使用される。価格エリア211が式を含んでいれば、シミュレートされた参考注文の入力エリア203で指定されている価格は無視されてもよい。価格エリア211は、市場データが変わるとき等の異なる時間に異なる値を評価する場合がある。そうであれば、管理されている注文は新しい価格で受け付けられるように変更される。これは、例えば、注文を削除しかつ新しい価格で新しい注文を出すことによって、またはキャンセル/置換コマンドを用いることによって達成されてもよい。
数量エリア212は、管理されている注文の発注数量を決定するために評価される。数量エリア212は、数量を表す数字を評価する。数量エリア212が空白であれば、シミュレートされた参考注文の入力エリア203で指定された数量が使用される。数量エリア212が式を含んでいれば、シミュレートされた参考注文の入力エリア203で指定されている数量は無視されてもよい。数量エリア212は、市場データが変わるとき等の異なる時間に異なる値を評価する場合がある。そうであれば、管理されている注文は新しい数量で受け付けられるように変更される。これは、例えば、注文を削除しかつ新しい数量で新しい注文を出すことによって、または注文数量変更コマンドを用いることによって達成されてもよい。数量エリア212が0を評価するのであれば、管理されている注文は、数量エリア212が非ゼロ値を評価するまで市場から取り除かれてもよい。これは、後述するように、条件付きエリア213が「偽」を評価することに類似する場合がある。
所定の実施形態では、アルゴリズムエリア210は数量エリア212を含まない。代わりに、数量は一定であるか、予め定義されている場合がある。例えば、ヘッジ注文を管理するための取引インタフェース(ヘッジ注文は、例えば取引戦略の取引可能オブジェクトのための別の注文が約定されると自動的に出される注文であり、これは、ヘッジ・マネージャ・インタフェースとも呼ばれることがある)は、他の注文の約定された数量を基礎とする、従ってアルゴリズムの観点から予め決められている数量を用いる場合がある。したがって、ヘッジ注文を機能させるためにアルゴリズムを使用できるようにする場合のあるこのような取引インタフェースにおけるアルゴリズムエリアは、数量値はアルゴリズムが利用される時点で予め決められることから指定する必要がないという理由で数量エリア212を含まなくてもよい。
条件付きエリア213は、そのアルゴリズムが機能すべきものであるかどうかを決定するために評価される。条件付きエリア213は、ブール値を評価する。条件付きエリア213が「真」と評価すれば、そのアルゴリズムは機能している。条件付きエリア213が「偽」と評価すれば、そのアルゴリズムは機能していない。条件付きエリア213が空白であれば、アルゴリズムは常時機能している。条件付きエリア213は、市場データが変わるとき等の異なる時間に異なる値を評価する場合がある。アルゴリズムが機能している場合、管理されている注文は市場へ入力され、かつ先に論じたように、決定された価格および数量によって機能される。アルゴリズムが機能していない場合、管理されている注文は市場から除去される。これは、例えば、注文を削除することによって達成されてもよい。
所定の実施形態では、アルゴリズムエリア210は条件付きエリア213を含まない。代わりに、アルゴリズムは、一旦注文が開始されると単に常時「機能して」いてもよい。例えば、ヘッジ・マネージャ・インタフェースにおいては、ヘッジ注文は可能な限り迅速に約定されることが望まれ得ることから、ヘッジ注文を管理するアルゴリズムは常時機能している場合がある。
価格エリア211、数量エリア212および/または条件付きエリア213における式が評価する値が適切なタイプ(価格エリア211、注文数量エリア212の場合は数字、条件付きエリア213の場合はブール値)でなければ、その式は無効である。式が無効であることを表示するために、特定エリアの背景は緑(有効な式を示す)から赤(無効な式を示す)へ変更されてもよい。アルゴリズムエリア210のエリアのうちの1つで式が無効であれば、注文を出すことはできない。
所定の実施形態では、背景色の他に(またはこれに加えて)他のインジケータが、アルゴリズムエリア210のエリア内の式が無効であることを表示するために用いられてもよい。例えば、異なる背景パターン、異なる境界色またはスタイル、「準備完了」または「無効」等のテキストメッセージおよび/または感嘆符のアイコンが用いられてもよい。
アルゴリズムに従って管理されている注文が約定されれば、先に論じたように、オートヘッジ・オプション204およびスクラッチ量205を基礎として反対注文が自動的に出されてもよい。
先に論じたように、ビルディング・ブロック・ボタン215は、アルゴリズムを定義すべくアルゴリズムエリア210において式を構築するために使用される。ビルディング・ブロック・ボタン215は、例えば、アイコン、可動アイコン、アイコンボタン、可動ボタンまたはユーザ・インタフェース・エレメントとも称される場合がある。式は要素(論理式およびパラメータ)を含み、かつアルゴリズムエリア210の各エリアの値を決定するために評価される。ビルディング・ブロック・ボタン215は、式を構築するために選択されてアルゴリズムエリア210の特定のエリアに配置されてもよい。例えば、ユーザは、1つまたは複数のビルディング・ブロック・ボタン215を、価格エリア211、数量エリア212および/または条件付きエリア213等のアルゴリズムエリア210のエリアのうちの1つまたはそれ以上へドラッグアンドドロップしてもよい。別の例として、ユーザはビルディング・ブロック・ボタン215を、例えばそれをクリックすることによって選択してもよく、選択されたボタン215は次に、最近に使用されたアルゴリズムエリア210に配置されてもよい。ビルディング・ブロック・ボタン215をアルゴリズムエリア210に配置すると、アルゴリズムエリア210内に構築されている式内に要素が配置される。後述するように、式内の所定の要素は、例えば部分式として作用する追加的な要素を含んでもよい。
ビルディング・ブロック・ボタン215のタイプには、インスツルメント、定数、算術演算子、論理演算子、演算子の優先順位、if−then−else構成および変数が含まれる。インスツルメントのビルディング・ブロック・ボタンは、選択されたインスツルメントの、例えば買い呼び値および売り数量等の属性を指定する。定値のビルディング・ブロック・ボタンは、例えば、一定の数値およびブール値を指定する。算術演算子のビルディング・ブロック・ボタンは、加算(「+」)、減算(「−」)、乗算(「*」)および除算(「/」)等の算術演算を含む。さらに、算術演算子のビルディング・ブロック・ボタンは、(「+/−」)等の注文側固有の算術演算を含んでもよく、これは、買い注文に関しては加算でありかつ売り注文に関しては減算である(または、ユーザが指定するように、売り注文に対しては加算でありかつ買い注文に関しては減算である)。論理演算子のビルディング・ブロック・ボタンは、例えば、AND、ORおよびNOT等の論理演算、および、大なり(「>」)、小なり(「<」)、以上(「>=」)、以下(「<=」)および等号(「=」)等の比較を含む。さらに、論理演算子のビルディング・ブロック・ボタンは、「>/<」等の注文側固有の論理演算を含んでもよく、これは、買い注文に関しては大なりでありかつ売り注文に関しては小なりである(または、ユーザが指定するように、売り注文に対しては大なりでありかつ買い注文に関しては小なりである)。演算子の優先順位のビルディング・ブロック・ボタンは、括弧(「(」および「)」)を含む。所定の実施形態において、演算子の優先順位のビルディング・ブロック・ボタンは、括弧内の要素から成る部分式を形成するために用いられてもよい。if−then−else構成のビルディング・ブロック・ボタンは、例えば、条件付きの値を指定することを見込んでいる。if−then−else構成のビルディング・ブロック・ボタンは、部分式が1つまたは複数の要素を用いて構築され得る部分を提供する。変数のビルディング・ブロック・ボタンは、例えば、先に論じたように、変数エリア206を用いてその値を変更している場合があるユーザ定義変数を指定する。
図2C−図2Iは、所定の実施形態による、取引インタフェース200でのアルゴリズム定義の構築を示す。
図2Cに示されているように、インスツルメントのビルディング・ブロック・ボタン231が選択され、価格エリア211にインスツルメントのビルディングブロック232として配置されている。インスツルメントのビルディングブロック232は、選択されたインスツルメントのどの属性が使用されるべきかをユーザがリスト233から選択できるようにする。インスツルメントの買い呼び値は、既に選択されている。したがって、(インスツルメントの買い呼び値として指定された)インスツルメントのビルディングブロック232を含む価格エリア211は、市場における瞬間的なインスツルメントの買い呼び値を評価する。
選択されたインスツルメントの属性の例には、買い呼び値、売り呼び値、買い数量、売り数量、最終取引価格、最終取引数量、出来高、取引セッション高値、取引セッション安値、非黙示の売/買数量(実際の売/買数量とも称される)、精算値、取引可能な最小増分(ティックサイズとも称される)およびある価格における待ち行列内の注文数(ヘッドカウントとも称される)が含まれる。さらに、例えば、「買い呼び値*」、「売り呼び値*」、「買い数量*」および「売り数量*」等の特別な注文側固有の属性も指定される場合がある(不図示)。これらの特別な属性に関して、指定された値は買い注文に使用され、かつ指定された値の反対の値は売り注文に使用される。例えば、「売り呼び値*」が選択されれば、式は買い注文の売り呼び値および売り注文の買い呼び値を評価する。
図2Dに示されているように、減算算術演算子のビルディング・ブロック・ボタン241が選択され、価格エリア211に減算のビルディングブロック242として配置されている。これで、価格エリア211内の式は、インスツルメントのビルディングブロック232と減算のビルディングブロック242とを含む。
しかしながら、価格エリア211内の式はこの時点で無効であり、よって評価はされ得ない(「買い呼び値、−」は、構文的に意味がない)。これは、先に論じたように、無効であるエリアタイプと同様に扱われてもよい。即ち、価格エリア211内の式が無効であることから、価格エリア211の背景は緑(有効な式を示す)から赤(無効な式を示す)へ変更される。
図2Eに示されているように、定数値のビルディング・ブロック・ボタン251が選択され、価格エリア211に定値のビルディングブロック252として配置されている。ユーザは、定値のビルディングブロック252が値「0.5」を有するべきであることを指定している。価格エリア211内の式は、これで再び有効となり(背景が赤から緑に変わっていることに注意)、マイナス0.5のインスツルメントの瞬間的買い呼び値を評価する。
図2Fに示されているように、if−then−else構成のビルディング・ブロック・ボタン261が選択され、数量エリア212にif−then−else構成のビルディングブロック262として配置されている。if−then−else構成のビルディングブロック262は、IF部分263と、THEN部分264と、ELSE部分265とを含む。1つまたは複数の要素(ネスト化されたif−then−else構成のビルディングブロックを含む)の部分式は、if−then−else構成のビルディングブロック262の各部分において構築されてもよい。if−then−else構成のビルディングブロック262が評価される場合、その値は次のように決定される。IF部分263が、ブール値を決定するために評価される。IF部分263からの決定されたブール値が「真」を評価すると、if−then−else構成のビルディングブロック262はTHEN部分264における式の値を評価する。IF部分263からの決定されたブール値が「偽」を評価すると、if−then−else構成のビルディングブロック262はELSE部分265における式の値を評価する。
ビルディング・ブロック・ボタン215は、if−then−else構成のビルディングブロック262の部分において式を構築するためにも用いられる。図示されているように、IF部分263は、インスツルメントの買い数量が何かより多いかどうかを決定する比較を行うために部分的に構築された式を含む。しかしながら、この式は、構文的に意味を成さないことから無効である。必然的に、これを表示するために、IF部分263の背景は赤であって緑ではないことに留意されたい。さらに、if−then−else構成のビルディングブロック262は有効でなく(そのIF部分263が有効でないため)、数量エリア212内の式は有効でなく、よってこれも赤の背景を有する。
図2Gに示されているように、if−then−else構成のビルディングブロック262は既にその部分の各々において有効な式を含み、よって、数量エリア212の式も有効である。
図2Hに示されているように、if−then−else構成のビルディングブロックはネスト化されてもよい。if−then−else構成のビルディングブロック262のELSE部分265は、別のif−then−else構成のビルディングブロック266を含む。図示されているように、if−then−else構成のビルディングブロック266は、その部分の何れにおいても式を含んでいないことから評価されることができず、よって、if−then−else構成のビルディングブロック262のELSE部分265において無効な式である。必然的に、ELSE部分265は、その式が無効であることを表示する赤い背景を有する。さらに、ELSE部分265は無効な式を有することから、if−then−else構成のビルディングブロック262は有効な式を持たず、よって数量エリア212の背景は赤である。
図2Iに示されているように、if−then−else構成のビルディングブロック262のIF部分263における式は、変数のビルディングブロック273、274、275および276を含む。変数のビルディングブロック273、274、275および276は、変数のビルディング・ブロック・ボタンを用いることによって、または定値のビルディング・ブロック・ボタンを用いる際に定値が変数でなければならないことを表示するオプションを選択することによって配置されてもよい。変数のビルディングブロック273は、変数の名称(「M_TH_1」)およびその値(「5000」)を表示している。これは、例えば、最小しきい値を表してもよい。先に論じたように、変数エリア206は各変数名およびその値を表示する。図示されているように、変数エリア206は、変数のビルディングブロック273、274、275および276毎に入力を有する名前カラム271と、変数毎に対応するデフォルト値の入力を有するデフォルト値カラム272とを含む。ユーザは、デフォルト値カラム272内のデフォルト値入力を選択して個々の変数ビルディングブロックのデフォルト値を変えることができ、よって、数量エリア212における式の評価ではその新しいデフォルト値が使用される。同様に、ユーザは、名前カラム271内の名前入力を選択して個々の変数ビルディングブロックの名前を変えることができる。変数のビルディングブロック273、274、275および276は、例えば、ユーザがアルゴリズムのパラメータとして作用する変数の値を変えることによって、根本的な論理ではなくアルゴリズムの行動を操作できるようにしてもよい。
取引インタフェース200は、ライブ評価機能を提供する。ライブ評価機能は、図2C−図2Iに示されているように、ある式の評価値の表示を提供する。ライブ評価値は、例えば、定義されているアルゴリズムとして提供されてもよい。ライブ評価値は、例えば、評価されている式に関連して表示されてもよい。評価は、式が変わる毎に、または式内のビルディングブロックの値が変わる毎に実行されてもよい。また、評価は周期的に、または絶えず実行される場合もある。所定の実施形態において、ライブ評価値は部分式に関して提供されてもよい。所定の実施形態において、ライブ評価値は、式の個々の要素に関して提供されてもよい。
図2Cに示されているように、インスツルメントの買い呼び値は、先に論じたようにインスツルメントのビルディングブロック232の属性として選択されている。価格エリア211のライブ評価281は「8.5」を表示しているが、これは、そのインスツルメントのカレント買い呼び値である(市場格子202にも示されている)。図2Dに示されているように、価格エリア211内の式は先に論じたように無効であり、よって、式を評価できないという理由でライブ評価は表示されていない。図2Eに示されているように、価格エリア211のライブ評価282は「8」を表示しているが、これは、インスツルメントの買い呼び値(8.5)から定値(0.5)をマイナスしたものである。
価格エリア211、数量エリア212および条件付きエリア213のライブ評価に加えて、これらのエリア内の式についてもライブ評価が実行されてもよい。例えば、図2Gに示されているように、ライブ評価は、if−then−else構成のビルディングブロック262の各部分について、ならびに数量エリア212自体についても提供される。IF部分263のライブ評価283は、インスツルメントの買い数量(863)が60以上であることから「真」である。THEN部分264のライブ評価284は、THEN部分264内の式が単に定値2であることから2である。同様に、ELSE部分265のライブ評価285は、ELSE部分265内の式が単に定値1であることから1である。よって、数量エリア212のライブ評価286は「2」となるが、これは、IF部分263の評価が「真」であることからif−then−else構成のビルディングブロック262の評価がTHEN部分264の値となるためである。
取引インタフェース200のビルディング・ブロック・ボタン215およびアルゴリズムエリア210は、トレーダまたは非プログラマ等のユーザがアルゴリズムの開発に要する時間およびリスクを減らすことを可能にする。これは、一部には、構文エラー(例えば、特定のプログラミング言語の複雑さに起因する)を減らす、またはなくすことによって、および構築されているアルゴリズムのライブ評価およびフィードバックを提供することによって(例えば、アルゴリズムが構築されている間にエラーをフラッグしかつ論理のデバッグを見込むことにより)達成される。
アルゴリズムは、アルゴリズムエリア210において定義されると保存されてもよい。また、アルゴリズムには(例えば、アルゴリズムの構築中および/またはアルゴリズムが保存される際に)名前が与えられてもよい。よって、保存されたアルゴリズムは、後に取引インタフェース200または別の取引インタフェースによって呼び出され、または参照されてもよい。例えば、保存されたアルゴリズムは、別の注文に関して編集または再使用され得るように取引インタフェース200によってロードされてもよい。別の例として、保存されたアルゴリズムは、後述するように別の取引インタフェースから1つの注文タイプとして参照されてもよい。
図2Jは、所定の実施形態による取引インタフェース290を示す。取引インタフェース290は、アルゴリズムがその注文用に特別に定義されている場合の、アルゴリズムによって管理される注文の開始に備えるように適合化された注文チケットである。
取引インタフェース290は、アルゴリズムエリア299と、アルゴリズム注文ボタン294と、ビルディング・ブロック・ボタン295とを含む。アルゴリズムエリア299は、価格エリア291と、数量エリア292と、条件付きエリア293とを含む。価格エリア291は、先に論じた価格エリア211に類似する。数量エリア292は、先に論じた数量エリア212に類似する。条件付きエリア293は、先に論じた条件付きエリア213に類似する。ビルディング・ブロック・ボタン295は、先に論じたビルディング・ブロック・ボタン215に類似する。
取引インタフェース290は、典型的な取引注文の実行を開始するために使用されてもよい。さらに、アルゴリズム注文ボタン294は、アルゴリズムエリア299を有効化するために選択されてもよい。有効化されると、アルゴリズム注文エリア299は、取引インタフェース200に関して先に論じた方法と同様に価格エリア291、数量エリア292および条件付きエリア293を用いてアルゴリズムを定義することに備える。アルゴリズムは、アルゴリズムエリア299において定義されかつ開始されると、取引インタフェース200に関して先に論じた方法と同様に、定義されたアルゴリズムに従って管理される。
同様に、取引インタフェース200および290におけるものに類似するアルゴリズムエリアおよびビルディング・ブロック・ボタンは、取引アプリケーションの他のコンポーネントに組み込まれる場合がある。例えば、ヘッジ・マネージャ・インタフェースは、アルゴリズムがヘッジ注文を管理するように定義されかつ指定され得るように、類似の機能を組み込むべく適合化されてもよい。
先に論じた取引インタフェース200および取引インタフェース290のコンポーネント、エレメントおよび/または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび/またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、CD−ROM、DVD、EPROMおよび/またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
III. アルゴリズム設計ラボ
所定の実施形態は、アルゴリズムを設計するための設計キャンバスエリアおよびブロックを提供する。所定の実施形態は、アルゴリズムで用いるための複雑な機能を有するブロックを提供する。所定の実施形態は、設計キャンバスエリア内に置かれる複数のブロックをグループ化することに備える。所定の実施形態は、アルゴリズムの一部の動的なインスタンス化が特定の不連続イベントを取り扱うことを可能にする仮想化されたグループブロックを準備する。所定の実施形態は、単一の取引セッションの間であってもアルゴリズムのパラメータおよび論理の双方を迅速に調整することを見込んでいる。所定の実施形態は、アルゴリズムが定義されるにつれてブロックのライブフィードバックを提供する。所定の実施形態は、アルゴリズムが設計される際の潜在的エラーを減らすための安全機能を提供する。所定の実施形態は、クライアントデバイスとアルゴリズムサーバとの接続が破断された場合のアルゴリズムの幾つかの部分または全ての部分の作動を準備する。所定の実施形態は、構文エラー、不明瞭な論理およびトレーダでないプログラマがトレーダにより指定される通りにアルゴリズムを開発する必要性等の伝統的にプログラムされるアルゴリズムのリスクを、ユーザによるプログラミングコードの書込みを減らす、またはなくすことによって低減する。所定の実施形態は、アルゴリズムの構築、デバッグおよび(実際の市場データを用いる)シミュレーションを全て同時に行うための単一のアプリケーションを提供する。さらに、この単一のアプリケーションは、アルゴリズムを用いる発注の開始にも備える場合がある。
図3Aは、所定の実施形態が使用され得る電子取引システム300を示すブロック図である。システム300は、1つまたは複数のクライアントデバイス301と、1つまたは複数のアルゴリズムサーバ302と、1つまたは複数の電子取引所303とを含む。各クライアントデバイス301は、1つまたは複数のアルゴリズムサーバ302と通信している。各アルゴリズムサーバ302は、1つまたは複数の取引所303と通信している。さらに、所定の実施形態では、図3Aには示されていないが、クライアントデバイス301が1つまたは複数の取引所303と通信していてもよい。クライアントデバイス301および/またはアルゴリズムサーバ302による取引所との通信は、例えば、先に論じたゲートウェイ120に類似するゲートウェイを介して行われてもよい。
クライアントデバイス301は、例えば、先に論じたクライアントデバイス110に類似するものであってもよい。所定の実施形態において、クライアントデバイス301はトレーダ端末と称される場合もある。取引所303は、例えば、先に論じた取引所130に類似するものであってもよい。
所定の実施形態において、アルゴリズムサーバ302は、物理的に取引所303の近くへ、または取引所303に位置決めされる。所定の実施形態において、アルゴリズムサーバ302はクライアントデバイス301の一部である。
動作に際して、電子取引のためのアルゴリズムは、クライアントデバイス301上に設計されてもよい。アルゴリズムは次に、アルゴリズムサーバ302へ伝達されてもよい。アルゴリズムサーバ302は、取引所303との電子取引を実行するためにアルゴリズムを実行する。市場データは、アルゴリズムによる使用のためにアルゴリズムサーバ302によって受信されてもよい。さらに、市場データは、アルゴリズムの設計に使用するためクライアントデバイス301によって受信されてもよい。市場データは、例えば取引所303から受信されてもよい。別の例として、市場データはシミュレータから、または格納された/履歴データから受信されてもよい。
図3Bは、所定の実施形態による取引インタフェース310を示す。取引インタフェース310は、アルゴリズム設計ラボ(「ADL」)と称されるアルゴリズム取引アプリケーションのための取引インタフェースである。ADLは、トレーダが電子取引のためのアルゴリズムを設計することを可能にする。しかしながら、図示されている取引インタフェース310のエレメントが他の取引インタフェースに組み込まれてもよいことは理解されるべきである。
取引インタフェース310は、設計キャンバスエリア311と、ブロック・リスト・エリア312と、変数エリア313と、制御エリア314とを含む。所定の実施形態において、これらのエリアのうちの1つまたはそれ以上は別々のウィンドウ内またはツールバー内にあってもよい。例えば、ブロック・リスト・エリア312は、設計キャンバスエリア311とは分離されたウィンドウ内にあってもよい。
動作中、アルゴリズムは、設計キャンバスエリア311において、ブロック・リスト・エリア312からの1つまたは複数のブロックを利用することにより定義される。アルゴリズムにおけるユーザ定義変数のデフォルト値は、変数エリア313を用いて指定されてもよい。アルゴリズムが定義されると、アルゴリズムは、制御エリア314内の制御を用いて、アルゴリズムの論理がどのように行動するかを示すようにシミュレートされてもよい。次には、取引インタフェースを用いて、定義されたアルゴリズムに従って管理されるべき注文が開始されてもよい。
設計キャンバスエリア311は、アルゴリズムを定義することに備える。設計キャンバスエリア311は、ホワイトボードエリアとも称される場合がある。設計キャンバスエリア311は、アルゴリズムを設計するための視覚的なプログラミング環境を提供する。アルゴリズムの設計には、アルゴリズムを構築し、試験し、シミュレートしかつ/または評価することが含まれる。
所定の実施形態において、設計キャンバスエリア311は取引アプリケーション310のためのインタフェースの主たる焦点であり、例えば大きな白い空間であってもよい。設計キャンバスエリア311では、ユーザの好みによってブロックが配列されてもよい。所定の実施形態において、設計キャンバスエリア311は、ブロックの配列に用いられてもよい格子線を提供する。所定の実施形態において、設計キャンバスエリア311は、多くのブロックを有する大規模アルゴリズムを介して誘導することに使用され得る総括表示またはマップを含む。所定の実施形態において、設計キャンバスエリア311は、ユーザがアルゴリズムを多少なりとも一度に見ることができるようにズームインまたはズームアウトされてもよい。
設計キャンバスエリア311においてブロックは配置され、かつアルゴリズムを定義するために接続される。配置されるべきブロックは、ブロック・リスト・エリア312から選択されてもよい。ブロックは、配置されると、配置された他のブロックへ接続されてもよい。
ブロック・リスト・エリア312は、選択されて設計キャンバスエリア311内に配置され得る1つまたは複数のブロックを含む。ブロックは、ユーザの好みによってアルゴリズムを構築するために組み合わされ得る異なる機能を表している。
概して、ブロックは入力と出力とを有する。しかしながら、所定のブロックは入力だけを有する場合があり、かつ他のブロックは出力だけを有する場合がある。例えば、ポーズブロックは入力だけを有してもよい。別の例として、数字ブロックは出力だけを有してもよい。
ブロックの入力および出力は、2つの主たるタイプ、即ち連続式または不連続式のうちの何れかである。連続タイプの入力/出力は、任意の特定の時刻において(故に、絶えず)値を有する。不連続タイプの入力/出力は、何らかの特別な時刻に発生する特有のアクション/イベントに対応して不連続のイベント(個々のメッセージ/オブジェクト)を受信/提供する。特有のアクション/イベントが発生すると、対応する不連続イベントが発生されてもよい。
この主たるタイプの入力/出力に加えて、入力/出力は特別な値のタイプを有してもよい。例えば、連続式の入力は、ブール値、数値、整数値、浮動小数点数値またはインスツルメント値という値タイプを有する場合もある。別の例として、1つのブロックが2つの連続する変数値タイプの入力を有することがあり、この場合、2つの入力の値タイプは例えばブール値または数値であってもよいが、同一タイプでなければならない。2つの入力をとり、これらが等しいかどうかを表示するブール値を出力するために比較する等号ブロックは、例えばブール値または数値またはインスツルメント値を比較すべく使用され得るように変数入力を有してもよい。別の例として、不連続出力は、約定確認の値タイプを有する場合もある。即ち、不連続出力は、約定確認の不連続イベントを提供する場合もある。別の例として、不連続出力は、注文要求確認(注文が出されたことを表示する)、約定確認(注文が約定された、または部分的に約定されたことを表示する)、注文変更確認(価格または数量等の受付中の注文パラメータが変更されたことを表示する)、注文削除確認(受付中の注文が削除またはキャンセルされたことを表示する)または取引確認(取引が発生していることを表示する)等のアクションに関して、2つ以上のタイプの不連続イベントを提供する場合もある。別の例として、不連続イベントは、単にイベントが発生していることを示して空である場合もある。空の不連続イベントは、例えばタイマ、ブール値の変更によってトリガされてもよく、または、特定の時間(時刻または例えば所定の市場条件が満たされたとき等)にアルゴリズムの一部を起動するために用いられてもよい。ある特別なタイプの不連続イベントは、別のタイプの不連続イベントとは異なる情報を含んでもよい。例えば、注文確認は、注文識別子および/またはインスツルメント等の情報を含んでもよい。別の例として、約定確認の不連続イベントは、注文識別子、価格、数量、インスツルメントおよび/または約定時刻等の情報を含んでもよい。別の例として、注文削除確認は、注文識別子、インスツルメントおよび/または削除時刻を含んでもよい。別の例として、空の不連続イベントは如何なる情報も含まなくてもよい(または、イベントの発生時刻のみを含むことがある)。不連続イベントは、ユーザが定義する情報を含んでもよい。例えば、インスツルメントAに関する約定された注文の約定確認の不連続イベントは、インスツルメントAの約定時におけるインスツルメントBの買い呼び値等のユーザが定義する市場情報を含んでもよい。
所定の実施形態において、ブロックは、その入力/出力の主たるタイプのインジケータを含む。例えば、連続式の入力/出力は、特別な背景色、前景色、背景パターン、境界色、境界スタイル、形状、記号、数字、テキストおよび/またはフォントによって表示されてもよく、不連続式の入力/出力は、別の色、パターン、境界、形状、記号、数字、テキストおよび/またはフォントによって表示される場合もある。
所定の実施形態において、ブロックは、その入力/出力の値タイプのインジケータを含む。例えば、特別な値タイプを有する入力/出力は、特別な背景色、前景色、背景パターン、境界色、境界スタイル、形状、記号、数字、テキストおよび/またはフォントによって表示されてもよく、異なる値タイプを有する入力/出力は、別の色、パターン、境界、形状、記号、数字、テキストおよび/またはフォントによって表示されてもよい。
所定の実施形態では、カーソルがそのブロックの近くへ位置合わせされると、主たるタイプの、かつ/または値タイプの入力または出力がポップアップウィンドウに表示される。所定の実施形態では、カーソルがそのブロックの近くへ位置合わせされると、ブロックの設定に関する情報がポップアップ・ウィンドウに表示される。
ブロックは、異なる機能を表現している。取引インタフェース310において、ブロックは4つの一般機能カテゴリ、即ち基本ブロック、取引ブロック、不連続ブロックおよびその他のブロックに分けられている。しかしながら、これらのグループ分けは編成およびユーザによる利用の便宜を図るためのものであって、ブロックはグループ化される必要はなく、ブロックのグループも特別な機能を必要としない。ブロックの中には、適宜2つ以上のカテゴリに当て嵌まるものもあり、またブロックの他の編成またはグルーピングが使用される場合もある。
基本ブロックは、概して連続式の入力および出力を有し、かつ算術演算(例えば、加算、減算、乗算および除算)、論理演算(例えば、AND、ORおよび等号、大なりおよび小なり等の比較)、定値(例えば、数値およびブール値)およびif−then−else構成を提供する。
取引ブロックは、概して、注文操作(例えば、発注、既存の注文の修正または注文の削除)に関して、または注文関連情報(例えば、約定確認)に関して、より複雑な機能を提供する。取引ブロックは、連続式および不連続式双方の入力および出力を有してもよい。例えば、マーケットメーカ・ブロックは、インスツルメント、価格、数量および注文に値付けをするための条件を指定するための連続式入力を有してもよく、かつ受付中の数量の連続式出力および約定通知を提供するための不連続出力を有してもよい。取引ブロックは、プログラマでない者(トレーダ等)を含むユーザが、取引アルゴリズムを生成して配備するために視覚的設計環境(ADLにより提供されるもの等)を利用できるようにする。取引ブロックは、より少ないステップを有する典型的なプログラマよりも高速かつ正確な設計のアルゴリズム、または他の視覚的プログラミングプラットフォームよりも高速かつ正確な設計の命令を見込むものであってもよい。
不連続ブロックは、概して不連続な入力および出力を有し、かつ不連続イベントの発生に基づいてオペレーションを提供する。例えば、ジェネレータブロックは、不連続イベントの発生を生成してもよい。別の例として、値抽出器ブロックは不連続イベントから値を抽出し、かつこれを連続値としてアルゴリズムの別の部分が利用できるようにしてもよい。別の例として、シーケンサブロックは、不連続イベントに応答して連続ブロックが処理されるシーケンスを制御するために用いられてもよい。所定の不連続ブロックは、後続時に参照されるべきデータを格納してもよい。例えば、値積算器ブロックは不連続イベントを受信し、かつこれからユーザ指定の値を抽出してもよい。抽出される値は、受信された各不連続イベントから抽出された値と共に累積されてもよい。
その他のブロックは、必ずしも上述のカテゴリに当て嵌まらない場合がある様々な機能を提供する。例えば、これらのブロックは専用の、またはより複雑な計算を提供する場合もあれば、アルゴリズム自体の実行に追加的制御を加える場合もある。さらに、その他のブロックは、リスクを制御し、数値を取引可能な値に変換し、または時間(精確な時刻であれ経過時間であれ)を入力または変数として用いるためのより精確なツールを提供してもよい。
図3Cは、所定の実施形態による、取引インタフェース310において用いられてもよいブロック320の例を示す。図中には、先に同定された各カテゴリからのブロック例が示されている。基本ブロック例は、加算ブロック321と、if−then−elseブロック322とを含む。取引ブロック例は、マーケットメーカ・ブロック323と、条件付き売り/買いブロック324と、注文ハンドラブロック325とを含む。不連続ブロック例は、値抽出器ブロック326と、ブランチブロック327とを含む。その他のブロック例は、注記ブロック328と、ポーズブロック329とを含む。以下、これらのブロックの各々、並びに所定の実施形態に包含され得る他のブロック例についてさらに詳しく論じる。
基本ブロックは、例えば、加算、減算、乗算、除算、大なり、小なり、以上、以下、AND、OR、等号、IF−THEN−ELSE、数字、ブールおよび定数の各ブロックを含んでもよい。
加算ブロックは、2つの連続式数値入力を合算して連続する1つの数値出力を生成してもよい。加算ブロックは、真ん中にプラス記号(「+」)、左側に2つの連続式入力および右側に1つの連続式出力を備える三角形状を有してもよい。加算ブロックは、加算器ブロックと称される場合もある。
減算ブロックは、1つの連続式数値入力(例えば、ボトム入力)を第2の連続式数値入力(例えば、トップ入力)から減算して1つの連続式数値出力を生成してもよい。減算ブロックは、真ん中にマイナス記号(「−」)、左側に2つの連続式入力および右側に1つの連続式出力を備える三角形状を有してもよい。
乗算ブロックは、2つの連続式数値入力を乗算して連続する1つの数値出力を生成してもよい。乗算ブロックは、真ん中に乗算記号(「X」または「*」)、左側に2つの連続式入力および右側に1つの連続式出力を備える三角形状を有してもよい。
除算ブロックは、1つの連続式数値入力(例えば、トップ入力)を第2の連続する入力(例えば、ボトム入力)で除算して1つの連続式数値出力を生成してもよい。除算ブロックは、真ん中に除算記号(「/」または「÷」)、左側に2つの連続式入力および右側に1つの連続式出力を備える三角形状を有してもよい。
大なりブロックは、2つの連続式数値入力を比較して、一方の入力(例えば、トップ入力)が第2の入力(例えば、ボトム入力)より大きいかどうかを決定してもよい。出力は、第1の入力が第2の入力より大きければ連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。大なりブロックは、真ん中に大なり記号(「>」)、左側に2つの連続式数値入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
小なりブロックは、2つの連続式数値入力を比較して、一方の入力(例えば、トップ入力)が第2の入力(例えば、ボトム入力)より小さいかどうかを決定してもよい。出力は、第1の入力が第2の入力より小さければ連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。小なりブロックは、真ん中に小なり記号(「<」)、左側に2つの連続式数値入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
以上ブロックは、2つの連続式数値入力を比較して、一方の入力(例えば、トップ入力)が第2の入力(例えば、ボトム入力)以上であるかどうかを決定してもよい。出力は、第1の入力が第2の入力以上であれば連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。以上ブロックは、真ん中に以上記号(「>=」または「>−」)、左側に2つの連続式数値入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
以下ブロックは、2つの連続式数値入力を比較して、一方の入力(例えば、トップ入力)が第2の入力(例えば、ボトム入力)以下であるかどうかを決定してもよい。出力は、第1の入力が第2の入力以下であれば連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。以下ブロックは、真ん中に以下記号(「<=」または「<−」)、左側に2つの連続式数値入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
ANDブロックは、第1の入力(例えば、トップ入力)が「真」でありかつ第2の入力(例えば、ボトム入力)が「真」であればブール出力が「真」であるように、2つの連続式ブール入力の論理積を実行してもよい。入力の何れかが「偽」であれば、出力値は「偽」である。ANDブロックは、真ん中にテキスト「AND」、左側に2つの連続式ブール入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
ORブロックは、入力の何れかが「真」であればブール出力は「真」であるように、2つの連続式ブール入力の論理和を実行してもよい。両方の入力が「偽」であれば、出力値は「偽」である。ORブロックは、真ん中にテキスト(OR)、左側に2つの連続式ブール入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
等号ブロックは、2つの連続する入力を比較して、一方の入力(例えば、トップ入力)が第2の入力(例えば、ボトム入力)に等しいかどうかを決定してもよい。入力は、各入力が同じタイプである限り、等式ブロックが数字、ブールまたはインスツルメント等の値を受け入れてもよいように、変数値タイプであってもよい。出力は、2つの入力が等しければ連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。等号ブロックは、真ん中に等号(「=」)、左側に2つの連続する変数入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。等号ブロックは、等式ブロックと称される場合もある。
IF−THEN−ELSEブロックは3つの連続式入力、即ち、ブールIF入力、変数THEN入力および変数ELSE入力を有してもよい。IF−THEN−ELSEブロックは、1つの連続式変数出力を有する。IF入力値が「真」であれば、出力はTHEN入力の値である。IF入力値が「偽」であれば、出力はELSE入力の値である。IF−THEN−ELSEブロックは、真ん中に「?」記号、左側に1つの連続式ブールIF入力および2つの連続式変数ELSE入力およびTHEN入力および右側に1つの連続式変数出力を備える矩形形状を有してもよい。
数字ブロックは、ユーザによって指定された数値を提供する1つの連続式数値出力を有してもよい。配置されると、ユーザは、数字ブロックに数値を入力するようにプロンプトされてもよい。あるいは、数字ブロックは、1等の既定値へデフォルトしてもよい。さらに、値は、注文チケット数量または注文チケット価格に指定されてもよい。そうであれば、数字ブロックの値は、注文がアルゴリズムを用いて管理されるように開始される際に指定される個々の値となる。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、数字ブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、数字ブロックが可変であるように指定されていれば、後述する変数エリア313を用いて変更されてもよい。数字ブロックは、真ん中に指定された数字、および右側に1つの連続式数値出力を備える円形状を有してもよい。このブロックは、定数ブロックと称される場合もある。
ブールブロックは、ユーザによって指定されたブール値を提供する1つの連続式ブール出力を有してもよい。配置されると、ユーザは、ブールブロックにブール値を入力するようにプロンプトされてもよい。あるいは、ブールブロックは、「真」等の既定値へデフォルトしてもよい。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、ブールブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、ブールブロックが可変であるように指定されていれば、後述する変数エリア313を用いて変更されてもよい。ブールブロックは、真ん中に指定されたブール値がテキスト表示されかつ右側に1つの連続式ブール出力を備える円形状を有してもよい。このブロックは、定数ブールブロックと称される場合もある。
所定の実施形態において、数字ブロックおよびブールブロックは、定数ブロック等の単一ブロックに合併されてもよい。定数ブロックは、ユーザによって指定された数値を提供する1つの連続式変数出力を有してもよい。配置されると、ユーザは、定値ブロックに値タイプおよび値を入力するようにプロンプトされてもよい。
あるいは、定数ブロックは、数字等の既定値タイプおよび1等の既定値へデフォルトしてもよい。さらに、値は、注文チケット数量または注文チケット価格に指定されてもよい。そうであれば、定数ブロックの値は、注文がアルゴリズムを用いて管理されるように開始される際に指定される個々の値となる。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、定数ブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、定数ブロックが可変であるように指定されていれば、後述する変数エリア313を用いて変更されてもよい。定数ブロックは、真ん中に指定された値がテキスト表示されかつ右側に1つの連続式変数出力を備える円形状を有してもよい。所定の実施形態において、定数ブロックは、後述するインスツルメントブロックと同様に、インスツルメントを値に指定することもサポートする場合がある。
取引ブロックは、例えば、インスツルメント、インスツルメント属性、マーケットメーカ、レガー、カスタムスプレッド、レスポンシブ売/買、条件付き売/買、注文ハンドラ、IF−THEN−ELSEインスツルメント、価格時インスツルメント属性、値幅、取引、注文、約定計算機および約定積算器の各ブロックを含んでもよい。
インスツルメントブロックは、インスツルメント名を提供する1つの連続式インスツルメント出力を有してもよい。インスツルメント名は、例えば、取引所がリストするインスツルメントであっても、合成インスツルメントであってもよい。配置されると、ユーザは、インスツルメントブロックにそのインスツルメント名を指定するようにプロンプトされてもよい。インスツルメント名は、例えば、リストから選択されてもよい。あるいは、インスツルメントブロックは既定値へデフォルトしてもよい。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、インスツルメントブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、インスツルメントブロックが可変であるように指定されていれば、変数エリア313を用いて変更されてもよい。
インスツルメント属性ブロックは、連続式インスツルメント入力と、連続式数値出力とを有してもよい。インスツルメント属性ブロックは、インスツルメント名を採用しかつそのインスツルメントの指定される属性に値を出力してもよい。属性には、最良の買い数量、最良の買い呼び値、最良の売り数量、最良の売り呼び値、出来高、セッション高値、セッション安値、取引可能な最小増分、最終取引価格、最終取引数量、合計数量(新価格で取引が発生するまでの最終取引価格で取引された合計数量)、先行取引セッションからの精算値、実際の(非黙示)最良の買い数量、実際の(非黙示)最良の売り数量、買いヘッドカウント(最良の買い呼び値での市場における注文数)、売りヘッドカウント(最良の売り呼び値での市場における注文数)またはポジション(特別なインスツルメントにおけるユーザの総合インベンタ)が含まれてもよい。配置されると、ユーザは、インスツルメント属性ブロックによって提供されるべき属性を入力するようにプロンプトされてもよい。あるいは、インスツルメント属性ブロックは、買い数量等の既定値へデフォルトしてもよい。指定された属性は、アルゴリズムを設計する間に、ユーザにより、例えば、インスツルメント属性ブロックを選択しかつ属性を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された属性は、インスツルメント属性ブロックが可変であるように指定されていれば、後述する変数エリア313を用いて変更されてもよい。
マーケットメーカ・ブロックは、条件連続式ブール入力が「真」である場合、連続式インスツルメント入力により指定される取引可能オブジェクトの売り注文または買い注文を2つの連続式数値入力により指定される価格および数量で提出してもよい。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。マーケットメーカ・ブロックは、条件入力が「偽」である場合に注文を削除してもよい。マーケットメーカ・ブロックは、個々の価格および数量入力値が変われば、既存の注文の価格または数量を修正する場合もある。数量入力に指定される値は、先行する約定を考慮した希望される最大約定数量を表す。例えば、数量入力値5が与えられれば、マーケットに注文5が入力されてもよく、かつ数量3が約定されれば、価格入力が変わっても注文2は機能され続けることになる。数量入力が変われば、機能される注文は、指定される新規数量から既に約定された数量3を減じたものとなる。マーケットメーカ・ブロックは、約定確認および/または注文要求の不連続イベントを提供する1つまたは複数の不連続出力を提供してもよい。マーケットメーカ・ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、マーケットメーカ・ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。この機能は、例えば、アルゴリズムのヘッジ部分に有益である場合がある。マーケットメーカ・ブロックは、マーケットメーカ・ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、(例えば、注文が注文帳に留まるものとは予想されていない場合でも)不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、マーケットメーカ・ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、マーケットメーカ・ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。
レガーブロックは、カスタムスプレッドのレッグの取引可能オブジェクトに関して買い注文または売り注文を提出してもよく、この場合、各レッグの取引可能オブジェクトは連続式インスツルメント入力によって指定される。カスタムスプレッドに希望される価格および数量は、2つの連続式数値入力によって指定される。レガーブロックは、条件連続式ブール入力が「真」である場合に、スプレッドの個々の注文を起こす。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。レガーブロックは、条件入力が「偽」である場合に注文を削除してもよい。レガーブロックは、価格および/または数量入力値が変われば、受付中の注文の価格および/または数量を修正する場合もある。数量入力に指定される値は、先行する約定を考慮したスプレッドの希望される最大約定数量を表す。例えば、数量入力値5が与えられれば、マーケットに注文5が入力されてもよく、かつ数量3が約定されれば、価格入力が変わっても注文2は機能され続けることになる。数量入力が変われば、機能される注文は、指定される新規数量から既に約定された数量3を減じたものとなる。レガーブロックは、スプレッド約定、注文要求および/またはレッグ約定の不連続イベントを提供する1つまたは複数の不連続出力を提供してもよい。スプレッドのレッグに関してインスツルメントが提供された後、レガーは、例えば、レガーブロックを選択しかつパラメータおよび設定値を指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって設定されてもよい。スプレッドの各レッグに指定され得るパラメータには、「倍数」(スプレッドレッグの係数)、「取引数量」(スプレッドの各レッグの数量、但し、正数は買いであり、負数は売りである)、「マーケットを働かせる?」(スプレッドのレッグが能動的に値付けをするかどうかトグルする)、「純変動」(カスタムスプレッド計算を価格ではなく純変動に変換するかどうかトグルする)、「ペイアップ・ティック」(カスタムスプレッドがリーンなレッグにリミット注文を入力する際の最小価格増分数、正数は成約に対してより積極的であることを意味し、負数は成約に対してあまり積極的でないことを意味する)および「リーンなレシオ」(呼び値のレッグに1数量単位を働かせるべくリーンなレッグ上に存在するために要求される数量単位、これは、例えば、2つのレッグ間の数量比である場合も、リーンなレッグにおけるしきい値数量である場合もある)が含まれる。指定され得る設定値には、「サイド」(カスタムスプレッドの買い手または売り手)、「常時場内市場を働かせる」(真であればレガーブロックは単に最良または場内市場に現出する個々のレッグ注文を働かせることと、所定の実施形態において、単に市場売/買サイズレシオを見て決定される通りに成約される可能性が高いレッグを働かせることをトグルする)、「「スナイピング」モードを無効化する」(レガーブロックは、希望されるスプレッド価格を達成することができれば、受付中のカレント注文を削除すると同時に、全てのレッグについて希望スプレッド価格で成約するように注文を出すデフォルト行動をトグルする。無効化されると、レガーブロックは、希望価格が瞬間的に利用可能となっても指定された「マーケットを働かせる?」レッグしか働かせない)、「クリップサイズ」(合計数量が規定されたスプレッド数量入力によって定義された通りに満たされるまで繰返し増大する、一度に機能されるべき数量)および「フラグ」(識別をより容易にするために、スプレッド約定の不連続イベントに関連づけられるユーザ定義のフラグを指定する)が含まれる。レガーブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、レガーブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。レガーブロックは、レガーブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、(例えば、注文が注文帳に留まるものとは予想されていない場合でも)不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、レガーブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、レガーブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。このブロックは、オートスプレッドブロックまたはスプレッダブロックと称される場合もある。
カスタムスプレッド・ブロックは、カスタムスプレッドのレッグの取引可能オブジェクトに関して買い注文または売り注文を提出してもよく、この場合、カスタムスプレッドは外部アプリケーションからのインスツルメントとして提供される。カスタムスプレッドに希望される価格および数量は、2つの連続式数値入力によって指定される。カスタムスプレッド・ブロックは、条件連続式ブール入力が「真」である場合に、スプレッドの個々の注文を起こす。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。カスタムスプレッド・ブロックは、条件入力が「偽」である場合に注文を削除してもよい。カスタムスプレッド・ブロックは、価格および/または数量入力値が変われば、受付中の注文の価格および/または数量を修正する場合もある。数量入力に指定される値は、先行する約定を考慮したスプレッドの希望される最大約定数量を表す。例えば、数量入力値5が与えられ、数量3が約定されれば、価格入力が変わっても注文2は機能され続けることになる。数量入力が変われば、機能される注文は、指定される新規数量から既に約定された数量3を減じたものとなる。カスタムスプレッド・ブロックは、オリジナルの注文数量をヘッジ・レッグに提示するように要求する代わりに、個々の注文のレッグの注文数量のダイナミックサイジングを有効化するためのブール入力をオプションとして含んでもよい。カスタムスプレッド・ブロックは、約定確認および/または注文要求の不連続イベントを提供する1つまたは複数の不連続出力を提供してもよい。配置されると、ユーザは、外部アプリケーションからカスタム設計インスツルメントを指定するようにプロンプトされてもよく、この場合、カスタム設計インスツルメントは、取引戦略を表現する合成市場データを提供する。あるいは、指定されるカスタム設計インスツルメントは、アルゴリズムを設計する間に、ユーザにより、例えば、カスタムスプレッド・ブロックを選択しかつ外部アプリケーションからカスタム設計インスツルメントを指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって指定され、かつ/または変更されてもよい。
さらに、アルゴリズムを設計する間、ユーザは、「「スナイピング」モードを無効化する」(カスタムスプレッド・ブロックは、希望されるスプレッド価格を達成することができれば、受付中のカレント注文を削除すると同時に、全てのレッグについて希望スプレッド価格で成約するように注文を出すデフォルト行動をトグルする。無効化されると、カスタムスプレッド・ブロックは、希望価格が瞬間的に利用可能となっても指定された呼び値のレッグしか働かせない)、および「クリップサイズ」(合計数量が規定されたスプレッド数量入力によって定義された通りに満たされるまで繰返し増大する、一度に機能されるべき数量)を含む場合のある設定値を指定してもよい。カスタムスプレッド・ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、カスタムスプレッド・ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。カスタムスプレッド・ブロックは、カスタムスプレッド・ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、(例えば、注文が注文帳に留まるものとは予想されていない場合でも)不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、カスタムスプレッド・ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、カスタムスプレッド・ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。所定の実施形態において、カスタムスプレッド・ブロックは、外部アプリケーションからの指定されたカスタム設計インスツルメントを連続式インスツルメント出力として提供してもよい。所定の実施形態において、カスタムスプレッド・ブロックは、外部アプリケーションからの指定された数値またはブール値を連続式数値またはブール出力として提供してもよい。このブロックは、カスタム戦略ブロックまたはカスタム外部アプリケーションブロックと称される場合もある。
レスポンシブ売/買ブロックは、不連続入力で不連続イベントが受信されると、連続式インスツルメント入力により指定されたインスツルメントの買い注文または売り注文の提出を開始してもよい。発注価格および/または数量は、連続式数値入力によって提供されてもよい。あるいは、価格および/または数量は、使用されるべき個々の価格または数量値を決定すべく評価されるユーザ定義の方程式によって指定されてもよい。所定の実施形態において、価格および数量の一方は連続式数値入力によって提供されてもよく、もう一方はユーザ定義の方程式を評価することによって提供されてもよい。指定された価格および/または数量の方程式(使用されれば)は、アルゴリズムを設計する間に、ユーザにより、例えば、レスポンシブ売/買ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。レスポンシブ売/買ブロックが一旦発注を開始すると、注文は、提供される価格および/または数量値のその後の変化に基づいて更新されない。レスポンシブ売/買ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、レスポンシブ売/買ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。レスポンシブ売/買ブロックは、レスポンシブ売/買ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、(例えば、注文が注文帳に留まるものとは予想されていない場合でも)不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、レスポンシブ売/買ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、レスポンシブ売/買ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。
条件付き売/買ブロックは、条件連続式ブール入力が「真」である場合、連続式インスツルメント入力により指定されるインスツルメントの売り注文または買い注文の発注を2つの連続式数値入力により指定される価格および数量で開始してもよい。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。条件付き売/買ブロックは、条件入力値が「偽」である場合でも注文を削除しない(但し、発注は、条件入力が「真」になるまで開始されない)。条件付き売/買ブロックは、一度に1つの注文だけを提出してもよい。所定の実施形態において、条件付き売/買ブロックは、注文が(例えば、アルゴリズムにおける別のブロックによって、またはユーザにより手動で)削除される場合でも、提供された当初の数量値を達成しようと注文(一度に1つの注文)を提出し続ける。条件付き売/買ブロックが一旦発注を開始すると、注文は、提供される価格および/または数量値のその後の変化に基づいて更新されない。条件付き売/買ブロックは、約定確認および/または注文要求の不連続イベントを提供する1つまたは複数の不連続出力を提供してもよい。条件付き売/買ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、条件付き売/買ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。条件付き売/買ブロックは、条件付き売/買ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、(例えば、注文が注文帳に留まるものとは予想されていない場合でも)不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、条件付き売/買ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、条件付き売/買ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。
注文ハンドラブロックは、不連続入力において注文イベントを受信し、かつ2つの連続式数値入力によって提供される価格および数量値を基礎として対応する注文を管理してもよい。連続式ブール入力において提供される値が「真」であれば、注文は削除される。注文ハンドラブロックは、約定確認、削除確認および/または変更確認の不連続イベントを提供する1つまたは複数の不連続出力を提供してもよい。注文ハンドラブロックは、受付中の数量および/または約定された数量を連続式数値出力へ提供してもよい。注文ハンドラブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、注文ハンドラブロックによって管理される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。
IF−THEN−ELSEインスツルメントブロックは3つの連続式入力、即ち、ブールIF入力、インスツルメントTHEN入力およびインスツルメントELSE入力を有してもよい。IF−THEN−ELSEインスツルメントブロックは、1つの連続式インスツルメント出力を有する。IF入力値が「真」であれば、出力はTHEN入力のインスツルメント値である。IF入力値が「偽」であれば、出力はELSE入力のインスツルメント値である。IF−THEN−ELSEインスツルメントブロックは、真ん中に「?」記号、左側に1つの連続式ブールIF入力および2つの連続式インスツルメントELSE入力およびTHEN入力および右側に1つの連続式インスツルメント出力を備える矩形形状を有してもよい。IF−THEN−ELSEインスツルメントブロックは、先に論じたIF−THEN−ELSEブロックに類似するが、インスツルメント値に特化されている。
価格時インスツルメント属性ブロックは、連続式インスツルメント入力と、連続式数値入力と、連続式数値出力とを有してもよい。価格時インスツルメント属性ブロックは、インスツルメント名(連続式インスツルメント入力によって提供される)および価格(連続式数値入力によって提供される)を採用しかつ指定価格におけるそのインスツルメントの指定される属性に値を出力してもよい。属性には、買い数量、売り数量、実際の(非黙示)買い数量、実際の(非黙示)売り数量、買いヘッドカウント(指定価格での市場における買い注文数)および売りヘッドカウント(指定価格での市場における売り注文数)が含まれてもよい。配置されると、ユーザは、価格時インスツルメント属性ブロックによって提供されるべき属性を入力するようにプロンプトされてもよい。あるいは、価格時インスツルメント属性ブロックは、買い数量等の既定値へデフォルトしてもよい。指定された属性は、アルゴリズムを設計する間に、ユーザにより、例えば、価格時インスツルメント属性ブロックを選択しかつ属性を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された属性は、価格時インスツルメント属性ブロックが可変であるように指定されていれば、後述する変数エリア313を用いて変更されてもよい。
値幅ブロックは、2つの連続式インスツルメント入力と、1つの連続式インスツルメント出力とを有してもよい。値幅ブロックは、2つのインスツルメント名(例えば、一方は「フロントレッグ」入力から、他方は「バックレッグ」入力から)を採用し、かつ提供される2つのインスツルメントの取引所がリストするスプレッドに対応するインスツルメント名(例えば、「フロントレッグ−バックレッグ」)を出力してもよい。例えば、値幅ブロックは、「CLZ0」(2010年12月原油)および「CLF1」(2011年1月原油)等の異なる2つのインスツルメント間のスプレッドを参照するために用いられてもよい。これらの「レッグ」は各々、「フロントレッグ」および「バックレッグ」と称される場合がある。値幅ブロックの対応する出力は取引所がリストするスプレッドインスツルメントであり、本例では、取引所がリストするインスツルメント「CLZ0−CLF1」(2010年12月−2011年1月のスプレッド市場)である。このブロックは、インスツルメント間のスプレッドを正しく参照するプロセスのエラーを減らすべくプログラミングの安全性を高めるために用いられてもよい。例えば、入力される2つのインスツルメントは、アルゴリズムの実行中に変更が可能な変数、またはアルゴリズムによって管理されている異なる注文に対しては取引所がリストする異なるスプレッドであるように指定されることが可能な変数として表示されてもよい。値幅ブロックは、第3の変数を個々の2つのインスツルメント変数に整合するように設定または変更する必要なしに、リストされた「正しい」スプレッドインスツルメントを発見することによって安全を提供する。また、値幅ブロックは、取引所がリストする所定のスプレッドの存在を位置決めする、または探索するために用いられる場合もある。
取引ブロックは、連続式インスツルメント入力に提供されるインスツルメントに関して、不連続イベント出力に不連続イベントにおける取引データを提供してもよい。不連続イベントは、各取引に関連づけられる取引価格値および取引数量値を含む。取引データは、例えば、取引所から受信されてもよい。取引価格および取引数量は、不連続イベントから、例えば値抽出器ブロック、値積算器ブロック、不連続最小ブロックおよび/または不連続最大ブロックによって抽出されてもよい。
注文ブロックは、既存の注文(即ち、アルゴリズムの外部で既に発注されていて、しかも別のアルゴリズムによって管理されていない注文)を定義されたアルゴリズムに従って管理することができるようにする場合がある。例えば、注文ブロックは、ユーザによって手動で発注されている注文を制限する特定タイプのオートヘッジ・ルーチンを提供するために用いられてもよい。注文ブロックは、既存の注文に関連するインスツルメントの連続式インスツルメント出力、および既存の注文の数量、価格および実行された数量に関する連続式数値出力を提供する。また、注文ブロックは、注文に関連する約定確認等の注文不連続イベントに関して不連続出力も提供する。所定の実施形態では、定義されたアルゴリズムが注文ブロックを含んでいれば、このアルゴリズムは、例えば注文ウィンドウを含む取引インタフェースにおいて、既存の注文へ適用されるべき利用可能アルゴリズムのリスト内に提示されてもよい。別の例として、アルゴリズムが注文ブロック自体において実行される、または指定される場合には、注文識別子がアルゴリズムへ変数として提供されてもよい。既存の注文へ適用される場合、注文ブロックを含む定義されたアルゴリズムは、その注文をそのアルゴリズムに従って管理してもよい。
約定計算機ブロックは、スプレッド約定の不連続イベントに関する不連続出力を提供してもよい。約定計算機ブロックは、アルゴリズムがカスタムスプレッドを、レガーブロックまたはカスタムスプレッド・ブロックを用いることなく買う/売る場合に用いられてもよい。約定計算機ブロックは、スプレッドの各取引実行(約定)レッグに関して複数の連続式インスツルメント入力と1つの不連続入力とを受信するが、前者はレッグのインスツルメントを提供しかつ後者は約定確認の不連続イベントを提供する。スプレッドのレッグに関してインスツルメントが提供された後、約定計算機ブロックは、例えば、約定計算機ブロックを選択しかつパラメータおよび設定値を指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって設定されてもよい。スプレッドの各レッグに指定され得るパラメータには、「倍数」(スプレッドレッグの係数)、「取引数量」(スプレッドの各レッグの数量、但し、正数は買いであり、負数は売りである)および「純変動」(カスタムスプレッド計算を価格ではなく純変動に変換するかどうかトグルする)が含まれる。指定され得る設定値には、「サイド」(約定計算機のカスタムスプレッドの買い手または売り手)および「フラグ」(識別をより容易にするために、スプレッド約定の不連続イベントに関連づけられるユーザ定義のフラグを指定する)が含まれる。
積算器ブロックは、不連続入力において注文または約定の不連続イベントを受信し、かつ受信された不連続イベントの積算された数量を連続式数値出力に提供してもよい。例えば、積算器ブロックがマーケットメーカ・ブロックへ接続されていれば、積算器ブロックは、マーケットメーカ・ブロックから受信される部分的約定の不連続イベント毎にその連続式数値出力の値を増してもよい。このブロックは、例えば、約定総数を追跡するために用いられてもよい。積算器ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。積算器ブロックは、イベントを受信すると積算数量を0へリセットするリセット不連続入力を含んでもよい。積算器ブロックは、後述する値積算器ブロックに類似するものであってもよいが、約定された数量のみを積算することから、より限定的な機能を有する。
不連続ブロックには、例えば、発生器、値抽出器、値積算器、値バケット、不連続移動平均、状態、ブランチ、マルチプレクサ、ファンネル、シーケンサ、不連続最小ブロックおよび不連続最大ブロックの各ブロックが含まれてもよい。
発生器ブロックは、条件が「真」であればいつも不連続出力に不連続イベントを提供してもよい。条件は、条件入力が「真」になる度にイベントが発生されるように、連続式ブール入力によって提供されてもよい。あるいは、条件は、「開始時」(条件は、アルゴリズムの開始時には「真」であってその後は「偽」であり、よって、アルゴリズムの開始時に単一の不連続イベントが提供される)、「変更時」(条件は、連続式ブール入力値が変わるとき常に「真」であり、よって、「真」から「偽」へ、または「偽」から「真」への移行の双方が不連続イベントを発生させる)、「毎X」(条件は、指定された時間間隔毎に一度「真」となり、前記間隔は分、秒またはミリ秒単位で指定されてもよい)等のイベントであるように指定されてもよい。
値抽出器ブロックは、不連続入力で不連続イベントを受信し、かつそのイベントからユーザ指定の値を抽出してもよい。あるいは、値抽出器ブロックは、不連続イベントが受信されると、抽出される値を決定するためにユーザ定義の方程式を評価してもよい。抽出された値は、次に、連続式出力へ提供されてもよい。出力の値タイプは、抽出された値のタイプに依存する。不連続イベントから抽出されるべき値を指定する際には、下記の式:「インスツルメント」(不連続イベントに関連づけられるインスツルメントを提供する)、「約定価格」(不連続イベントに関連づけられる約定価格を提供する)、「約定数量」(不連続イベントに関連づけられる約定数量を提供する)、「注文数量」(不連続イベントに関連づけられる注文数量を提供する)、「注文価格」(不連続イベントに関連づけられる注文価格を提供する)、「実行数量」(注文数量に関連する約定の累算を提供する)、「受付中の数量」(特定の注文価格における実行されない注文数量の累算を提供する)、「取引数量」(ある取引所で実行される取引の数量を提供する)、「取引価格」(ある取引所で実行される取引の価格を提供する)および「変数」(指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する)を利用可能である。所定の実施形態において、値抽出器ブロックは、別のブロックの出力からの値を参照してもよい。値は、例えば、先に論じた式「変数」を用いて参照されてもよく、または値は、値抽出器ブロックの連続式変数入力へ提供されてもよい。値抽出器ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。
値積算器ブロックは、不連続入力で不連続イベントを受信し、かつ各不連続イベントの受信に伴ってイベントからユーザ指定の値を抽出し、値を積算してもよい。積算された値は、連続式数値出力へ提供される。不連続イベントから抽出されるべき値を指定する際には、下記の式:「約定価格」(不連続イベントに関連づけられる約定価格を提供する)、「約定数量」(不連続イベントに関連づけられる約定数量を提供する)、「注文数量」(不連続イベントに関連づけられる注文数量を提供する)、「注文価格」(不連続イベントに関連づけられる注文価格を提供する)、「実行数量」(注文数量に関連する約定の累算を提供する)、「受付中の数量」(特定の注文価格における実行されない注文数量の累算を提供する)、「取引数量」(ある取引所で実行される取引の数量を提供する)、「取引価格」(ある取引所で実行される取引の価格を提供する)および「変数」(指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する)を利用可能である。値積算器ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。値積算器ブロックは、イベントを受信すると積算価格を0へリセットするリセット不連続入力を含んでもよい。値積算器ブロックは、先に論じた積算器ブロックに類似するものであるが、どのような価格が積算されるかに関してさらにフレキシブルな設定をサポートする。
値バケットブロックは、キー値ペアのテーブルを生成することに備える。このテーブルは、例えば、ハッシュテーブルであってもよい。値バケットブロックのテーブルのキーは、バケットホールと称される。テーブルの、特定のバケットホールに対応する値(即ち、テーブルのキー)は、バケット値と称される。値バケットブロックは、不連続入力で不連続イベントを受信する。不連続イベントが受信されると、テーブルにおける適切なエントリを決定するために、バケットホールに関するユーザ定義の方程式が評価される。バケット値に関するユーザ定義の方程式は、次に、テーブルにおける決定されたバケットホールに対応するエントリに関して新たなバケット値を決定するために評価される。後述するように、この新たなバケット値は、先行するバケット値と組み合わされても、これに取って代わってもよい。配置されると、ユーザは、バケットホールの式およびバケット値を入力するようにプロンプトされてもよい。あるいは、値バケットブロックは、バケットホール「0」およびバケット値「0」等の既定の方程式へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、値バケットブロックを選択しかつバケットホール方程式およびバケット値方程式の一方または双方を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。方程式(ビルディング・ブロック・ボタンによって提供され得る)を指定する際に使用すべく利用可能な式には、「インスツルメント」(不連続イベントに関連づけられるインスツルメントを提供する)、「約定価格」(不連続イベントに関連づけられる約定価格を提供する)、「約定数量」(不連続イベントに関連づけられる約定数量を提供する)、「注文数量」(不連続イベントに関連づけられる注文数量を提供する)、「注文価格」(不連続イベントに関連づけられる注文価格を提供する)、「実行数量」(注文数量に関連する約定の累算を提供する)、「受付中の数量」(特定の注文価格における実行されない注文数量の累算を提供する)、「取引数量」(ある取引所で実行される取引の数量を提供する)、「取引価格」(ある取引所で実行される取引の価格を提供する)および「変数」(指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する)が含まれてもよい。値バケットの方程式を指定する一部として、ユーザは、新たなバケット値が先行するバケット値とどのように組み合わされるかも設定する場合がある。例えば、新たなバケット値は、先行するバケット値へ追加されてもよい(受信される不連続イベント毎に同じバケットホールに関して決定されるバケット値の加算を提供する)。別の例として、同じバケットホールに関して決定されるバケット値の平均が決定されてもよい。別の例として、新たなバケット値が先行するバケット値に取って代わってもよい(最新値を特定のバケットホールのバケット値として提供する)。値バケットは、例えば、特定のバケットホールに関するバケット値を合計することにデフォルトしてもよい。値バケットブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。また、値バケットブロックは、提供されるバケットホールの対応するバケット値が値連続式数値出力において提供されるように、バケットホールとして使用されるべき値を提供するホール連続式数値入力も有する場合がある。値バケットブロックは、イベントを受信すると格納されたテーブルをリセットするリセット不連続入力を含んでもよい。
不連続移動平均ブロックは、不連続入力において不連続イベントが受信される度に指定されたユーザ定義の方程式を評価することによって決定される値の移動平均を提供してもよい。移動平均を決定する際に使用されるべきデータポイントの数は、連続式数値入力によって指定される。移動平均は、連続式数値出力へ提供される。不連続移動平均ブロックは、対応する入力によって指定されたデータポイント数が達成されるまで、評価されたデータポイントのリストを保持してもよく、達成された時点で、最新のデータポイントがリストへ追加され、最も古いデータポイントがリストから外され、かつリスト内のデータポイントに渡って移動平均が計算されてもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、不連続移動平均ブロックは、方程式に関して0等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、不連続移動平均ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。方程式(ビルディング・ブロック・ボタンによって提供され得る)を指定する際に使用すべく利用可能な式には、「インスツルメント」(不連続イベントに関連づけられるインスツルメントを提供する)、「約定価格」(不連続イベントに関連づけられる約定価格を提供する)、「約定数量」(不連続イベントに関連づけられる約定数量を提供する)、「注文数量」(不連続イベントに関連づけられる注文数量を提供する)、「注文価格」(不連続イベントに関連づけられる注文価格を提供する)、「実行数量」(注文数量に関連する約定の累算を提供する)、「受付中の数量」(特定の注文価格における実行されない注文数量の累算を提供する)、「取引数量」(ある取引所で実行される取引の数量を提供する)、「取引価格」(ある取引所で実行される取引の価格を提供する)および「変数」(指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する)が含まれてもよい。また、不連続移動平均ブロックは、リセット入力である不連続入力を採用する場合もある。リセット入力によって不連続イベントが受信されると、記録されたデータポイントは放棄される。これにより、移動平均の出力は結果的に0、または「非数」(NaN)になる場合がある。また、不連続移動平均ブロックは、移動平均を完全に計算するに足る数のデータポイントが記録されているかどうかを表示するOKの連続式ブール出力を提供する場合もある。OKの出力は、必要とされる数のデータポイントが記録されるまでは「偽」であり、それ以後(リセットまで)は「真」である。例えば、入力されるデータポイント数が値20を提供すれば、OK出力が「真」になるまでに20個のデータポイント(即ち、各々不連続イベントの受信によってトリガされる、指定された方程式の20個の評価)が記録される必要がある。また、不連続移動平均ブロックは、記録されているデータポイント数を表示するデータポイント数連続式数値出力を提供する場合もある。不連続移動平均ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。
状態ブロックは、不連続入力において不連続イベントを受信し、かつその不連続イベントが不連続出力に提供されるべきかどうかを決定するために各不連続出力の条件文を評価してもよい。状態ブロックは、行動モデルである、例えば有限数の状態、これらの状態間の遷移およびアクションから成る状態マシンを設計するために用いられてもよい。複数の状態ブロックは、所定の条件が満たされた場合に論理が実行される様をユーザが調べ得る「フロー」グラフと同様に、互いに連結されてもよい。カレント状態は、過去の状態によって決定されることから、これは本質的には、過去に関する情報を記録してもよい。遷移は状態変化を表示し、かつ遷移を有効化するために満たされることが必要となる条件文によって記述される。状態ブロックは、ユーザが退出アクションおよび遷移を定義する条件文を定義できるようにする。例えば、各々が異なる状態遷移に対応する2つの不連続出力を提供する状態ブロックでは、ユーザはその各々について条件文を指定する。不連続イベントが受信された後、状態ブロックは、各遷移に関連づけられる条件文のうちの1つまたはそれ以上が「真」になるのを待つ(不連続イベントが受信された時点で、条件文の何れも「真」でなければ)。特定の状態遷移に関連づけられる条件文が「真」と評価されると、状態ブロックは、その特定の状態遷移に関連づけられる出力へ(受信以降保持されている)不連続イベントを提供する。条件文は、連続式ブール入力へ提供されてもよい。あるいは、条件文は、ブール値を評価する指定されたユーザ定義の方程式によって提供されてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、状態ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。状態ブロックは、非安値において複数の連続する取引が存在するかどうか等、市場におけるユーザ定義のパターンを評価するために用いられてもよい。これらの信号は、例えば、マーケットメーカ・ブロック等の取引ブロックへ入力される条件文として用いられてもよい。また状態ブロックは、例えば、不連続イベントが買いの約定メッセージであるか、売りの約定メッセージであるか等の情報を評価する可能性もある。方程式(ビルディング・ブロック・ボタンによって提供され得る)を指定する際に使用すべく利用可能な式には、「インスツルメント」(不連続イベントに関連づけられるインスツルメントを提供する)、「約定価格」(不連続イベントに関連づけられる約定価格を提供する)、「約定数量」(不連続イベントに関連づけられる約定数量を提供する)、「注文数量」(不連続イベントに関連づけられる注文数量を提供する)、「注文価格」(不連続イベントに関連づけられる注文価格を提供する)、「実行数量」(注文数量に関連する約定の累算を提供する)、「受付中の数量」(特定の注文価格における実行されない注文数量の累算を提供する)、「取引数量」(ある取引所で実行される取引の数量を提供する)、「取引価格」(ある取引所で実行される取引の価格を提供する)および「変数」(指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する)が含まれてもよい。
ブランチブロックは、不連続入力において不連続イベントを受信しかつ条件文を評価してもよい。条件文が「真」であれば、不連続イベントは第1の不連続出力(「はい」経路)において提供され、条件文が「偽」であれば、不連続イベントは第2の不連続出力(「いいえ」経路)において提供される。条件文は、連続式ブール入力において提供されてもよい。あるいは、条件文は、ブール値を評価する指定されたユーザ定義の方程式によって提供されてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、ブランチブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。ブランチブロックは、例えば、不連続イベントが買いの約定イベントであるか、売りの約定イベントであるかを評価するために用いられてもよい。このような方程式を構築するためには、「買い?」ビルディング・ブロック・ボタンが用いられてもよい。方程式(ビルディング・ブロック・ボタンによって提供され得る)を指定する際に使用すべく利用可能である他の式には、「インスツルメント」(不連続イベントに関連づけられるインスツルメントを提供する)、「約定価格」(不連続イベントに関連づけられる約定価格を提供する)、「約定数量」(不連続イベントに関連づけられる約定数量を提供する)、「注文数量」(不連続イベントに関連づけられる注文数量を提供する)、「注文価格」(不連続イベントに関連づけられる注文価格を提供する)、「実行数量」(注文数量に関連する約定の累算を提供する)、「受付中の数量」(特定の注文価格における実行されない注文数量の累算を提供する)、「取引数量」(ある取引所で実行される取引の数量を提供する)、「取引価格」(ある取引所で実行される取引の価格を提供する)および「変数」(指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する)が含まれてもよい。
マルチプレクサブロックは、不連続入力において不連続イベントを受信し、かつこの不連続イベントを特定の不連続出力において提供してもよい。例えば、マルチプレクサブロックは、注文ハンドラブロックから不連続イベントを受信し、この不連続イベントのタイプ(例えば、約定、変更または削除)を基礎としてこれをマルチプレクサブロックの適切な不連続出力において提供してもよい。配置されると、ユーザは、どの不連続イベントタイプに関して出力が提供されるかを指定するようにプロンプトされてもよい。あるいは、マルチプレクサブロックは、あらゆる不連続イベントタイプに関して出力を提供する規定の設定へデフォルトしてもよい。出力が提供される指定された不連続イベントタイプは、アルゴリズムを設計する間に、ユーザにより、例えば、マルチプレクサブロックを選択しかつ不連続イベントタイプを指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。マルチプレクサブロックは、例えば、注文を管理するために注文ハンドラブロックと共に用いられてもよい。
ファンネルブロックは、2つ以上の不連続入力において不連続イベントを受信し、かつこれらを単一の不連続出力において提供してもよい。ファンネルブロックは不連続イベントを保持せず、出力へと通過させる。ファンネルブロックは、例えば、複数の入力を必要とする状態ブロックと共に用いられてもよい。
シーケンサブロックは、不連続イベントが出力を通過する注文を保証してもよい。シーケンサブロックは、1つの不連続入力と、2つ以上の不連続出力とを有してもよい。入力において不連続イベントが受信されると、シーケンサブロックは、この不連続イベントを各出力へ順番に提供する。即ち、受信された不連続イベントの処理において、シーケンサブロックは、まずこの不連続イベントを第1の出力へ提供し、次にはこの不連続イベントが第2の出力、等々へ提供されていく。これにより、ユーザは、アルゴリズムにおいて不連続入力を受信するどの注文ブロックが更新されるかを正確に決定できる場合がある。しかしながら、シーケンサブロックの同じ不連続出力へ複数のブロックが接続されていれば、これらのブロックが不連続イベントを受信する順番は指定されない。このブロックは、シーケンスブロックと称される場合もある。
不連続最小ブロックは、2つの不連続入力を比較し、かつ指定された属性(例えば、取引価格、取引数量、他)の最小値の連続式数値出力を提供してもよい。一方の入力において不連続イベントが受信されると、このイベントから指定された属性値が抽出されかつ格納される。抽出された値は、他の不連続入力に関して最近に格納された値と比較されてどちらが小値であるかが決定され、その値が連続式数値出力において提供される。一方の入力で不連続イベントが受信されていなければ、他方の入力から抽出される値が常により大きい値として取り扱われてもよい。代替例として、特定の不連続入力の値は、単に0へデフォルトしてもよい。不連続最小ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。不連続最小ブロックは、イベントを受信すると、各不連続入力に関して格納された値をリセットしかつ相応して最小出力を更新するリセット不連続入力を含んでもよい。
不連続最大ブロックは、2つの不連続入力を比較し、かつ指定された属性(例えば、取引価格、取引数量、他)の最大値の連続式数値出力を提供してもよい。一方の入力において不連続イベントが受信されると、このイベントから指定された属性値が抽出されかつ格納される。抽出された値は、他の不連続入力に関して最近に格納された値と比較されてどちらがより大きい値であるかが決定され、その値が連続式数値出力において提供される。一方の入力で不連続イベントが受信されていなければ、他方の入力から抽出される値が常により大きい値として取り扱われてもよい。代替例として、特定の不連続入力の値は、単に0へデフォルトしてもよい。不連続最大ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。不連続最大ブロックは、イベントを受信すると、各不連続入力に関して格納された値をリセットしかつ相応して最大出力を更新するリセット不連続入力を含んでもよい。
その他のブロックには、例えば、最小、最大、丸め、10進表示、not、一度真、数字である、移動平均、条件付きf(x)、数値f(x)、平均、タイマ、注記、乱数、平方根、対数および休止の各ブロックが含まれてもよい。
最小ブロックは、2つの連続式数値入力を比較してどちらが小値であるかを決定し、かつこれを出力してもよい。最小ブロックは、真ん中にテキスト「MIN」、左側に2つの連続式数値入力および右側に1つの連続式数値出力を備える三角形状を有してもよい。
最大ブロックは、2つの連続式数値入力を比較してどちらがより大きい値であるかを決定し、かつこれを出力してもよい。最大ブロックは、真ん中にテキスト「MAX」、左側に2つの連続式数値入力および右側に1つの連続式数値出力を備える三角形状を有してもよい。
丸めブロックは、連続式数値入力によって提供される数字を連続式数値入力によって提供される最近の増分へと丸め、1つの連続式数値出力を生成してもよい。増分値が提供されていなければ、丸めブロックは最近の整数へ丸めてもよい。さらに、ユーザは、丸めブロックの3つのオプション、即ち正規丸め、常に切り上げ、および常に切り捨て、の中から1つを指定してもよい。正規丸めは、伝統的な丸め規則を使用する(例えば、0.5は1に切り上げられ、0.49は0に切り捨てられる)。常に切り上げは、2つの増分間に存在する値をより高位の増分へと丸める(例えば、2.1は3に切り上げられ、2は2に丸められる)。常に切り捨ては、2つの増分間に存在する値をより低位の増分へと丸める(例えば、2.9は2に切り捨てられ、2は2に丸められる)。どのオプションも指定されなければ、丸めブロックは、例えば正規丸めへデフォルトしてもよい。丸めブロックは、真ん中にテキスト「丸め」、左側に2つの連続式数値入力および右側に1つの連続式数値出力を備える矩形形状を有してもよい。
10進表示ブロックは、連続式数値入力によって提供される数字および連続式インスツルメント入力によって提供されるインスツルメントを用いて10進形式の数字を出力してもよい。例えば、10進表示ブロックは、ユーザが、数字ブロックを用いて価格等の値をアルゴリズムの他の部分へ、その値を10進形式で計算する必要なしに(恐らくは変数として)供給することを希望する場合に利用されてもよい。ユーザは、インスツルメントZNの価格が117125となっているのを見慣れているかもしれないが、これは、価格117および12.5/32ndsを表現している場合がある。117125は、10進表示ブロックによってインスツルメントと共に入力として提供されてもよく、10進表示ブロックはこの数字を、アルゴリズムの残りの部分が使用する適切な10進フォーマット値(ここでは、117.390625)へ変換する。10進表示ブロックは、真ん中にテキスト「D2Dec」、左側に1つの連続式インスツルメント入力および1つの連続式数値入力および右側に1つの連続式数値出力を備える矩形形状を有してもよい。
NOTブロックは、入力値が「真」であれば出力は「偽」であり、かつ入力値が「偽」であれば出力は「真」であるように、連続式ブール入力の論理否定を実行してもよい。NOTブロックは、真ん中に否定記号(「!」または「−」)、左側に1つの連続式ブール入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
一度真ブロックは、連続式ブール入力が「真」になると、アルゴリズムの寿命に渡って「真」の連続式ブール出力を提供してもよい。入力値が少なくとも一度「真」になるまでは、一度真ブロックの出力値は「偽」である。一旦、入力値が「真」になれば、一度真ブロックは、その後入力値が変わったとしても、常に値「真」を出力する。一度真ブロックは、真ん中にテキスト「T」、左側に1つの連続式ブール入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。このブロックは、「一度真なら常に真」ブロックと称される場合もある。
「数字である」ブロックは、連続式数値入力において提供される値が数字であれば「真」の連続式ブール出力を提供し、かつ提供される値が「非数」(NaN)であれば「偽」を出力してもよい。「数字である」ブロックは、真ん中にテキスト「IsNum?」、左側に1つの連続式数値入力および右側に1つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
移動平均ブロックは、連続式数値入力としてデータ値(価格または数量等、経時変化している場合がある)を、かつ連続式数値入力として分数値を採用し、かつ連続式数値出力として指定された分数に渡る移動平均を提供してもよい。移動平均ブロックは、データ値を毎秒記録してもよい。例えば、ユーザが1分間の移動平均を得ることを希望すれば、移動平均ブロックは60個のデータポイントを記録し、これらを平均して出力する。また、移動平均ブロックは、入力されたデータ値が有効かどうかを表示する連続式ブール値を採用してもよい。この入力はオプションであり、「真」へデフォルトする。データ値が(1秒に一度のデフォルトによって)記録される予定であれば、移動平均ブロックは、その有効な入力が「真」であるかどうかを確認するチェックを行う。「真」であれば、データ値はデータポイントとして記録される。有効な入力が「偽」であれば、データ値はデータポイントとして記録されない。また、移動平均ブロックは、リセット入力である不連続入力を採用する場合もある。リセット入力によって不連続イベントが受信されると、記録されたデータポイントは放棄される。これにより、出力される移動平均は、記録されるデータ値に依存して結果的に0または「非数」(NaN)になる。また、移動平均ブロックは、移動平均を完全に計算するに足る数のデータポイントが記録されているかどうかを表示するOKの連続式ブール出力を提供する場合もある。OKの出力は、必要とされる数のデータポイントが記録されるまでは「偽」であり、それ以後(リセットまで)は「真」である。例えば、入力される分数が値20を提供すれば(20分間の移動平均)、OK出力が「真」になるまでに1200個のデータポイント(毎秒1データポイントで20分間)が記録される必要がある。また、移動平均ブロックは、記録されているデータポイント数を表示するデータポイント数連続式数値出力を提供する場合もある。移動平均ブロックは、真ん中にテキスト「MvgAvg」、左側に4つの入力(2つの連続式数値入力、1つの連続式ブール入力および1つの不連続入力)および右側に3つの出力(2つの連続式数値出力および1つの連続式ブール出力)を備える矩形形状を有してもよい。
条件付きf(x)ブロックは、連続式ブール出力の値を提供するユーザ定義の方程式を評価してもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、条件付きf(x)ブロックは、「真」等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、条件付きf(x)ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。所定の実施形態において、条件付きf(x)ブロックは、別のブロックの出力からの値を参照してもよい。値は、ブロックおよび出力を指定するビルディング・ブロック・ボタン215を用いて参照される場合もあれば、条件付きf(x)ブロックの連続式変数入力へ提供される場合もある。条件付きf(x)ブロックは、真ん中にテキスト「f(x)」を有し、左側に入力がなく(値がユーザ定義の方程式において参照されない場合。この場合、各変数に対応する連続式入力が提供される)、右側に1つの連続式ブール出力を備えて、左側に矩形形状、および右側にアーチ形を有してもよい。
数値f(x)ブロックは、連続式数値出力の値を提供するユーザ定義の方程式を評価してもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、数値f(x)ブロックは、0等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、数値f(x)ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。所定の実施形態において、数値f(x)ブロックは、別のブロックの出力からの値を参照してもよい。値は、ブロックおよび出力を指定するビルディング・ブロック・ボタン215を用いて参照される場合もあれば、数値f(x)ブロックの連続式変数入力へ提供される場合もある。数値f(x)ブロックは、真ん中にテキスト「f(x)」を有し、左側に入力がなく(値がユーザ定義の方程式において参照されない場合。この場合、各変数に対応する連続式入力が提供される)、右側に1つの連続式数値出力を備えて、左側に矩形形状、および右側にアーチ形を有してもよい。
所定の実施形態において、条件付きf(x)ブロックおよび数値f(x)ブロックは、f(x)ブロック等の単一ブロックに合併されてもよい。f(x)ブロックは、連続式変数出力のブール値または数値の何れかを提供するユーザ定義の方程式を評価してもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、f(x)ブロックは、0等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、f(x)ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン215に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。所定の実施形態において、f(x)ブロックは、別のブロックの出力からの値を参照してもよい。値は、ブロックおよび出力を指定するビルディング・ブロック・ボタン215を用いて参照される場合もあれば、f(x)ブロックの連続式変数入力へ提供される場合もある。f(x)ブロックは、真ん中にテキスト「f(x)」を有し、左側に入力がなく(値がユーザ定義の方程式において参照されない場合。この場合、各変数に対応する連続式入力が提供される)、右側に1つの連続式変数出力を備えて、左側に矩形形状、および右側にアーチ形を有してもよい。
平均ブロックは、2つ以上の連続式数値入力の値を平均して1つの連続式数値出力を生成してもよい。例えば、平均ブロックは10個の入力を有してもよい。別の例として、平均ブロックは1つの入力によって始まってもよく、かつ平均ブロック入力へ接続が行われる度に新たな入力が動的に提供されてもよい。入力の値は合計され、次に、値を提供する入力数で除算されて出力が提供される。平均ブロックは、真ん中にテキスト「AVE」または「AVG」、左側に2つ以上の連続式数値入力および右側に1つの連続式数値出力を備える矩形形状を有してもよい。
タイマブロックは、時間、分および秒という時間の連続式数値出力を提供してもよい。例えば、タイムはカレントタイムであってもよい。カレント時間は、例えば、ユーザへ取引インタフェースを提供するコンピューティングデバイスにおける時間であっても、アルゴリズムサーバにおけるカレント時間であってもよい。別の例として、この時間は、アルゴリズムが実行を開始された時点からであってもよい。別の例として、この時間は、カレント取引セッションの開始以降の時間であってもよい。別の例として、この時間は、カレント取引セッションの12amCSTからの時間であってもよい。別の例として、この時間は取引所によって提供される時間であってもよい。タイマブロックは、真ん中にテキスト「TIMER」またはクロック記号、および右側に3つの連続式数値出力を備える矩形形状を有してもよい。
注記ブロックは、ユーザが設計されているアルゴリズムに関してコメントおよび注記を入力するためのテキストボックスを提供してもよい。注記ブロックは、入力または出力を持たなくてもよい。配置されると、ユーザは、注記ブロックにテキストを入力するようにプロンプトされてもよい。あるいは、注記ブロックは、「ここへ注記を追加」等の既定値へデフォルトしてもよい。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、注記ブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。注記ブロックは、アルゴリズムの動作に影響を与えない。注記ブロックは、真ん中にテキスト値が表示される矩形形状を有してもよい。
乱数ブロックは、連続式数値出力へ乱数を提供してもよい。乱数は、乱数ブロックが配置される、または後に設定される際に、整数または浮動小数点値であるように指定されてもよい。乱数ブロックは、整数値を提供することへデフォルトしてもよい。乱数は、連続式数値入力によって指定される最小値と、連続式数値入力によって指定される最大値との間であってもよい。最小入力が提供されていなければ、これは、例えば0へデフォルトしてもよい。最大入力が提供されていなければ、これは、整数出力に関してはコンピューティングデバイスによってサポートされる最大整数へ、または浮動小数点出力に関しては1へデフォルトしてもよい。また、乱数ブロックは、新たな乱数が提供されるべき時点をシグナリングするための不連続入力も有する場合がある。不連続入力が提供されていなければ、乱数ブロックは、例えば1秒毎に新たな乱数を提供してもよい。乱数ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。乱数ブロックは、真ん中に疑問符記号(「?」)またはテキスト(RAND)、左側に2つの連続式数値入力および1つの不連続入力および右側に1つの連続式数値出力を備える正方形形状を有してもよい。
平方根ブロックは、連続式数値入力において提供される値に関して、連続式数値出力において平方根値を提供してもよい。入力が負数であれば、出力は「非数」(NaN)であってもよい。平方根ブロックは、真ん中に平方根記号
左側に1つの連続式数値入力および右側に1つの連続式数値出力を備える三角形状を有してもよい。
対数ブロックは、連続式数値入力において提供される値に関して、連続式数値出力において対数値を提供してもよい。対数の底の値は、連続式数値入力において提供されてもよい。底の値が提供されていなければ、これは、例えば自然対数へデフォルトしてもよい。対数ブロックは、真ん中にテキスト「対数」、左側に2つの連続式数値入力および右側に1つの連続式数値出力を備える正方形形状を有してもよい。
休止ブロックは、不連続入力において不連続イベントが受信されると、または連続式ブール入力において提供される値が「真」になると、アルゴリズム全体を休止してもよい。所定の実施形態では、ブール入力値が再び「偽」になれば、アルゴリズムは実行を再開してもよい。所定の実施形態では、アルゴリズムは、休止ブロックに起因して一旦休止されると、手動で再開されなければならない。休止ブロックは、背景が赤で真ん中にテキスト「停止」、左側に1つの連続式ブール入力および1つの不連続入力を備える八角形状であってもよい。
アルゴリズムを表現する命令または論理(本明細書ではプログラミングコードと称される)は、アルゴリズムの定義を基礎として生成される。所定の実施形態において、プログラミングコードは、続いてコンパイルされ得るソースコード(人間および/またはコンパイラによって読取り可能なテキスト)である。所定の実施形態において、プログラミングコードの言語は中間言語である。所定の実施形態において、プログラミングコードは機械実行可能命令を含む。所定の実施形態において、プログラミングコードの生成は、生成されたソースコードおよび/または中間言語コードのコンパイルを含む。所定の実施形態では、プログラミングコードの生成は生成されたソースコードおよび/または中間言語コードのコンパイルを含まず、このようなコンパイルは別個のプロセスである。
次に、(コンパイルの後、適切であれば)生成されたプログラミングコードは、定義されたアルゴリズムに従って取引するためにシミュレートされ、かつ/または使用されてもよい。本明細書において、プログラミングコードが実行され、遂行されかつ/またはシミュレートされるべく論考される場合、生成されたプログラミングコードは、実行され、遂行されかつ/またはシミュレートされることが適切であれば追加的なコンパイルを行われているものと想定されている。
所定の実施形態において、プログラミングコードは、アルゴリズムが設計されるにつれて生成される。アルゴリズムが設計される間、アルゴリズムの定義は、ブロックおよび/または接続が追加され、修正されかつ/または除去されるにつれて変化していく場合があることに留意されたい。所定の実施形態において、プログラミングコードは、アルゴリズムの定義が変更される際に自動的に生成される。所定の実施形態において、プログラミングコードはユーザが要求する時点で生成される。
所定の実施形態において、プログラミングコードは、クライアントデバイスにおいて取引インタフェース310のアルゴリズム取引アプリケーションのコンポーネントによって生成される。所定の実施形態において、プログラミングコードは、例えば、アルゴリズム生成デバイス、先に述べたアルゴリズムサーバ302に類似するアルゴリズムサーバおよび/または先に述べたゲートウェイ120に類似するゲートウェイ等の別のデバイスにおいて、アルゴリズム取引アプリケーションのコンポーネントによって生成される。所定の実施形態において、プログラミングコードは2つ以上のコンポーネントによって生成される。例えば、アルゴリズム取引アプリケーションの複数のコンポーネントは、コードを生成するために互いに機能してもよい。このようなコンポーネントは、例えば、プログラミングコードの異なる態様または機能を生成するように特化されてもよい。
所定の実施形態において、プログラミングコードは2つ以上のデバイスによって生成される。例えば、プログラミングコードは、クライアントデバイスおよびアルゴリズムサーバによって生成されてもよい。アルゴリズムの定義を基礎として生成されるプログラミングコードは、どのコンポーネントまたはデバイスがこれを生成しているかに基づいて異なってもよい。例えば、クライアントデバイスにおいて生成されるプログラミングコードは、クライアントデバイスによる実行に合わせて最適化される場合があり、かつ/またはアルゴリズムサーバにおいて生成されるプログラミングコード(例えば、ユーザインタフェース関連機能を含まない場合がある)とは異なる機能(例えば、ユーザインタフェース関連機能)を含む場合がある。明確を期して、別段の指摘のない限り、以下の論考はクライアントデバイスにおけるプログラミングコードの生成に関して行うが、アルゴリズムサーバ等の別のデバイスにおいてプログラミングコードが生成される場合でも同様の措置が講じられることは理解されるべきである。
所定の実施形態において、プログラミングコードは、C#および.NET4.0フレームワーク等のプログラミング言語を用いてオブジェクト指向的に生成される。
所定の実施形態において、プログラミングコードは、アルゴリズム定義における各ブロックおよび接続をトラバースすることによって生成される。プログラミングコードは、ブロック毎に生成される。プログラミングコードの生成に際しては、幾つかのブロックが原始変数になる場合がある。例えば、加算器ブロックは、その値が加算器ブロックの入力へ接続される出力の値の合計であるように設定される浮動小数点変数になる場合があり、前記合計は再帰的に決定されてもよい。さらに複雑な機能を有し得る他のブロックは、ベースクラスから導出されるサブクラスとして生成されてもよい。ベースクラスは、対応するブロックに関連づけられるコア機能を提供してもよい。生成されたサブクラスは、次に、プログラミングコードが生成されつつあるブロックに固有の値をベースクラスのコア機能へ提供するために、戻り値を有する仮想方法をオーバーライドしてもよい。例えば、設計キャンバスエリア311内に配置されるマーケットメーカ・ブロックは、ベース・マーケット・メーカ・クラスのサブクラスである生成されたプログラミングコードを有してもよい。サブクラスは、マーケットメーカ・ブロックの様々な入力に値を得るために、かつマーケットメーカ・ブロックが買いのために設定されたか、売りのために設定されたかを指定するために、仮想方法をオーバーライドしてもよい。先に論じた基本ブロックとは異なり、マーケットメーカ・ブロックは、より複雑な機能を提供する取引ブロックである。
ブロック間の連続式接続は、接続される出力値と入力値とがどのように関係するかを指定する。上述の加算器の例を続けると、加算器ブロックの出力を表す浮動小数点値は、加算器ブロックの連続式入力へ接続される他の原始変数(他のブロック/出力を表す)の値の合計であるように設定されてもよい。所定の実施形態では、連続式接続を有する複数のブロック(原始変数を生成する)が複数の中間媒介変数を用いることなく1つの式へ凝縮され得るように、生成されたプログラミングコードが連続式接続を用いて扁平にされてもよい。
ブロック間の不連続接続は、不連続イベントが生成されると適切な方法(ハンドラ)が呼び出されるように、イベント発生器およびイベントハンドラを生成するために用いられる。不連続イベントは、イベント発生器からイベントハンドラへ送られて処理される。
実行に際して、アルゴリズムは、アルゴリズムの状態を変えさせるアクションに応答する。アクションには、市場イベント(例えば、価格更新、数量更新、注文確認、取引確認、約定確認または取引通知)等の外部イベントおよびタイマイベント(例えば、システムのクロックまたはアラームからの)が含まれてもよい。これらの外部イベントにより、結果的に、注文確認不連続イベント、取引確認不連続イベント、約定確認不連続イベントまたは取引通知不連続イベント等の不連続イベントが生成され、かつ/またはインスツルメントの価格値または数量値等の連続値が更新される場合がある。また、アクションには、アルゴリズム内のブロックまたは変化する連続値によって生成される不連続イベント等の内部イベントも含まれる場合がある。
内部または外部不連続イベントが発生する(例えば、取引確認不連続イベントまたは発生器ブロックが不連続イベントを発生する)場合、アルゴリズム内の各関連ブロックは、そのブロックがイベントに関連づけられるその特化された機能を実行し得るようにイベントハンドラ方法を呼び出している。イベントハンドラは、不特定の順序で評価されてもよい。例えば、イベントハンドラは、アルゴリズム定義においてその個々のブロックが置かれている順番を基礎として評価されてもよい。イベントハンドラによる処理は、受信されるイベントを基礎としてブロックの機能を実行すること、連続式出力値を更新すること、および不連続イベントを発生してそれを接続された他のブロックへの出力へ提供することを含んでもよい。
内部または外部連続値が変わる(例えば、市場データが更新される、またはシステムクロックの時間が変わる)場合、データソースに直接または間接的に接続される各関連ブロック(下流ブロック)は、新たなデータを反映してその値を更新している。幾つかのブロックの結果である原始変数は、例えば、新たな値を割り当てられる。
連続式出力値が不連続イベントまたは連続値変化の何れかによって更新されれば、更新値を受信するために直接または間接的に接続される各ブロックが処理されるべきブロックのリストに追加される。外部イベントに関与しているブロックがその処理を完了すると、ブロックのリストは、これらのブロックが次には内部イベントに応答して行動し得るように処理される。内部イベントは、外部イベントと同様にして処理される。この処理は、次に、各ブロックの処理がアルゴリズムの状態に新たな変化を生み出すにつれて反復されてもよい。
図3D−1から図3D−7は、所定の実施形態によって生成されるプログラミングコードの例を示す。図示されているプログラミングコードは、生成され得るプログラミングコードの単なる一部でありかつ例示を目的とするものであり、よって明確を期して所定の機能を強調するために単純化されていることに留意されたい。
プログラミングコードは、図3D−1に示されているように、設計キャンバスエリア311にブロックが配置されていない場合でも生成される場合がある。生成されるプログラミングコードは、設計中のアルゴリズムを表す新たなクラス(「CustomAlgorithm0」)を含む。この新たなクラスはアルゴリズムクラスのサブクラスであり、アルゴリズム取引アプリケーションを有するアルゴリズムを実行するための基本的なインタフェースおよび機能を提供する。CustomAlgorithm0クラスは、設計中のアルゴリズムに固有の機能がアルゴリズム取引アプリケーションのフレームワークに組み込まれかつ実行され得るように、このアルゴリズムクラスの仮想方法をオーバーライドしてもよい。
本例の説明を続けると、図3D−2に示されているように、設計キャンバスエリア311にブロックが配置されると、追加的なプログラミングコードが生成されてもよい。先に論じたように、幾つかのブロックは原始変数となる場合があり、これらの間の連続式接続は、これらがどのように関連しているかを表している。例えば、図示されているように、設計キャンバスエリア311には2つの定数ブロック(「ConstantNumberBlock0」および「ConstantNumberBlock1」)ならびに加算器ブロック(「AdderBlock0」)が配置されている。ブロック同士は、接続されていないことに留意されたい。生成されたプログラミングコードのマーキングされている部分は、これらの基本ブロックがプログラミングコードにおいて(「ダブル」タイプの)原始変数として表現されることを示す。
図3D−3に示されているように、接続はConstantNumberBlock0およびConstantNumberBlock1からAdderBlock0へ行われている。接続は、これらのブロック間の関係性を明示する。生成されたプログラミングコードのマーキングされている部分は、AdderBlock0の値がConstantNumberBlock0の値とConstantNumberBlock1の値との和に等しいことを示す。これは、加算器ブロックによって表される機能が2つの入力の値を加算することにあるためである。
図3D−4に示されているように、設計キャンバスエリア311にマーケットメーカ・ブロックが配置されている。先に論じた基本ブロックとは異なり、マーケットメーカ・ブロックは、より複雑な機能を提供する取引ブロックである。生成されるプログラミングコードは、配置されている特定のマーケットメーカ・ブロックの機能を表す新たなクラス(「CustomMarketMaker0」)を追加する。CustomMarketMaker0はMarketMakerのサブクラスであり、マーケットメーカ・ブロックの基本機能を提供する。CustomMarketMaker0クラスは、配置されたマーケットメーカ・ブロックに固有の機能がアルゴリズム取引アプリケーションのフレームワークに組み込まれかつ実行され得るように、MarketMakerクラスの戻りタイプを有する仮想方法をオーバーライドしてもよい。この場合、CustomMarketMaker0は、MarketMakerベースクラスにおける論理によって呼び出される方法をオーバーライドして、マーケットメーカ・ブロックの様々な入力の値を取得する。図3D−5に示されているように、配置されたマーケットメーカ・ブロックの数量入力は、先に論じた加算器ブロックの出力へ接続されている。生成されたプログラミングコードのマーキングされている部分は、CustomMarketMaker0クラスの仮想方法「GetQty」がAdderBlock0の値を戻すためにオーバーライドされていることを示す。
本例の説明を続けると、図3D−6に示されているように、不連続出力と不連続入力との間に接続が行われている。具体的には、接続は、マーケットメーカ・ブロックの不連続約定出力と、値積算器ブロックのリセット入力との間で行われた。値積算器ブロックは不連続ブロックであり、取引ブロックと同様に新たなクラス(「CustomValueAccumulator0」)が追加されている(不図示)。生成されたプログラミングコードのマーキングされている部分は、新たなサブクラス(「CustomMarketMaker0」および「CustomValueAccumulator0」)がインスタンス化されること、およびMarketMakerBlock0のイベント「DiscreteObjectGenerated」がCustomAlgorithm0(「InterceptOrderMessage」)およびValueAccumulatorBlock0(「ProcessResetMessage」)のイベントハンドラと連結されることを示す。したがって、MarketMakerBlock0が約定メッセージを有していれば、これがDiscreteObjectGeneratedイベントをファイアし、連結されている全てのハンドラに通知される。この場合、ProcessResetMessageハンドラに通知が届けば、これは積算器の値を0にリセットする。
本例の説明を続けると、図3D−7に示されているように、インスツルメントブロック(「SimpleInstrumentBlock0」)とインスツルメント属性ブロック(「InstrumentFieldBlock0」)との間に接続が行われている。インスツルメントブロックは、インスツルメント「ESZ0」に関して受信される市場データを基礎としてその連続式出力を更新する「InstrumentSnapshot」クラスのインスタンスであるように生成される。InstrumentSnapshotクラスは、インスツルメントのその属性の対応値を得るために参照され得る会員変数または特性を提供する。例えば、「SetAllVariables」(アルゴリズム内の全ての値を設定する)または「HandleUpdate」(特定の連続値の更新によって影響される値を設定する)が呼び出されると、インスツルメント属性ブロックは、その値をインスツルメントブロックの「.Bid」特性となるように設定する。
図3Eは、所定の実施形態による取引インタフェース310を示す。所定のブロックは、「変数」であるように指定されてもよい。例えば、定数ブロック、定数ブールブロックおよびインスツルメントブロックは変数であるように指定されてもよい。
変数エリア313は、変数ブロックの修正に備える。変数エリア313は、各変数のブロック名およびそのデフォルト値を表示する。変数エリアは、変数のブロック名および/またはそのデフォルト値を変更するために選択されてもよい。変数は、アルゴリズムのパラメータと称される場合もある。
図示されているように、設計キャンバスエリア311は、変数として指定されている2つのブロック、即ちインスツルメントブロック321および定数ブロック322を含む。ブロックは、例えば、配置される際に、または配置された後に変数として指定されてもよい。例えば、ブロックはカーソルを用いて選択されてもよく、次に、変数にされるべきブロックを指定するためにメニュオプションが選択されてもよい。変数として指定されたブロックは、例えば、異なる色、縁、背景、パターンおよび/またはテキストによって示されてもよい。本図では、表示されたブロック名にテキスト「Variable」が付加されている。
先に論じたように、変数エリア313は、変数ブロック321および322毎に入力を有する名前カラム323と、変数ブロック毎に対応するデフォルト値入力を有するデフォルト値カラム324とを含む。例えば、インスツルメントブロック321は「InstrumentBlock0」と名付けられてデフォルト値「ESZ0」を有し、かつ定数ブロック322は「ConstantBlock0」と名付けられてデフォルト値「5」を有する。
ユーザは、カラム324内のデフォルト値入力を選択して変数ブロックのデフォルト値を変えることができ、よって、アルゴリズムの評価ではその新しいデフォルト値が使用される。同様に、ユーザは、名前カラム323内の名前入力を選択して個々の変数ブロックの名前を変えることができる。変数ブロック321および322は、例えば、ユーザが、アルゴリズムのパラメータとして作用する変数ブロックの値を変えることによって、根本的な論理ではなくアルゴリズムの行動を操作できるようにしてもよい。
制御エリア314は、アルゴリズムの設計に際して用いるための制御を提供する。制御エリア314は、アルゴリズムのシミュレーションを開始しかつ休止するための再生ボタンと休止ボタンとを含んでもよい。アルゴリズムのシミュレーションは、アルゴリズムの論理がどのように行動するかを示すために用いられてもよい。さらに、制御エリア314は、アルゴリズムを基礎としてプログラミングコードを生成させる生成ボタン(不図示)を含んでもよい。生成ボタンは、アルゴリズムの変更に基づいてプログラミングコードが自動的には生成されていない場合に用いられてもよい。これは、設計中のアルゴリズムが複雑であり、かつアルゴリズムの各修正後のプログラミングコードの生成(および適当であれば、これに続くこのプログラミングコードのコンパイル)が望ましくなく長い時間を要する場合に望ましいことがある。所定の実施形態では、制御エリア314は、アルゴリズムを基礎として生成されたプログラミングコードをコンパイルさせるコンパイルボタン(不図示)を含んでもよい。コンパイルボタンは、アルゴリズムの変更に基づいてプログラミングコードが自動的には生成かつ/またはコンパイルされていない場合に用いられてもよい。これは、設計中のアルゴリズムが複雑であり、かつアルゴリズムの各修正後のプログラミングコードのコンパイルが望ましくなく長い時間を要する場合に望ましいことがある。
図3F−図3Gは、所定の実施形態による取引インタフェース310を示す。取引インタフェース310は、ライブフィードバック機能を提供する。ライブフィードバック機能は、設計キャンバスエリア311内の特定のブロックに関して、この特定のブロックの値のディスプレイを提供する。例えば、そのブロックの1つまたは複数の入力および/または出力について、ライブフィードバック値が表示されてもよい。ライブフィードバック値は、例えば、そのブロックまたは対応する入力および/または出力に関連して表示されてもよい。ライブフィードバックは、ブロックの入力または出力の値が変わる度に更新されてもよい。あるブロックの出力の変化は、結果的にこの第1のブロックの出力を入力として得る別のブロックの出力を(直接または間接的に)変える場合があり、これにより両ブロックのライブフィードバックが更新される結果となることに留意されたい。
図3Fに示されているように、設計キャンバスエリア311に様々なブロック331が配置されている。ブロック331の出力毎に、ライブフィードバック332が出力の値を示して提供されている。ブロック333は数字ブロックであり、出力値はブロック333自体のディスプレイに示されることから、ライブフィードバックは提供されないことに留意されたい。所定の実施形態において、ライブフィードバックは、配置された特定のブロックの1つまたは複数の入力に関して提供される。所定の実施形態において、ライブフィードバックは、配置された特定のブロックの入力および出力の双方に関して提供される。所定の実施形態において、ライブフィードバックは、設計キャンバスエリア311内の全てのブロックに関して提供される。
インスツルメントブロックのライブフィードバックは、値「GCJ1」を表示している。買い数量を提供するように設定されるインスツルメント属性ブロックのライブフィードバックは値「3」を表示し、インスツルメントGCJ1の買い数量が3であることを表現している。加算器ブロックのライブフィードバックは値13を表示しているが、これは、2つの入力値3(インスツルメント属性ブロックから)および10(第1の数字ブロックから)の合計である。除算ブロックのライブフィードバックは値6.5を表示しているが、これは、第1の入力値13(加算器ブロックから)を第2の入力値2(第2の数字ブロックから)で除算した結果である。
アルゴリズムがシミュレーション中でない限り、所定のブロックにはライブフィードバックが提供されない場合がある。例えば、図3Gに示されているように、マーケットメーカ・ブロック335の出力にはライブフィードバックが提供されていない。これは、アルゴリズムが実行中でない(例えば、シミュレーション中でない)限り、マーケットメーカ・ブロック335は動作せず、よって市場と相互に作用しないためである。したがって、マーケットメーカ・ブロック335は、その動作を基礎とする連続値を提供せず(動作していないため)、また不連続イベントを発生することもない(やはり、動作していないため)。また、ライブフィードバックは、値抽出器ブロック336の出力にも提供されない。これは、値抽出器ブロック336が不連続入力を有し、よってその出力が値を有するのは不連続イベントが受信される場合に限られるためである。しかしながら、アルゴリズムが実行中でない限り、不連続イベントは受信されない。
表示されるべきライブフィードバック値は、アルゴリズム自体から提供される。例えば、設計中のアルゴリズムに関して生成されるプログラミングコードは、取引インタフェース310等の取引インタフェースのディスプレイを更新するための追加命令を含んでもよい。所定の実施形態において、アルゴリズムに関して生成されるプログラミングコードは、例えば、アルゴリズムサーバ302等には取引インタフェースが存在しない場合があることから、取引インタフェースのディスプレイを更新するための追加インスツルメントを含まない。図3D−2および図3D−3に示されているように、方法「SetAllVariables」は、呼び出されると、方法「SendUpdate」を呼び出す。方法SendUpdateはユーザインタフェースへ、更新対象であるブロックの識別、更新対象である特定の出力指数および値(この場合は、加算器ブロックの値)を提供する。したがって、ブロックの値が変わる度に、ライブフィードバックを更新すべくユーザインタフェースへ更新が提供される。また、方法SendUpdateは、ユーザインタフェースへ更新値を提供するために、導出クラスを生成するブロックのベースクラスによって呼び出される場合もある。同様に、図3D−6に示されているように、イベントハンドラ「InterceptOrderMessage」は、イベント「DiscreteObjectGenerated」が発生すると呼び出されるべく登録されている。方法InterceptOrderMessageは、ユーザインタフェースへ、対応する不連続イベントの通知を提供する。したがって、この不連続イベントが発生される度に、ユーザインタフェースはライブフィードバックを提供することができる。
アルゴリズムの実行中(シミュレーション中等)、ライブフィードバックは、設計キャンバスエリア311内の全てのブロックに関して提供されてもよい。不連続イベントは特定の時点で発生することから、イベントが発生すると、不連続イベント発生のインジケータが表示されてもよい。例えば、不連続入力および/または出力は、その入力および/または出力において不連続イベントが発生するとフラッシュして色、サイズまたは形状を変えてもよい。別の例として、不連続入力と不連続出力との間の接続は、その接続を介して不連続イベントが提供されるとフラッシュして色、サイズまたは形状を変えてもよい。別の例として、不連続イベントが出力から接続に沿って入力へ提供されていることを表現するために、接続に沿ってアニメーションが提供されてもよい。アニメーションは、例えば、接続に沿って移動する赤い円等のアイコンであってもよく、または接続は脈動してもよい。
ライブフィードバック機能は、アルゴリズムの設計中およびアルゴリズムの実行中にユーザへフィードバックを提供する。ライブフィードバックは、アルゴリズムの動作の安全性および完全性、一般的傾向および損/益の可能性を含み、アルゴリズム論理がどのように行動するかをユーザが評価できるようにしてもよい。
図3H−図3Lは、所定の実施形態による取引インタフェース310を示す。取引インタフェース310は、アルゴリズムが設計される際の潜在的エラーを減らすための安全機能を提供する。
図3Hに示されているように、設計キャンバスエリア311にはインスツルメントブロック341が配置されている。しかしながら、インスツルメントブロック341が配置された時点でインスツルメントは指定されていなかった。インスツルメントが指定されていなければ、インスツルメントブロックはインスツルメント名を出力できないことから、これは無効な設定である。インスツルメントブロック341の近くには、問題が存在することを示す警告インジケータ342(この場合は、赤い円内に感嘆符(「!」)が付されたアイコン)が表示され、カーソルをインスツルメントブロック341の近くへ置くと問題の説明343が表示される。所定の実施形態では、問題を示すために、例えば、設計キャンバスエリア311の背景が赤で薄く彩色される、および/または警告またはエラーメッセージがステータスバーに表示される、等の他の(または追加的な)インジケータが表示されてもよい。
図3Iに示されているように、設計キャンバスエリア311にはインスツルメント属性ブロック344が配置されている。しかしながら、インスツルメントの最良の買い呼び値を提供するように設定されているインスツルメント属性ブロック344に、必要な入力、即ち、最良の買い呼び値を提供すべきインスツルメント名は提供されていない。即ち、インスツルメント属性ブロック344は、インスツルメントブロック(または、インスツルメント名を提供し得る他のブロック)へ接続されていない。従って、アルゴリズム定義は無効である。この場合も、図3Hの場合と同様に、警告インジケータおよび感嘆符が表示される。
図3Jに示されているように、設計キャンバスエリア311にはインスツルメント属性ブロック344およびマーケットメーカ・ブロック345が配置されている。ユーザは、インスツルメント属性ブロック344の出力(数値タイプを伴う連続式出力)を、マーケットメーカ・ブロック345のインスツルメント入力(インスツルメント値タイプを伴う連続式入力)へ接続しようとしている。これらの入力および出力の値タイプは不適合であり、よって、結果としてアルゴリズム定義は無効となる。試行された接続ライン上には、接続が無効であることを示すインジケータ346(この場合は、スラッシュの入った円)が表示されている。さらには、説明347も表示される。連続式出力と不連続入力との間で接続が試行される場合にも、同様のフィードバックが提供されることがある。
図3Kに示されているように、設計キャンバスエリア311には加算器ブロック348aおよび加算器ブロック348bが配置されている。ユーザは、加算器ブロック348bの出力を加算器ブロック348aの入力へ接続しようとしている。しかしながら、加算器ブロック348aの出力が既に加算器ブロック348bへ入力として接続されている。試行されている接続を許容すれば、結果的に、生成されるプログラミングコードにおいて循環依存関係が生じることになる。具体的には、加算器ブロック348aの値を決定するようにプログラミングコードを生成しようとすれば、結果的に無限ループが生じる。したがって、このようなアルゴリズム定義は無効であり、よって、図3Jで規定されたフィードバックと同様に、この接続は無効として示され、説明が表示される。
図3Lに示されているように、設計キャンバスエリア311には発生器ブロック349a、ファンネルブロック349b、値抽出器ブロック349cおよび値積算器ブロック349dが配置されている。ユーザは、値積算器ブロック349dの不連続出力をファンネルブロック349bの不連続入力へ接続しようとしている。しかしながら、ファンネルブロック349b、値抽出器ブロック349cおよび値積算器ブロック349dは各々パススルー・ブロックであり、よって受信される各不連続イベントは対応する不連続出力を介して出される。したがって、発生器ブロック349a(同じくファンネルブロック349bへ接続されている)によって不連続イベントが提供されると、これは、各接続ブロックを通過していく。
試行されている接続を許容すれば、結果的に、生成されるプログラミングコードにおいて無限ループが生じることになる。具体的には、生成されるプログラミングコードは、発生器ブロックにより提供される不連続イベントの処理に際して、不連続イベントを次には処理されるべき各ブロックへと無限に送り、この場合、前記処理は不連続イベントをサイクル内の次のブロックへ提供することを含む。したがって、このようなアルゴリズム定義は無効であり、よって、図3Jで規定されたフィードバックと同様に、この接続は無効として示され、説明が表示される。
所定の実施形態において、警告および/またはエラーメッセージは、取引インタフェース310の別々のエリアに提供されてもよい。これにより、ユーザは、例えば、各ブロックを個々に調べるのではなく、全ての際立った警告およびエラーを即座に見ることができる。
図3M−図3Rは、所定の実施形態による取引インタフェース310を示す。取引インタフェース310は、例えば、クラッタを減らし、アルゴリズム部分の再使用を有効化し(アルゴリズム間で共用され得るモジュールの生成を含む)、仮想化機能を有効化することを可能にするグルーピング機能を提供する。クラッタの低減およびアルゴリズム部分の再使用は、アルゴリズム設計における間違いの可能性を減らすことから、アルゴリズムをより良くすることに繋がる場合がある。以下、仮想化機能の優位点について論じる。
図3Mに示されているように、単純なスキャルピングアルゴリズムの定義が設計されている。大まかに言えば、スキャルピングアルゴリズムは、最良の買い呼び値で買い、次に約定価格より1つ上の取引増分で売って1単位の売り買いにつき1つの取引増分の利益を出す。より具体的には、本アルゴリズムは、買いマーケットメーカ・ブロック351と、売りマーケットメーカ・ブロック352とを含む。買いマーケットメーカ・ブロック351には、インスツルメントブロックによって指定された買うべきインスツルメント(「ESZ0」)が提供される。買いマーケットメーカ・ブロック351には、インスツルメントフィールド・ブロックによって指定される、そのインスツルメントにとって最良の買い呼び値を与える買い価格が提供される。買いマーケットメーカ・ブロック351には、数字ブロックによって指定される、買うべき固定数量10が提供される。買いマーケットメーカ・ブロック351が、受付中の買い注文の約定確認を受信すると、不連続イベントが発生される。
売りマーケットメーカ・ブロック352は、買いマーケットメーカ・ブロック351によって取られたポジションをカバーするように売り注文を働かせる。売りマーケットメーカ・ブロック352には、売るべき同じインスツルメント(「ESZ0」)が提供される。売りマーケットメーカ・ブロック352には、インスツルメントの最小価格増分(インスツルメントフィールド・ブロックにより提供される)を約定価格(値抽出器ブロックにより、約定確認が受信されると買いマーケットメーカ・ブロック351により発生される不連続イベントから提供される)へ加算する加算器ブロックによって指定される売り価格が提供される。売りマーケットメーカ・ブロック352には、買いマーケットメーカ・ブロック351により買われている積算数量を提供する加算器ブロックによって指定された売り数量が提供されるが、これは、買いマーケットメーカ・ブロック351により約定確認が受信されると発生される不連続イベントから抽出される。
したがって、アルゴリズムの実行中、買いマーケットメーカ・ブロック351は、数量10を最良の買い呼び値で購入し、数量10を(恐らくは、複数の売り注文によって)約定価格プラス最小価格増分で売る。
図3Nに示されているように、アルゴリズムの論理部分をカバーすることに関連づけられるブロックは、周囲にボックス353を描くことによって選択されている。ユーザにとって関心のあるブロックを選択するためには、例えば、シフトまたはコントロールキーを押すこととカーソルとの組み合わせによって選択すること等の他のユーザインタフェース技術が用いられてもよい。
ブロックが選択されると、これらは、メニュアイテムの選択等のアクションによってグルーピングされてもよい。
図3Oに示されているように、グルーピングされたブロックは、次に、グループブロック353内にブロックのサムネイル画像が内部に包含された状態で表示される。グループブロック353は、示されるブロックおよび接続の数を減らすことによって設計キャンバスエリア311のクラッタを減らす。さらに、グループブロックは、別のアルゴリズムにロードされて再使用され得るようにモジュールのライブラリに保存されてもよい。グループブロックは、グルーピングされたブロックと称される場合もある。グループブロック内のブロックは、例えば、定義されたアルゴリズムの一部、サブアルゴリズムまたはサブルーチンと称されてもよい。
グループブロック353は、グループブロック353内のブロックの入力に対応する、グループブロック353内に存在しないブロックの出力によって値を提供される入力354を伴って生成されてもよい。例えば、図3Oに示されているように、グループブロック353は、連続式インスツルメント入力と、不連続入力とを有する。連続式インスツルメント入力は、売りマーケットメーカ・ブロック352および最小価格増分を決定するインスツルメントフィールド・ブロックの連続式インスツルメント入力に対応する。不連続入力は、加算器ブロックおよび値抽出器ブロックの不連続入力に対応する。
グループブロック353は選択されてもよく、次に、メニュアイテムの選択またはダブルクリック等のアクションを用いて、グループブロック353に包含されるブロックが編集されてもよい。図3Pに示されているように、設計キャンバスエリア311に類似する設計キャンバスエリアを有する新たなウィンドウが表示され、かつ同様にして操作されてもよい。グループブロック353は、グループブロック353の入力に対応する新たな入力ブロック355および356を含む。入力ブロック355はグループブロック353の連続式インスツルメント入力に対応し、かつ入力ブロック356はグループブロック353の不連続入力に対応する。入力ブロック355および356は各々、グループブロック353の個々の入力へ提供される値を提供する単一の出力を有する。
グループブロック353内のブロックは何れも、グループブロック353より外部のブロックへ接続される出力を持たないことから図3Pには示されていないが、グループブロックは出力ブロックを含む場合もある。先に論じた入力ブロックと同様に、出力ブロックはグループブロックの出力に対応する。出力ブロックへ接続される出力を有するグループブロック内のブロックは、グループブロックの対応する出力へ接続される、グループブロックより外部のブロックへ値を提供する。
グループブロックの設計に際しては、入力ブロックおよび出力ブロックは、グループブロックの入力または出力を生成するように配置されてもよい。配置されると、ユーザは、入力または出力のタイプを指定するようにプロンプトされてもよい。あるいは、入力または出力ブロックは、連続数値等の既定タイプへデフォルトしてもよい。入力または出力ブロックのタイプは、アルゴリズムを設計する間に、ユーザにより、例えば、入力または出力ブロックを選択しかつタイプを入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。同様に、ユーザは、入力または出力ブロック(および延てはグループブロックの対応する入力または出力)の名前を指定する場合もある。
グループブロックは、別のグループブロックを含んでもよい。グループブロックのこのネスティングは、クラッタが減少しかつアルゴリズムの様々な部分の再使用可能性が潜在的に高まることを見込んでいる。
プログラムコードの生成に際して、グループブロックは、設計中のアルゴリズムの主要なCustomAlgorithm0クラス内にネスティングされるアルゴリズムクラスのサブクラスとして生成される。グループブロックが他のグループブロック内にネスティングされる場合、生成されるプログラミングコードも同様に生成される各サブクラスをネスティングする。さらに、非原始ブロックは何れも、その最近のグループブロック・ペアレントにおいて宣言されかつ定義される。よって、例えば、あるグループブロックがグループブロック3段階の深さまでネスティングされ、かつそれが内部にマーケットメーカ・ブロック(非原始ブロックの一例)を有していれば、マーケットメーカ・ブロックのサブクラスは3段階深度で派生されるアルゴリズムクラス内に存在する。
先に論じたスキャルピングアルゴリズムに戻ると、図3Mに示されているように、このアルゴリズムは欠陥を有する。スキャルピングアルゴリズムの目的は、最良の買い呼び値で買い、次に約定価格より1つ上の取引増分で売って1単位の売り買いにつき1つの取引増分の利益を出すことにある点を想起されたい。買いマーケットメーカ・ブロック351が、行っている買い注文の総数量10に対して単一の約定を受信すれば、アルゴリズムは意図された通りに動作する。しかしながら、2つ以上の約定確認が2つ以上の価格レベルで受信されれば、アルゴリズムは望み通りに機能しない。例えば、買いマーケットメーカ・ブロック351が最良の買い呼び値114125で数量10の買い注文を出すものと仮定する。すると、数量3について、第1の約定確認が受信される(よって、第1の約定の対象は約定価格114125における数量3である)。この約定に対して、売りマーケットメーカ・ブロック352は、価格114150(114125(約定価格)+25(最小価格増分))で数量3の売り注文を出す。ここで、最良の買い呼び値が114100に下がるものと仮定する。すると、買いマーケットメーカ・ブロック351は、数量7について、その受付中の注文を新たな(かつ今回はより安い)最良の買い呼び値に付け直す。すると、数量7について、第2の約定確認が受信される(したがって、第2の約定の対象は、約定価格114100で数量7となった)。
したがって、スキャルピングアルゴリズムの行動としては、第1の売り注文を(第1の約定をカバーする)数量3に対して価格114150(114125+25)で行ない、かつ第2の売り注文を(第2の約定をカバーする)数量7に対して価格114125(114100+25)で行なうというのが望ましい。
しかしながら、図3Mに示されているアルゴリズムは、望ましい行動を達成すべく適切な発注をしない。第1の約定が受信されると、売りマーケットメーカ・ブロック352は、数量3を価格114125+25で売る第1のカバー注文を出す。しかしながら、第1のカバー注文が約定される前に第2の約定が受信されれば、加算器ブロック(数量10が既に約定されていることを反映して更新される)からクオートするために新たな数量を受信する売りマーケットメーカ・ブロック352は、数量10に対し価格114100+25(最新の約定(第2の約定)価格プラス最小価格増分)でカバー注文を出す。必然的に、第1の約定は、所望される価格ではカバーされない(これは、意図されない、かつ/または望ましくない行動である)。この場合、カバー注文が完全に約定されれば、アルゴリズムの望ましい行動の対象が受信される各約定に特有の価格および数量で出されるべきカバー注文であるとしても、カバー注文の全体数量10は同じ価格で約定される。
取引アプリケーション300の仮想化機能は、この種の問題に対処する。グループブロックが選択されてもよく、次に、メニュアイテムの選択等のアクションを用いて、グループブロックは仮想化されるものと指定されてもよい。図3Qに示されているように、グループブロック353は仮想化されていて、これがグループブロック353の境界を実線から破線に変えることによって示されている。所定の実施形態において、グループブロックは仮想化されていることを、例えばブロック名にテキストを付加する、境界色、背景色または背景パターンを変える、等の他の方法で示されてもよい。
仮想化されたグループブロックのインスタンスは、仮想化されたグループブロックへ提供される不連続イベント毎に生成される。即ち、仮想化されたグループブロックにおいて不連続イベントが受信される度に、その不連続イベントを取り扱うべく仮想化されたグループブロックの新たなインスタンスが生成される。これは、先に論じた、各不連続イベントはその不連続イベントに特有の情報を基礎としてグループブロックの論理によって扱われる、という望ましい行動に対処するものである。上述の例の説明を続けると、但し、グループブロック353が仮想化されることに特化して言えば、約定のために買いマーケットメーカ・ブロック351によって発生される各不連続イベントにより、結果的に、仮想化されたグループブロック353の新たなインスタンスがその特定の不連続イベントを扱うために生成される。
したがって、新たなインスタンスを生成させるものが仮想化されたグループブロックへ不連続イベントを知らせるものであることから、仮想化されるべきグループブロックは悉く不連続イベント入力を持たなければならない。仮想化されたグループブロックが一旦インスタンス化されると、その特定のインスタンスはそれ以後、その範囲の外から(即ち、仮想化されたグループブロック内に存在しないブロックから)不連続イベントを受信しない。代わりに、仮想化されたグループブロックの範囲外からのこれに続く不連続イベントは何れも、仮想化されたグループブロックの新たなインスタンスを生成させることになる。しかしながら、不連続イベントは依然として発生されて仮想化されたグループブロック内のブロックによって処理される場合があり、よって、仮想化されたグループブロック内部で発生される不連続イベントは仮想化されたグループブロックの不連続入力へ提供される場合がある。図3Rは、買いマーケットメーカ・ブロック351によって3つの不連続イベントが発生されている場合に、アルゴリズム論理がどのように機能するかを概念的に示している。グループブロック353の3つのインスタンスは、買いマーケットメーカ・ブロック351からの3つの不連続イベントの各々に応答してインスタンス化されている。表示されているアルゴリズムは、事実上単に図3Qに示されているような単一の仮想化されたグループブロック353を示すだけであること、および図3Rに示されている3つのインスタンスは単にグループブロック仮想化の概念を表すために示されていることに留意されたい。所定の実施形態において、グループブロックのインスタンスの数は表示されてもよい。例えば、インスタンスの数は、図3Rに示されているものに類似する方法でグラフィカルに、仮想化されたグループブロックの積層を示すことによって表示されてもよく、この場合、積層のサイズがインスタンス化されている仮想化されたグループブロックのインスタンス数を表す。別の例として、インスタンスの数は、グループブロック内(角等)に表示される、インスタンス化されている仮想化されたグループブロックのインスタンス数の計数として表現される数字によって示されてもよい。
さらに、連続式出力のような出力の値は意味論的に定義されないことから、仮想化されたグループブロックは連続式出力を有することができない(但し、不連続出力を有することはできる)。これは、仮想化されたグループブロックのインスタンスは2つ以上存在する場合があり(または、そのための不連続イベントがまだ受信されていなければ、インスタンスが存在しない可能性もある)、よって、このような連続式出力は異なる値を同時に有する可能性も、場合もある(または、全く値が存在しない)ことに起因する。さらに、変数は仮想化されたグループブロックがインスタンス化されるまでは「存在」しないはずであることから、仮想化されたグループブロックは、変数として指定されるブロックを含まない場合もある。
仮想化されたグループブロックは、先に論じたようにグループブロックがネスティングされ得るのと同様に、別のグループブロックまたは別の仮想化されたグループブロックを包含してもよい。
プログラミングコードの生成に際して、仮想化されたグループブロックは、先に論じたような非仮想化グループブロックと同様にアルゴリズムクラスのサブクラスとして生成される。しかしながら、当初は空である仮想化されたグループブロックのサブクラスのリストである主たるCustomAlgorithm0クラスが保持されている場合、および仮想化されたグループブロックに対応するサブクラスへ不連続イベントが提供されることになっている場合にインスタンス化されるのではなく、仮想化されたグループブロックのサブクラスの新たなインスタンスが生成される。
クライアントデバイスとアルゴリズムサーバとの間のネットワーク接続は、不意に切断されることがある。例えば、クライアントデバイスによってアルゴリズムサーバへ接続するために使用されるインターネット・サービス・プロバイダ(「ISP」)はルータの故障または通信リンクの物理切断を経験することがあり、これにより、クライアントデバイスとアルゴリズムサーバとの間の通信が遮断される場合がある。別の例として、ネットワーク内の中間ノードは故障することがあり、同じくクライアントデバイスとアルゴリズムサーバとの間の通信が遮断される。別の例として、クライアントデバイスは機能停止することがあり、アルゴリズムサーバへの接続が遮断される。現行システムの場合、このような接続が遮断されると、アルゴリズムは停止するか、接続が遮断されていることを認識せずに実行を続ける。前者の場合、トレーダは、容易には(または、接続がダウンしていることから可能性としては全く)抜け出せないオープンポジションのままにされることがある。後者の場合、トレーダは、もはや正しく動作していない、または市場における状態変化にとって不相応であり得るアルゴリズムのパラメータの修正も、アルゴリズムのシャットダウンも、停止もできないことがある。しばしば、トレーダは、極めて危険であり得るアルゴリズムを実行し、よって即座にこれをオフにできる、またはパラメータを変更できるように望むかもしれない。
所定の実施形態において、1つまたは複数のブロックは、クライアントデバイスとアルゴリズムサーバとの接続状態を認識するように指定されることが可能である。例えば、配置されると、ユーザは、クライアントデバイスとアルゴリズムを実行するアルゴリズムサーバとの接続が切断される場合でもブロックが実行を続けるように指定するオプションを提示されてもよい。また、このオプションは、ブロックを選択しかつメニュアイテムまたはキーボードのコマンド等のアクションを使用することによって指定される場合もある。デフォルトを使用すれば、アルゴリズムは、クライアントデバイスとアルゴリズムサーバとの接続が遮断されると休止または停止する場合がある。所定の実施形態において、アルゴリズム全体は、クライアントデバイスとアルゴリズムを実行するアルゴリズムサーバとの接続が切断されても実行を続けるように指定される。
例えば、マーケットメーカ・ブロックは、クライアントデバイスとアルゴリズムサーバとの接続が遮断されても、マーケットメーカ・ブロックによって発生される注文を市場にキープするためのオプションを有する場合がある。アルゴリズムのヘッジングまたはカバー注文部分に使用されているマーケットメーカ・ブロックは、これらの注文を出すアルゴリズムの一部が接続の遮断に起因してもはや実行を止めていても、アルゴリズムの別の部分によってとられているポジションは望み通りにヘッジまたはカバーされるように、この方法で設定されてもよい。
所定の実施形態では、クライアントデバイスとアルゴリズムサーバとの接続の状態を表す連続式ブール出力を提供する入力ブロックが、設計中のアルゴリズムへ追加されてもよい。ブロックは次に、この接続状態入力ブロックからの値を、その行動を制御するための入力として取得してもよい。例えば、接続状態入力ブロックは、接続状態が「真」である(接続されていることを表す)場合にのみマーケットメーカ・ブロックが注文を出すように、マーケットメーカ・ブロックの条件付き入力へ接続されてもよい。
アルゴリズムは、取引インタフェース310において定義されると保存されてもよい。また、アルゴリズムには(例えば、アルゴリズムの構築中および/またはアルゴリズムが保存される際に)名前が与えられてもよい。よって、保存されたアルゴリズムは、後に取引インタフェース310または別の取引インタフェースによって呼び出され、または参照されてもよい。例えば、保存されたアルゴリズムは、別の注文に関して編集または再使用され得るように取引インタフェース310によってロードされてもよい。別の例として、保存されたアルゴリズムは、後述するように別の取引インタフェースから1つの注文タイプとして参照されてもよい。
先に論じた取引インタフェース310のコンポーネント、エレメントおよび/または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび/またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、CD−ROM、DVD、EPROMおよび/またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
IV. アルゴリズムの立ち上げおよび管理
所定の実施形態は、選択されたアルゴリズムによってある注文タイプとして管理されるべき発注の開始に備える。所定の実施形態は、値軸から選択されるユーザ定義取引アルゴリズムによって管理されるべき発注の開始に備える。所定の実施形態は、アルゴリズムがある注文を管理している間にアルゴリズムの変数を変更することに備える。所定の実施形態は、アルゴリズムによって管理されている注文を手動で修正することに備える。所定の実施形態は、非管理注文へその注文を管理するためのアルゴリズムを割り当てることに備える。所定の実施形態は、異なるユーザ定義取引アルゴリズムによって管理されている受付中の注文を値軸へ表示することに備える。
図4A−図4Fは、所定の実施形態による取引インタフェースを示す。図4Aに示されているように、取引インタフェース410は、保存されたアルゴリズムが注文タイプとして選択されることを可能にする注文チケットである。保存されたアルゴリズムは、例えば、先に論じた取引インタフェース200および310に類似する取引インタフェースを用いて保存されている場合もある。
保存されたアルゴリズムは選択インタフェース415を用いて選択されてもよく、選択インタフェース415は、図示されているように、標準的な注文タイプ(リミットおよび成り行き等)並びに保存されたアルゴリズムの双方を含むドロップダウン・リストを提供する。所定の実施形態において、選択インタフェース415は、利用可能な保存されたアルゴリズムから選択するための他の要素を含む。例えば、選択インタフェース415は、特定のアルゴリズムについてブラウズするためにファイルナビゲータを開いてもよい。別の例として、選択インタフェース415は、アルゴリズムのタイプを基礎として階層に分類されている保存されたアルゴリズムのツリー表示を含んでもよい。
取引インタフェース420は、やはり、保存されたアルゴリズムが選択インタフェース415により注文タイプとして選択されることを可能にする単純化された注文チケットである。
注文が取引インタフェース410または420から開始され、かつ保存されたアルゴリズムが注文タイプとして選択されると、注文は選択されたアルゴリズムに従って管理される。選択されたアルゴリズムが取引インタフェースからパラメータ(注文チケット価格または数量等)を取得するように設定されていれば、取引インタフェース410または420において指定される値は、実行中のアルゴリズムへ提供される。
図4B−図4Cに示されているように、選択インタフェース415を用いてアルゴリズム注文タイプが選択された後、取引インタフェース430(先に論じた取引インタフェース410に類似する注文チケットスタイル取引インタフェース)および取引インタフェース440(市場深さラダーまたは軸スタイル取引インタフェース)が示される。この場合、選択されたアルゴリズムは図2Iに示されているものに類似する。取引インタフェース440は、取引可能オブジェクトの価格レベルに対応する、またはこれを基礎とする値を含む値軸を含んでもよい。値は、例えば、取引可能オブジェクトの価格(価格軸におけるもの等)であってもよい。値軸沿いには、値軸内の値に対応する価格レベルで入手可能な数量等の取引可能オブジェクトに関連する情報も表示される場合がある。アルゴリズムの変数は各々変数エリア435および445に示され、かつ注文を開始する前に変更されてもよい。変数エリア435は、取引インタフェース430内へ同じウィンドウの一部として組み込まれる。変数エリア445は、取引インタフェース440へ別のウィンドウとして組み込まれる。変数エリア435および445における変数は、図2Iに示されているように、変数エリア206のデフォルト値カラム272に指定される値へデフォルトする。変更されると、開始された注文は、変更された変数値によって選択されたアルゴリズムに従って受け付けられる。
図4Dに示されているように、取引インタフェース450は、市場において受け付けられている注文を示す注文帳である。ここでは、アルゴリズム(同じく、図2Iに示されているものに類似する)に従って受け付けられている注文451が選択される。アルゴリズムの変数は変数エリア455(変数エリア435および445に類似する)に示され、かつ変更されてもよい。変更され(かつこの変更が適用され)ると、アルゴリズムは、変更された変数値に従って実行を続ける。変数の変更は、アルゴリズムを休止または停止することなく有効となる。
所定の実施形態において、取引インタフェース450は、アルゴリズムによって管理されている注文をユーザが手動で修正できるようにする。例えば、ユーザは、注文の価格または数量を変更しても、注文を削除してもよい。これに対して、注文を管理するアルゴリズムは、例えば、注文価格を変更してもよく、注文数量を変更してもよく、何もしなくてもよく、また、単にアルゴリズム定義に従って使用するために手動修正に基づく新たな情報またはしきい値を保有するだけで新たなアクションは実行しなくてもよい。
所定の実施形態において、取引インタフェース450は、アルゴリズムによって管理されるものではない注文(例えば、手動入力される注文)を含んでもよい。この管理されない注文は選択されてもよく、かつこれにアルゴリズムが適用されてもよい。例えば、ユーザは管理されない注文を選択し、かつメニュアイテムまたはキーボードコマンド等のアクションを用いて選択された管理されない注文へ適用する利用可能なアルゴリズムのリストを提示されてもよい。利用可能なアルゴリズムのリストは、例えば、注文ブロックを含む保存されたアルゴリズムを含んでもよい。選択された管理されない注文へ適用されると、選択されたアルゴリズムは、次に、アルゴリズムに従って注文を管理してもよい。別の例として、ユーザは、管理されない「取り消すまで有効」(「GTC」)注文を選択し、かつ将来の取引セッションに渡ってアルゴリズムが注文を管理し得るように、選択されたアルゴリズムをこの注文に適用してもよい。
図4Eに示されているように、取引インタフェース460は、先に論じた取引インタフェース440に類似する市場深さラダーまたは軸スタイル取引インタフェースである。幾つかの注文が開始されていて、異なる価格レベルで受け付けられていることが示されている。注文461は第1のアルゴリズムによって管理されるように開始され、かつ注文462は第2のアルゴリズムによって管理されるように開始された。したがって、取引インタフェース460は、同じアルゴリズムに従って管理される複数の受付中の注文を表示する単一のインタフェースを用意する。さらに、取引インタフェース460は、複数のアルゴリズムに従って管理される受付中の注文を表示する単一のインタフェースも用意する。
所定の実施形態において、特定のアルゴリズムに従って管理される受付中の注文は共通して識別される。例えば、第1のアルゴリズムに関連づけられる受付中の注文は各々、例えば、特定の背景色、前景色、背景パターン、境界色、境界スタイル、形状、記号、数字、テキストおよび/またはフォントによってグラフィックに識別されてもよい。次に、第2のアルゴリズムに関連づけられる受付中の注文は、例えば、異なる色、パターン、境界、形状、記号、数字、テキストおよび/またはフォントを用いて識別されてもよい。
所定の実施形態において、特定のアルゴリズムに従って管理される受付中の注文は個々に識別される。例えば、同じアルゴリズムの異なるインスタンスに関連づけられる受付中の注文は各々、そのアルゴリズムの異なるインスタンスに関連づけられる他の受付中の注文から、色、パターン、境界、形状、記号、数字、テキストおよび/またはフォント等の識別子によって区別されてもよい。アルゴリズムの第1のインスタンスに従って管理される注文は、その受付中の注文インジケータの角に数字「1」を有してもよく、一方で、アルゴリズムの第2のインスタンスに従って管理される注文は、その受付中の注文インジケータの角に数字「2」を有してもよい。特定のアルゴリズムの異なるインスタンスによって管理される受付中の注文の表示は、先に論じた異なるアルゴリズムによって管理される受付中の注文の表示と組み合わせて適用されてもよい。
図4Fに示されているように、取引インタフェース470はアルゴリズムマネージャである。また、取引インタフェース470は、コックピットまたはダッシュボードと称される場合もある。取引インタフェース470は、利用可能なアルゴリズムのリスト471を含む。リスト471からは、特定のアルゴリズムが選択されてもよい。アルゴリズムが選択されると、選択されたアルゴリズムのビューが表示エリア472に表示され、かつ選択されたアルゴリズムの実行中のインスタンスのリスト473も表示される。図示されているように、表示エリア472は、先に論じた取引インタフェース310に類似する取引インタフェースを用いて作成されたアルゴリズム定義を示してもよい。しかしながら、表示エリア472は、先に論じた取引インタフェース200に類似する取引インタフェースを用いて定義されたアルゴリズムのビューも表示してもよい。選択されたアルゴリズムの実行中のインスタンスのリスト473は、実行中のインスタンスに関する、例えば、その開始時間、そのポジション、ステータス、損益、受付中の注文数、約定された注文数、最近に発注されかつ/または約定が受信されたインスツルメントおよび/または注文口座情報等の情報を含んでもよい。
さらに、変数エリア474は、選択されたアルゴリズムの変数、および選択されたアルゴリズムの選択されたインスタンスに関するこれらの変数の値を表示する。変数エリア474は、先に論じた変数エリア435、445および455に類似する。選択されたアルゴリズムの選択されたインスタンスの変数は、変更されてもよい。変更され(かつこの変更が適用され)ると、アルゴリズムは、変更された変数値に従って実行を続ける。変数の変更は、アルゴリズムを休止または停止することなく有効となる。
所定の実施形態において、取引インタフェース200、290、310、410、420、430、440、450、460および/または470等の取引インタフェースは、アルゴリズムによって管理される注文が取引セッションのクローズにおいて約定されていない場合にユーザが行動を指定できるように適合化される。例えば、取引インタフェースは、アルゴリズムによって管理される約定されていない注文がキャンセルされてアルゴリズムが停止されることをユーザが指定できるようにしてもよい。別の例として、取引インタフェースは、アルゴリズムによって管理される約定されていない注文が、次の取引セッションの開始時において引き続き管理されることをユーザが指定できるようにしてもよい。別の例として、取引インタフェースは、アルゴリズムによって管理される約定されていない注文が、次の取引セッションの開始時において休止され、かつユーザにより休止されない場合は管理されることを再開するようにユーザが指定できるようにしてもよい。
先に論じた取引インタフェース410、420、430、440、450、460および470のコンポーネント、エレメントおよび/または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび/またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、CD−ROM、DVD、EPROMおよび/またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
V. ランキングツール
図5は、所定の実施形態によるランキングツール500を示す。ランキングツール500は、例えば、ヘッジオプションをランク付けするために用いられてもよい。先物取引において、最も一般的な戦略の1つは「スプレッド取引」をすることである。これは、あるインスツルメントに市場指向性のリスクエクスポージャを有するトレーダが、1つまたはそれ以上の同様のインスツルメントの取引を行うことにより、自らのリスクの変数を相殺し、最小限に抑え、または減らしてそのリスクを回避しようとする方法である。2つのポジションが開始される時点での2つの価格は、コンビネーション価格またはスプレッド価格を生成する。よってトレーダは、最終的に、オープンポジションを、好適には、ポジションを開始した価格から利益を生み出すスプレッド価格差でアンワインドする取引の実行を試行してもよい。
幾つかの自動化された取引プログラムの場合、トレーダのリスクを自動的に回避するヘッジ技法を実行することができる。このヘッジ技法は、ある特定のインスツルメントにおいてヘッジするように自動化される場合もあれば、予めプログラムされた方法に従ってインスツルメントの複数の選択肢から選択するようにプログラムされる場合もある。しかしながら、カレントシステムは、インスツルメントの既定の選択肢に結びつけられないヘッジング取引を用意していない。
特にマーケットメーカにとって、自動化されていないスプレッド取引ポジションを開始する困難さは、技術の速度利得に起因して、取引を最も効率的にヘッジする機会を得ることが極めて困難になっていることにある。市場において役割を果たすその流動資産の性質に起因して、マーケットメーカは、彼らが取引相手に流動資産を与えている(即ち、取引を実行されている)という認識または覚悟に気づかされないことが多い。突然にオープン取引ポジションを入手する場合のあるマーケットメーカまたは任意のトレーダにとって、スプレッドの最初のレッグが開始される時点と、トレーダがこの取引をヘッジできる時点との時間差は、効率的なヘッジングおよびリスク管理にとって重大な不利益となっている。取引を迅速にヘッジすることができないトレーダは、何百、何千、または何百万ドルさえも失う場合がある。トレーダは、ヘッジするにはどのインスツルメントが最良のインスツルメントであるかを決定するために時間を費やさなければならないだけでなく、ヘッジ取引も実行しなければならない。
所定の実施形態は、スプレッドポジションを最適に生成するために(但し、生成に限定されない)取引の手動でのヘッジングにおいて2つの顕著な速度的優位点をもたらすランキングツール500を提供する。第1の態様は、任意の特定の瞬間における売りまたは買いにとってどの契約が最も効果的なインスツルメントであるかを選好順に決定するために、予めプログラムされたパラメータ方法によって絶えず分析されるインスツルメントグループをユーザに事前選択させる。ある実施形態では、この技法は、プログラムが考察しているインスツルメントに関して、既存のスプレッド市場における様々な売り/買いレベルを分析するように実装されることが可能である。別の実施形態では、これは、トレーダの全体的リスクを最も下げることにおいてどのヘッジ取引がトレーダをアシストするかを決定するために、トレーダの取引在庫ポジションに注目する場合がある。実際には、システムの実行プロセスの背後には無限の方法が存在する。トレーダは、この情報を使用して、リスクヘッジの対象としてのインスツルメントを決定するために要する時間を省くことができる。
どのインスツルメントが最適なヘッジを提供するかを自動的に分析する能力に加えて、ランキングツール500の別の態様は、これを、前述の予めプログラムされたヘッジング方法に従って市場で利用可能な「最良の」ヘッジまたはヘッジグループを実行すべく売買注文または注文グループを事実上自動入力するために使用できることにある。トレーダに要求される唯一の潜在的アクションは、考慮対象のインスツルメントを予め選択し、希望数量を入力し(事前設定が可能)、かつ取引インタフェース上の売り、または買い実行ヘッディングをクリックすることである。この自動ヘッジャにより、トレーダには、トレーダが希望するランキング方法と整合する効果的なスプレッド価格で積算されるべき様々なヘッジされた取引在庫が残る。ランキングツール500は、広範な市場環境下ではヘッジが困難となる可能性もある取引を実行するという危険を冒す全てのトレーダにとって有益である。
ランキングツール500は、分析用にユーザが識別または選択できる取引可能オブジェクトのリストを備える選択エリア510を含む。図示されている例では、取引可能オブジェクトとして様々な月例向けのユーロドル先物がリストされている。「最良」のカラム(最良買い520および最良売り530)は、選択されたインスツルメントをランク順に表示し、本例において買い520はカレント売り呼び値を基に、また売りはカレント買い呼び値を基にランク付けされている。
ランキングツール500の注文チケット部分540は、ユーザがランキングシステムに従って売り買いする数量を入力できるようにする。売り、買いボタンは、希望するインスツルメントの自動実行を可能にする。このシステムの場合、ユーザは、一位にランクされたインスツルメントのみを売り/買いする選択、選択されたインスツルメントを全て約定する選択、または必要に応じてループする選択を含む様々な選択肢550を有する。例えば、トレーダの希望数量が一位のインスツルメントで入手可能な数量では満たされない場合、ランキングツール500は、そのインスツルメントのリミット注文を初期価格で出すことができる。さらに積極的なアプローチは、どんな量であれ一位のインスツルメントで入手可能な数量を実行し、かつ必要に応じて次の契約の自動ヘッジへ移行することである。自動実行は、単にリストの最後(本例では第5位)まで作用し、かつ、関連数量がまだ満たされていなければ、リストされている高位の全月例を通じて取引することによってリミット注文を出す。ランキングツール500は、純粋な成り行き注文が存在する場合等、必要に応じてループすることができ、アプリケーションは、リスト上位で再び開始しながら利用可能な次の価格へと続く。
先に論じたランキングツール500のコンポーネント、エレメントおよび/または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび/またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、CD−ROM、DVD、EPROMおよび/またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
VI. コンピューティングデバイス例
図6は、所定の実施形態によるコンピューティングデバイス600を示すブロック図である。クライアントデバイス110は、例えば、1つまたは複数のコンピューティングデバイス600を含んでもよい。クライアントデバイス301は、例えば、1つまたは複数のコンピューティングデバイス600を含んでもよい。アルゴリズムサーバ302は、例えば、1つまたは複数のコンピューティングデバイス600を含んでもよい。ゲートウェイ120は、例えば、1つまたは複数のコンピューティングデバイス600を含んでもよい。取引所130は、例えば、1つまたは複数のコンピューティングデバイス600を含んでもよい。取引所303は、例えば、1つまたは複数のコンピューティングデバイス600を含んでもよい。
コンピューティングデバイス600は、バス610と、プロセッサ620と、メモリ630と、ネットワークインタフェース640と、ディスプレイデバイス650と、入力デバイス660と、出力デバイス670とを含む。コンピューティングデバイス600は、追加的な、異なる、またはこれより少ないコンポーネントを含んでもよい。例えば、複数のバス、複数のプロセッサ、複数のメモリデバイス、複数のネットワークインタフェース、複数のディスプレイデバイス、複数の入力デバイス、複数の出力デバイスまたはこれらの任意の組合せが設けられてもよい。別の例として、コンピューティングデバイス600は、ディスプレイデバイス650から分離した出力デバイス670を含まなくてもよい。別の例として、コンピューティングデバイス600はディスプレイデバイス650を含まなくてもよい。別の例として、コンピューティングデバイス600は入力デバイス660を含まなくてもよい。代わりに、例えば、コンピューティングデバイス600は、外部またはリモート入力デバイスによりネットワークインタフェース640を介して制御されてもよい。
バス610は、コンピューティングデバイス600内のコンポーネント間でデータを通信するための通信バス、チャネル、ネットワーク、回路、スイッチ、ファブリックまたは他の機構を含んでもよい。バス610は、コンピューティングデバイス600の任意のコンポーネントと通信で結合されかつ前記任意のコンポーネントとの間でデータを転送してもよい。例えば、取引アプリケーションのインストールプロセスの間、プロセッサ620によって実行されるべき1つまたは複数のコンピュータ読取り可能命令が入力デバイス660および/またはネットワークインタフェース640からメモリ630へ転送されてもよい。コンピューティングデバイス600がメモリ630に格納された取引アプリケーションを実行している、または実行する準備をしているとき、プロセッサ620は、メモリ630からバス610を介して命令を検索してもよい。
プロセッサ620は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールド・プログラマブル・ゲートアレイ、アナログ回路、デジタル回路、プログラムプロセッサ、これらの組合せ、または現時点で既知である、または今後開発される他の処理デバイスを含んでもよい。プロセッサ620は、ネットワークまたは分散処理関連等の単一のデバイスであっても、デバイスの組合せであってもよい。処理戦略は、例えば、マルチ処理、マルチタスク、平行処理および/またはリモート処理等の任意のものが用いられてもよい。処理はローカルであってもリモートであってもよく、かつ1つのプロセッサから別のプロセッサへ移動されてもよい。
プロセッサ620は、メモリ630等の1つまたは複数の有形媒体において、かつ/またはネットワークデバイス640を介して符号化された論理を実行する働きをしてもよい。本明細書において、1つまたは複数の有形媒体において符号化される論理は、プロセッサ620または異なるプロセッサによって実行され得る命令を含む。論理は、例えば、ソフトウェア、ハードウェア、集積回路、ファームウェアおよび/またはマイクロコードの一部として格納されてもよい。論理は、外部通信デバイスから、例えばインターネットへ接続される通信ネットワークを介して受信されてもよい。プロセッサ620は、図示されている、または本明細書に記述されている機能、行動またはタスクを実行するために論理を実行してもよい。
メモリ630は、例えば、コンピュータ読取り可能記憶媒体等の有形媒体であってもよい。コンピュータ読取り可能記憶媒体には、ランダムアクセスメモリ、読取り専用メモリ、プログラム可能読取り専用メモリ、電気式プログラム可能読取り専用メモリ、電気式消去可能読取り専用メモリ、フラッシュメモリ、磁気テープまたはディスク、光媒体、これらの任意の組合せ、または現時点で既知である、または今後開発される他の有形データ記憶デバイスを含む、但しこれらに限定されない様々なタイプの揮発性および不揮発性記憶媒体が含まれてもよい。メモリ630は、単一のデバイスまたは複数のデバイスを含んでもよい。例えば、メモリ630は、ランダムアクセスメモリおよびハード・ドライブ・ストレージを含んでもよい。メモリ630は、プロセッサ620に隣接しても、これの一部であっても、これによってプログラムされても、これとネットワークで結ばれても、かつ/またはこれより遠隔であってもよく、よって、メモリ630に格納されるデータは、例えばプロセッサ620によって検索されかつ処理されてもよい。
メモリ630は、プロセッサ620によって実行可能な命令を格納してもよい。命令は、本明細書に記述されている、または図示されている行動または機能のうちの1つまたはそれ以上を達成するために実行されてもよい。
ネットワークインタフェース640は、一方向の通信カップリングであっても、双方向の通信カップリングであってもよい。したがって、ネットワークインタフェース640は、1つ、2つまたはそれ以上の通信ネットワークまたはデバイスを通信で接続してもよい。例えば、バス610は、ネットワークインタフェース640を介して先に論じたゲートウェイ120に類似するゲートウェイとカップリングされてもよく、よって、コンピューティングデバイス600の1つ、幾つかまたは全てのコンポーネントはゲートウェイによってアクセス可能であり、またはゲートウェイと通信することができる。別の例として、ネットワークインタフェース640は、バス610を他の通信ネットワークとカップリングしてもよい。ネットワークインタフェース640は、例えば、データ通信接続を提供するための統合サービスデジタル網(ISDN)カードまたはモデムであってもよい。別の例として、ネットワークインタフェース640は、例えばインターネットへ接続される互換性LANへデータ通信接続を提供するためのローカル・エリア・ネットワーク(LAN)カードであってもよい。また、無線リンクも実装される場合がある。ネットワークインタフェース640は、例えば、様々なタイプの情報を表現するアナログまたはデジタル・データ・ストリームを伝送する電気的、電磁的または光学信号を送受信してもよい。
ディスプレイデバイス650には、例えば、視覚的出力デバイス、陰極線管(CRT)ディスプレイ、電子ディスプレイ、電子ペーパ、フラットパネル・ディスプレイ、発光ダイオード(LED)ディスプレイ、エレクトロルミネッセントディスプレイ(ELD)、プラズマ・ディスプレイ・パネル(PDP)、液晶ディスプレイ(LCD)、薄膜トランジスタディスプレイ(TFT)、有機発光ダイオードディスプレイ(OLED)、表面伝導型電子放出素子ディスプレイ(SED)、レーザテレビ、カーボンナノチューブ、ナノ結晶ディスプレイ、ヘッドマウント・ディスプレイ、プロジェクタ、三次元ディスプレイ、透過型ディスプレイデバイスおよび/または現時点で既知である、または今後開発される他のディスプレイが含まれてもよい。
ディスプレイデバイス650は、取引画面を表示するように適合化される。取引画面は、例えば、先に論じた取引画面に類似するものであってもよい。取引画面は、双方向性であってもよい。双方向性の取引画面は、例えば、1つまたは複数の取引アクションが取引画面を用いて実行されることを可能にしてもよい。例えば、双方向性の取引画面は、1つまたは複数の注文エントリパラメータが1つまたは複数の注文エントリアクションを用いて設定されかつ/または送信されることを可能にしてもよい。ディスプレイデバイス650および/または入力デバイス660は、例えば、取引画面と相互作用するために用いられてもよい。
入力デバイス660には、例えば、キーボード、マウス、マイクロホン、タッチスクリーン、トラックボール、キーパッド、ジョイスティックおよび/または入力を提供するための他のデバイスが含まれてもよい。入力デバイス660は、例えば、プロセッサ620へコマンドセレクションを提供するために用いられてもよい。例えば、入力デバイス660は、取引画面に表示されるカーソルを制御するために用いられるマウスであってもよい。マウスは、例えば、選択および制御用の1つまたは複数のボタンを含んでもよい。
出力デバイス670には、例えば、キーボード、マウス、スピーカ、タッチスクリーン、トラックボール、キーパッド、触覚デバイスまたはシステム、ジョイスティックおよび/または出力を提供するための他のデバイスが含まれてもよい。例えば、出力デバイス670は、触覚信号または可聴信号等の1つまたは複数の信号をユーザへ出力するために用いられてもよい。
所定の実施形態を参照して本発明を説明してきたが、当業者には、発明の範囲を逸脱することなく様々な変更が行われ、かつ同等物での置換が行われ得ることが理解されるであろう。さらに、特定の状況または材料に適応するために、本発明の教示内容には、その範囲を逸脱することなく多くの修正が行われてもよい。したがって、本発明は開示された特定の実施形態に限定されず、クレームの範囲内にある全ての実施形態を含むことが意図されている。