暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）

发明者量化-小小梦

フォローダイレクトメッセージ

フォロー

1271

フォロワー

暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）

作成日:: 2021-04-19 14:16:21, 更新日:: 2024-12-04 21:21:43

4006

暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）

前回の記事では、プログラムによる取引スクリプトについて説明しました。実際、トレーディング戦略はトレーディングスクリプトプログラムです。この記事では主に、トレーディングスクリプトプログラム用のハードウェアキャリア（プログラムが実行される場所）の必要性、このスクリプトトレーディングプログラムを書くために使用できるコンピュータプログラミング言語（リスト）について説明しています。 Inventor Quantitative Trading Platform の使用には 3 つのプログラミング言語があります。もちろん、任意のプログラミング言語を使用して、プログラムによる取引の戦略を実装できます。この記事では、暗号通貨界の定量分析について引き続き議論し、暗号通貨界の定量分析の知識を理解します。

プログラムによる取引スクリプト

取引戦略の種類プログラム取引や定量取引に不慣れな初心者は、トレンド戦略、裁定取引戦略、高頻度戦略、グリッド戦略などのさまざまな用語に混乱するかもしれません。実際、プログラム取引と定量取引の一般的な戦略タイプは、次のように説明されています: いくつかの方向。
- 裁定ヘッジ戦略簡単に言えば、基本的に、一方でロングポジションを保持し、他方でショートポジションを保持する戦略は、アービトラージ戦略として分類できます。クロススポット市場、クロス先物期間、スポット先物アービトラージ、クロスプロダクトアービトラージなど、具体的なタイプは多数あります。
- トレンド戦略簡単に言えば、二重移動平均線やMACDなどのトレンドに沿って注文を出し、ポジションを保持する戦略です。
- 回帰戦略たとえば、グリッド戦略では、不安定な市場での価格変動から利益を得ることができます。
- 高頻度戦略簡単に言えば、市場の微細構造、ルール、機会などを発見するためにいくつかのアルゴリズムを介して高頻度取引を行う戦略です。

上記は取引戦略の観点から分類したものですが、Inventor Quantitative Trading Platform の戦略設計の観点からは、戦略は次のように分類することもできます。

単一製品戦略つまり、この戦略では、BTC 取引や ETH 取引など、1 つの商品のみを操作します。
マルチプロダクト戦略簡単に言えば、戦略ロジックに従って複数の品種を運用することです。
マルチアカウント戦略簡単に言うと、実ディスク上に複数の交換オブジェクトを構成することです（交換の概念は前回の記事で紹介しており、API KEY が設定された交換オブジェクトは交換アカウントを表します）。例えば、コピートレード戦略の中には、複数の口座（同じ取引所の場合もあれば、異なる取引所の場合もあります）で操作を実行するものがあります。つまり、複数の取引所オブジェクト（口座）を 1 つの実口座で管理することになります。
複数のロジック戦略例えば、実際の市場では、MACD戦略、移動平均戦略、グリッド戦略などが同時に設計されています（もちろん、それらは異なる取引所オブジェクトで動作します。同じ取引所オブジェクトを操作する場合は、特定の戦略には論理的な矛盾がある）
Exchange APIインターフェースプログラムされた取引スクリプトはどのようにして取引口座を操作するのでしょうか?答えは、取引所が公開した API インターフェースを通じて得られます。では、取引所にどのような種類のインターフェースが開かれているのでしょうか?前回の記事では、「Exchange」セクションについて説明しました。このセクションでは、Exchange には一般に REST および Websocket インターフェースがあることを説明しました。ここでは、戦略プログラムレベルからいくつかの概念を追加します。 Exchange インターフェースは、検証されているかどうかによって、検証済みと非検証済みの 2 種類に分けられます (REST と Websocket の両方)。
- 認証を必要としないインターフェース一般的に「パブリックインターフェース」と呼ばれるこのタイプのインターフェースは検証を必要としませんAPI KEY（API KEYが何であるかを忘れた場合は、前の記事を参照してください）。このタイプのインターフェースは、通常、ディープマーケット情報のクエリ、K ラインデータのクエリ、資金調達率のクエリ、トランザクション製品関連情報のクエリ、取引所サーバーのタイムスタンプのクエリなどの市場インターフェースです。簡単に言えば、アカウントとは何の関係もないインターフェースは、大まかにパブリックインターフェース（検証不要）であると判断できます。
  Inventor Quantitative Trading Platform では、未検証の API 関数 (取引所の未検証インターフェース、パブリックインターフェースをカプセル化したもの) を呼び出すときに、API KEY が正しく設定されていない場合でも、インターフェースによって返されるデータを正常に取得できます。（検証されていないため）
- 検証が必要なインターフェース簡単に言えば、検証（API KEY による検証）が必要なインターフェースです。このタイプのインターフェースはプライベートインターフェースと呼ばれます。このタイプのインターフェースは通常、アカウント資産の照会、アカウントポジションの照会、保留中の注文の照会、転送の照会、コインの転送、レバレッジの調整、ポジションモードの設定など、アカウントの一部の操作または情報に関連しています。これらの操作は検証する必要があります。 Inventor Quantitative Trading Platformでは、検証が必要なAPI関数（カプセル化された取引所が検証する必要があるインターフェース、プライベートインターフェース）を呼び出すときに、API KEYの設定が正しくない場合、インターフェースの呼び出し時にエラーが報告され、 null値が返されます。

では、これらのインターフェースは Inventor Quantitative Trading Platform でどのように使用されるのでしょうか?

Inventor Quantitative Trading Platform は、取引所の振る舞いをカプセル化し、一貫したインターフェース（K ラインインターフェース、ディープマーケットインターフェース、現在の資産照会インターフェース、注文インターフェース、注文引き出しインターフェースなど）を定義します。これらのインターフェースは、API 関数と呼ばれます。 Inventor Quantitative Trading Platform は、API ドキュメント (https://www.fmz.com/api) をクエリすることで表示できます。

では、Inventor Quantitative Trading Platform で、動作や定義に一貫性のない一部の交換インターフェースをどのように使用すればよいのでしょうか?

これらの取引所インターフェースには、資産の移転、条件付き委託、一括注文の配置、一括注文のキャンセル、注文の変更などが含まれます。一部の取引所にはこれらのインターフェースがありますが、他の取引所には存在しません。機能と使用方法の詳細は大きく異なる場合があります。したがって、これらのインターフェースは Inventor Quantitative Trading Platform で利用できます。exchange.IOこの関数はアクセスするために使用されます (詳細については、Inventor Quantitative Trading Platform API ドキュメント (https://www.fmz.com/api#exchange.io…) を参照してください)。 Inventor Quantitative Trading Platform Strategy Square には、実用的な IO サンプル戦略もいくつかあります。

Inventor Quantitative Trading Platform API ドキュメント内のすべての API 関数はネットワーク要求を生成しますか?

まず、取引所のAPIインターフェースにはアクセス頻度の制限（たとえば、1秒あたり5回）があるとします。アクセス頻度が高すぎると、http 429エラーが報告され、アクセスが拒否されます（ほとんどの取引所は429を報告します）。。同じ制限は、Inventor Quantitative Trading Platform 上のパッケージ化された交換インターフェースの呼び出しにも適用されます。ネットワーク要求を生成しない Inventor Quantitative Trading Platform 上の API 関数には、このような制限はありません。 Inventor Quantitative Trading Platform のすべての API 関数がネットワーク要求を生成するわけではありません。Inventor の API 関数の一部は、現在の取引ペアの設定、契約コードの設定、指標計算関数、取引所オブジェクト名の取得など、一部のローカル設定のみを変更します。等基本的に、関数の目的からネットワークリクエストが発生するかどうかを判断できます。取引所データの取得、取引所アカウントの操作などであれば、ネットワークリクエストが発生します。呼び出しに注意する必要があります。これらのインターフェースの頻度。

Inventor Quantitative Trading Platform で API 関数を使用するときによくある問題と経験について説明します。
- フォールトトレランスこれは最も一般的なエラーであり、多くの初心者を悩ませています。多くの場合、戦略のバックテストは正常ですが、しばらく実行した後、実際の市場がクラッシュするのはなぜですか (いつでもトリガーされる可能性があります)?
戦略を書くときは、インターフェースから返されるデータを判断して検証する必要があります。たとえば、このコード行は、Inventor Quantitative Trading Platformで市場情報を取得するために使用されます（取引所に直接アクセスするプログラムを書く場合も同様です）。インタフェース）：var ticker = exchange.GetTicker()これを使う必要がある場合はticker変数（GetTicker関数によって返される構造を参照）Last（最新価格）データを使用するにはvar newPrice = ticker.Last次のようにデータを取得します（newPriceとは何か？new：最新、Price：価格、そう！これらをまとめます！）このとき、GetTicker()関数が正常なデータを返す場合は問題ありませんが、リクエストがタイムアウトしたり、ネットワークエラーが発生したり、取引所がネットワークケーブルを抜いたり、ケーブルが切断されたり、いたずらな子供が電源スイッチを引っ張ったりした場合は、GetTicker()関数の戻り値null。現時点ではtickerの値はnullまた訪れてみます。Lastプログラム例外が発生し、ポリシープログラムが停止します。インターフェース呼び出しの失敗（GetTicker呼び出しが失敗し、nullが返された）は、戦略の実際の取引停止の直接的な原因ではないようです（直接の原因は、null変数プロパティ、インターフェース呼び出しの失敗、エラーによって実際の取引が停止することはありません (強調追加)。では、実取引の異常な停止を回避するために何ができるでしょうか? 答えは、インターフェースから返されるデータに対してフォールトトレランス処理を行うことです。返されたデータがnull（JavaScriptを例に挙げていますが、他の言語も基本的には同じです）説明のために小さなコードスニペットを記述します (これは単なる説明であり、直接実行しても機能しません)。
```
  var ticker = exchange.GetTicker()
  if (ticker) {
      var newPrice = ticker.Last
      Log("打印最新价格：", newPrice)
  } else {
      // 数据为null，不做操作就不会出问题
  }
```
だけでなくGetTickerインターフェースはフォールトトレラントである必要があります。ネットワーク要求を持つすべてのインターフェースは、戻り値に対してフォールトトレラントである必要があります（関数の戻り値を使用する場合）障害を許容する方法は数多くあります。_C()関数 (FMZ API ドキュメントを参照)、独自のフォールトトレラント関数を記述し、独自のフォールトトレラントメカニズムとロジックを設計します。について_C()関数を使用する場合、多くの新入生は関数を誤って使用する可能性があります。_C()関数パラメータは関数呼び出しではなく、関数参照です。簡単に言えば: _C(funcName, param1, param2)呼び出しは正しく、funcName には括弧がなく、param1 と param2 は funcName 関数に渡されるパラメーターです。 _C(funcName(param1, param2))、呼び出しエラー、通常、FMZ API ドキュメントを注意深く読まない初心者は、これを次のように記述します。
- スポット市場の買い注文の注文数量スポット市場の買い注文の注文数量も、多くの新規トレーダーによく間違えられます。前回の記事では、スポット市場の買い注文の注文数量は通常、金額であると述べました（一部の取引所では他の設定がある場合があり、通常はFMZ、これらの特別な交換設定は、FMZ API ドキュメントで説明されています。たとえば、テストには OKEX V5 シミュレーションディスクを使用しました。取引ペアの設定は次のとおりです。LTC_USDT
```
  function main() {
      exchange.IO("simulate", true)   // 切换为OKEX交易所的模拟盘
      exchange.Buy(-1, 1)             // 价格是-1，表示下的订单为市价单，数量为1表示下单量是1USDT
  }
```
取引所には通常、注文金額の制限があるため、制限を下回る注文は送信されません (たとえば、Binance スポットでは、各注文が 5 USDT を超えると正常に送信されます)。したがって、次のような注文を行うとエラーが発生します。
```
  错误	Buy(-1, 1): map[code:1 data:[map[clOrdId: ordId: sCode:51020 sMsg:Order amount should be greater than the min available amount. tag:]] msg:]
```
- 先物注文時の指示先物戦略を開発する際、初心者は注文の方向を間違えることが多く、それが問題につながります。Inventor Quantitative Trading Platform での戦略の作成を例に挙げてみましょう。まず、API ドキュメントの説明を見てみましょう。 https://www.fmz.com/api#exchange.setdirection...
順序関数にはBuy,Sell。しかし、先物（もちろんスポットには問題はありません。スポットには買いと売りしかありません）には、ロングのオープン、ロングのクローズ、ショートのオープン、ショートのクローズなどの方向があります。明らかに、買い/売りはそれほど多くの方向の操作を表すことはできません。このとき、先物取引の方向の設定を導入する必要があります。この機能はexchange.SetDirection()。 FMZについて exchange.SetDirection("buy")（まず方向を決める）そしてexchange.Buy一緒に使用すると、発注された注文がロングポジションを開く注文であることを意味します。等々： exchange.SetDirection("sell")そしてexchange.Sellこれらを一緒に使用すると、発注された注文がショートポジションを開く注文であることを意味します。 exchange.SetDirection("closebuy")そしてexchange.Sellこれらを一緒に使用すると、発注された注文がロングポジションをクローズする注文であることを意味します。 exchange.SetDirection("closesell")そしてexchange.Buyこれらを一緒に使用すると、発注された注文がショートポジションをクローズする注文であることを意味します。通常、初心者はexchange.SetDirection("sell")そしてexchange.Buy他のものと組み合わせて使用したり、その他の誤った組み合わせで使用したりします。その後、エラーが報告されました (バックテストではエラーが報告されない場合もありますが、これは明らかに論理エラーであり、強迫性障害の人はそれを容認できません…)。初心者が犯すもう一つのよくある間違い
```
  function main() {
      exchange.SetContractType("quarter")   // 设置当前合约为季度合约
      exchange.SetDirection("sell")
      var id = exchange.Sell(-1, 1)    
      Log("看我市价单下单了，成交了，就有持仓了", exchange.GetPosition())    
      exchange.SetDirection("closebuy")   // closebuy 和Sell 搭配使用，嗯没错~
      exchange.Sell(-1, 1)
  }
```
これを見ると、「ポジションを持っていて、closebuy と sell を一緒に使用しているのに、エラーが発生してポジションをクローズできないのはなぜですか?」と疑問に思うかもしれません。私はこう答えます。「間違った方向に決済してしまいました。ロングポジションを決済してしまいました。」上記のエラーが発生する可能性のある別の状況としては、決済方向が正しく設定され、注文関数が正しく使用され、ポジションがこの方向に保持されているにもかかわらず、このエラーが報告される場合が挙げられます。理由は、プログラムが複数の注文を出したが、最初の注文は実行されず、決済注文は市場で実行を待っていたためです。この時点で、プログラムはポジションをクローズし続け、プロンプトが表示されます。終値を超えるエラー。
- ログ出力とトランザクション情報の表示プログラム化された定量的な取引戦略の設計と記述は、「データの表示」や「操作ログの出力」などの人間とコンピュータの相互作用の設計と切り離せません。リアルタイムスクリプトと戦略プログラムは通常、ネイティブプログラミング言語で記述されます。現在の言語の出力機能を直接使用します。例えば：パイソンprint。 JavaScriptconsole.log。 Go言語fmt.Println()。 C++cout
FMZ プラットフォームに表示される情報についてお話しましょう。Inventor Quantitative Trading Platform には、情報が表示される主な場所が 2 つあります。
```
 - ステータスバー
実ディスクが稼働すると、実ディスクページは図のようになります。


![暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）](/upload/asset/16bafc3d4df6dfa18102.png)


表示部分はステータスバー情報です。ステータスバーは主にリアルタイムで変化するデータを表示するために使用されます（リアルタイムの変化はリアルタイムで観察する必要があり、毎回ログに印刷することはできないため、この種類のステータス バーにデータを表示できます。 1 つずつ印刷すると、ログに多くの重複した意味のないデータが含まれることになり、クエリに影響します。
ステータスバーにデータ使用量を表示する`LogStatus`機能の詳細については、FMZ の API ドキュメントを参照してください。

 - ログ列
実際のマーケットページでも、図に示すように次のようになります。


![暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）](/upload/asset/16cf9d61e66384022a76.png)


表示部分はログバーであり、主に特定の瞬間の特定のデータを永続的に記録したり、特定の時間における戦略の特定の操作を記録したりするために使用されます。
ログにはいくつかの種類があります。
1. 通常のログ: FMZ 戦略は、ログ機能を使用して戦略ログに出力および印刷します。


![暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）](/upload/asset/16ddc72e1f7d07dcfa5a.png)


2. FMZ戦略で使用される注文ログ`exchange.Sell`/`exchange.Buy`ログ出力に自動的に記録されます。


![暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）](/upload/asset/172aac2089e93865e3c2.png)


3. FMZ戦略で使用される注文キャンセルログ`exchange.CancelOrder`、注文キャンセルログがログに自動的に出力されます。


![暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）](/upload/asset/15e90c7be742743c7421.png)


4. エラー ログ。FMZ 戦略の実行中に、ネットワーク要求のインターフェイスで呼び出しエラーが発生したり、例外がスローされたりした場合 (throw などのステートメントなど)、ログにエラー ログが自動的に出力されます。


![暗号通貨界における定量取引の初心者の方は、こちらをぜひご覧ください - 暗号通貨界における定量取引への近道（パート 2）](/upload/asset/166196451439434a800f.png)
```
Log(…)、exchange.Buy(Price, Amount)、exchange.CancelOrder(Id)などのログ出力を生成できるFMZ API関数には、必須パラメータの後にいくつかの追加の出力パラメータを続けることができます。例えば、exchange.CancelOrder(注文[j].Id, orders[j]) これは注文をキャンセルするためのものです[j] この注文をすると、注文情報が出力されます。
```
  function main() {
      Log("数据1", "数据2", "数据3", "...")
      var data2 = 200
      var id = exchange.Sell(100000, 0.1, "附带数据1", data2, "...")
      exchange.CancelOrder(id, "附带数据1", data2, "...")
      LogProfit(100, "附带数据1", data2, "...")
  }
```
- 指標関数の使用インジケーターの機能について話す前に、まずインジケーターとは何かを理解しましょう。簡単に言うと、移動平均線やMACD、ATRなどの線のことです。 Q: これらの指標はどこから来るのでしょうか? 回答：もちろん計算されます。 Q: 計算の根拠は何ですか? 回答: K ラインデータに基づいて計算されます。 Q: 例を挙げていただけますか? 回答: 最も単純な指標である移動平均指標を例にとると、指標計算のデータソースとして日次 K ライン (正または負のラインが 1 日を表します) データを使用します。移動平均インジケーターのパラメータが 10 の場合、計算される移動平均インジケーターは 10 日間の移動平均になります。質問: K ライン BAR の数が 10 未満の場合、移動平均インジケーターを計算できますか? 回答：移動平均指標を計算できないだけでなく、Kラインデータバーの数が指標サイクルパラメータを満たしていない場合、どの指標も有効な指標値を計算できません。計算された配列の対応する位置は空で埋められます。例えば、JavaScript計算された指標データを印刷するときに言語戦略が表示されます。null。
Strategy Square に指導例があります: https://www.fmz.com/strategy/125770 このチュートリアルの例の戦略をバックテストすると、バックテストシステムによって生成されたチャートと 10 期間の移動平均が表示されます。

戦略カスタム描画、描画された K ラインと移動平均チャート:

Q: 10 時間移動平均が必要な場合はどうすればいいですか? 回答: K ラインデータは、1 時間ごとの K ラインデータを使用できます。

平たく言えば、私たちが目にするKラインは、デジタル化された後の配列です（配列の概念がわからない場合は、Baiduで検索してください）。各要素はKラインの列であり、順番に。配列の最初の要素は現在時刻から最も遠く、配列の最後の要素は現在時刻に最も近いものになります。通常、K ラインデータの最後のバーは現在の期間のバーであり、リアルタイムで変化し、未完了です (取引所のページにログインして K ラインを観察することで、変化を観察できます)。計算されたインジケーターも K ラインバーに 1 対 1 で対応します。上記の例では、1 つのインジケーター値が 1 つの K ラインバーに対応していることがわかります。最後の K ライン列はリアルタイムで変化し、計算されたインジケーターも K ライン列の変化に応じて変化することに注意してください。

Inventor Quantitative Trading Platformでは、TAライブラリ（FMZプラットフォームによって実装され、カストディアンに統合され、さまざまな言語で直接使用できるライブラリ）またはtalibライブラリ（talibは定評のある指標ライブラリであり、 JS と C++ が統合されており、Python は自分で記述する必要があります) をインストールします。たとえば、上記の例では、移動平均は次のように計算されます。 TA ライブラリの使用:
```
  function main() {
      var records = exchange.GetRecords()
      var ma = TA.MA(records, 10)
      Log(ma)       // 打印均线
  }
```
talib ライブラリの使用:
```
  function main() {
      var records = exchange.GetRecords()
      var ma = talib.MA(records, 10)
      Log(ma)       // 打印均线
  }      
```
計算された指標データmaは配列であり、その各要素はKライン配列（レコード）に対応しています。ma[ma.length -1]対応するrecords[records.length - 1]、等々。

他の複雑な指標でも同様で、MACDなどの指標にも注意を払う必要があります。
```
  var macd = TA.MACD(records)   // 这样只传入K线数据，不传入指标参数，指标参数采用的就是默认值，其它指标函数也是同理
```
このとき、変数macdは2次元配列です（概念がわからない場合は、Baiduで検索してください）。簡単に言えば、2次元配列は配列であり、その各要素も配列です。。質問: macd インジケーターのデータが 2 次元配列であるのはなぜですか? 回答：MACDインジケーターは2本の線（DIF線とDEA線）と一連のボリュームバー（MACDボリュームバー、実際にはこのボリュームバーデータも線と見なすことができます）で構成されているためです。したがって、macd 変数は次のように分割できます。
```
  var dif = macd[0]
  var dea = macd[1]
  var macdColumn = macd[2]
```
こちらには既成の指導例もありますので、ご興味があればご覧ください: https://www.fmz.com/strategy/151972

Forums

PINE Language FAQ Summary MyLanguage Web3 About Us

Product

Robot Strategy Node Platforms Tickets

API

Syntax guide User guide Trading api Blockchain Indicator