資源の読み込みに... 荷物...

新人,チェックアウト仮想通貨量的な取引にあなたを連れて行く (2)

作者: リン・ハーンニナバダス, 作成日: 2022-04-19 16:46:53, 更新日: 2022-04-20 16:56:43

新人,チェックアウト仮想通貨量的な取引にあなたを連れて行く (2)

前回の記事では,プログラムされた取引スクリプトについて語りました. 実際,取引戦略は取引スクリプトプログラムです. この記事では主に,取引スクリプトプログラム (プログラムが実行される場所) のハードウェアキャリアの必要性について語り,スクリプト取引プログラムは,そのコンピュータプログラミング言語で記述することができます (FMZ Quant Trading Platformで使用される3つのプログラミング言語をリストします.もちろん,プログラムされた取引で戦略を実行するために,任意のプログラミング言語を使用できます). この記事では,暗号通貨サークルの定量化について議論し,知識を理解し続けます.

プログラムされた取引スクリプト

取引戦略の種類プログラミング取引と定量取引に初心者であれば,トレンド戦略,アービタージ戦略,高周波戦略,グリッド戦略など様々な用語で混乱する可能性があります. 実際,プログラミング取引と定量取引における一般的な戦略は,単にいくつかの方向にあります.
- 仲裁戦略簡単に言えば,ショートポジションを保持しながら基本的にロングポジションを保持する戦略は,アービトラージ戦略に分類することができる.スポットクロスマーケット,フューチャークロスペリオド,フューチャーとスポットアービトラージ,クロスシンボルアービトラージなど,多くの特定の種類があります.
- トレンド戦略単純に言えば,トレンドを追跡し,ダブル移動平均,MACDなどの戦略で1つのポジションを配置する戦略です.
- リターン戦略例えば格子戦略は変動する市場での価格変動から利益を得ることです
- 高周波戦略簡単に言うと,それは市場マイクロ構造,ルール,機会,などを見つけるためにいくつかのアルゴリズムを通じて高周波取引を行う戦略です.
上記のタイプは,取引戦略の観点から分類される. FMZ Quantの戦略設計の観点から,戦略は以下に分けられる:
- 単一のシンボルの戦略つまり,戦略は1つのシンボルのみを操作できる.例えば,BTC取引やETH取引を行う.
- 複数シンボル戦略シンプルに言うと複数のシンボルを 1つの戦略論理で操作することです
- 複数口座戦略簡単に言えば,ボット上で複数の交換オブジェクトを構成する (プラットフォームの概念は前回の記事で紹介され,API KEYで構成された交換オブジェクトはプラットフォームアカウントを表します).例えば,いくつかのオーダー監督戦略では,複数のアカウントが一緒に操作をフォローします (同じプラットフォームまたは異なるプラットフォームのアカウントかもしれません).要するに,複数の交換オブジェクト (アカウント) は1つのボットで管理されます.
- 多論理戦略例えば,MACD戦略,移動平均戦略,グリッド戦略など,ボットで同時に設計されています (もちろん,それは異なる交換オブジェクトを操作することであり,同じ操作を持つ交換オブジェクトは,特定の戦略が論理的に矛盾しているかどうかに依存します)
プラットフォーム API インターフェースプログラムされた取引スクリプトがプラットフォームアカウントを操作する方法は? 答えはプラットフォームが開いた API インターフェースを通じてです. では,プラットフォームに開かれているインターフェースの種類は? 前回の記事では,プラットフォームは一般的に REST と Websocket のインターフェースを持っていることを,Platform セクションで話した.ここで,戦略手順の側面からいくつかの概念を追加します.プラットフォームインターフェースは,検証されているかどうか (REST と Websocket 両方),すなわち検証されたものと非検証されたものによって分割されています.
- 検証を必要としないインターフェース一般的には"公開インターフェース"と呼ばれます.このタイプのインターフェースは,API KEYこのタイプのインターフェースは,一般的に市場インターフェースである.例えば,深度市場コート,Kラインデータ,資金提供率,取引シンボル,プラットフォームサーバータイムスタンプ等に関する情報への問い合わせなど. 簡単に言うと,基本的にはアカウントとは関係のないインターフェースは,概して公開インターフェイスであると判断できます (検証は必要ありません). FMZ Quant Trading Platformでは,検証されていない API 関数 (プラットフォームの検証されていないインターフェースをカプセル化する;公開インターフェース) を呼び出すとき,API KEY 構成が間違っている場合でも,インターフェースが返したデータは通常取得できます (検証は必要ありません)
- 検証が必要なインターフェース簡単に言うと,これらのインターフェースは,検証する必要がある (API KEYによって).このタイプのインターフェースはプライベートインターフェイスと呼ばれます.このタイプのインターフェースは,通常,アカウントのいくつかの操作や情報,例えばアカウント資産,アカウントポジション,待機中のオーダー,転送,通貨変換,レバレッジ調整,ポジションモード設定などに関連しています. これらの操作は検証されなければならない.
  
  FMZ Quantでは,検証を必要とする API 関数 (カプセル化されたプライベートインターフェース,プラットフォーム検証を必要とする) を呼び出すとき. API KEY の設定が間違っている場合,この種の関数を呼び出すとエラーが報告され, null を返します.
FMZの量子取引プラットフォームではどう使うのか?

FMZ Quant Trading Platformは,プラットフォームインターフェースを統一されたアクションと定義 (Kラインインターフェイス,ディープマーケットインターフェイス,現在の資産クエリインターフェイス,オーダーインターフェイス,オーダーキャンセルインターフェイスなど) でカプセル化している.これらのインターフェイスは,FMZ Quant Trading Platformで呼び出される.FMZ API機能は,APIドキュメントをクエリすることによって閲覧することができます: (https://www.fmz.com/api).

FMZ Quantで統一されたアクションや定義がない場合,

これらのプラットフォームインターフェースには:資産転送,条件オーダー,バッチオーダー,バッチオーダーのキャンセル,オーダーの変更などが含まれます.exchange.IOFMZ Quantの機能 (詳細については,FMZ Quant取引プラットフォームのAPIドキュメントを参照してください.https://www.fmz.com/api#exchange.io..FMZ Quant の Square において,いくつかの実用的な IO 例の戦略もあります.

FMZ API ドキュメンテーションのすべての API 機能がネットワークリクエストを行うことができるか?

プラットフォームAPIにはアクセス頻度が制限されている (例えば,1秒間に5回).アクセスが頻繁すぎない場合, http 429 のエラーが報告され,アクセスが拒否される (ほとんどのプラットフォームは 429 を報告する).したがって,FMZ Quant でカプセル化されたプラットフォームインターフェースを呼び出すことも制限がありますが,ネットワークリクエストを行わない API 関数を呼び出すにはそのような制限はありません.
FMZ Quant のすべての API 機能はネットワークリクエストを行うことができません. FMZ の一部の API 機能は,現在の取引ペア,契約コード,指標計算機能の設定,交換オブジェクトの名前を取得など,一部のローカル設定のみを変更します. 基本的に,a関数の使用から,ネットワークリクエストが行われるかどうかを決定できます. プラットフォームデータを取得するか,プラットフォームアカウントを操作する限り,ネットワークリクエストが行われます. これらのインターフェースはすべて呼び出し頻度に注意を払う必要があります.

FMZ Quant で API 関数を使用するいくつかの一般的な問題と経験についてお話ししましょう.
- 誤差許容度これは,無数の初心者を悩ませている最も一般的なエラーです.しばしば,戦略バックテストは良好で,すべてが正常です.ボットがしばらく実行した後 (いつでもトリガーされることがあります) なぜボットが異常な動作をするのですか?
  
  戦略を書くとき,インターフェースが返したデータについて検証する必要があります.例えば,FMZ Quantのティッカーを取得するコード (プラットフォームインターフェースに直接アクセスするために自分のプログラムを書く 것과同じです):var ticker = exchange.GetTicker()データを利用する必要がある場合Last(最新の価格) 変数ticker(GetTicker関数の返信構造を参照できます) データを取得する必要があります (newPriceとは何か? new:最新; Price: price; that's right,それらを組み合わせます!)
  
  機能が機能している場合,それは大丈夫ですGetTicker()ネットワークエラー,プラットフォームがケーブルを引っ張っている場合,ケーブルが掘りで割れた場合,または子供たちが電源スイッチをオフにする場合,機能GetTicker()戻ってくるnull現在では,tickerはnullサイトにアクセスするときにLast戦略プログラムはプログラム例外によって停止されます. インターフェースの呼び出しの失敗 (GetTickerの呼び出しが失敗し null を返します) が戦略ボットの停止の直接的な原因ではないようです (直接的な原因は,nullインターフェースの呼び出しの失敗がエラーを報告する状況では,ボットが停止しない (ここで強調).
  
  異常なボットの停止を防ぐにはどうすればよいのでしょうか?
  インタフェースによって返されるデータに誤差耐性処理を行うことです. それは非常に簡単で,返されるデータがnull(ここではJavaScriptを例として,他の言語は類似しているからです) 小さなコードセグメントを書いてください (これは指示のみで,直接実行することはできません!)
```
var ticker = exchange.GetTicker()
if (ticker) {
    var newPrice = ticker.Last
    Log("Print the latest price:", newPrice)
} else {
    // data is null, so no operation will make no problem 
}
```
  だけでなく,GetTickerインターフェースは故障耐性処理を行う必要がありますが,ネットワークリクエストのインターフェースは返信値の故障耐性処理を行う必要があります (関数の返信値を使用する場合) 誤差容認の方法はたくさんあります._C()FMZ API ドキュメンテーションを参照してください) 独自の故障耐性関数を作成し,独自の故障耐性メカニズムとロジックを設計します.
  
  規制の適用について_C()機能,多くの新しい学生も誤って使用する可能性があります._C()簡単に言うと,関数は関数の参照ではなく,関数の呼び出しです._C(funcName, param1, param2);呼び出しが正し; funcName は括弧がありません.そして,param1 と param2 は funcName 関数にインポートされるパラメータです._C(funcName(param1, param2))呼び出しが間違っています. 通常,初心者がFMZ APIのドキュメントを注意深く読まない場合は,こんな感じで書かれます.
- スポットマーケットの購入注文額
  
  初心者は,スポットマーケットの購入オーダーのオーダー金額に間違いを犯すことも容易です. 前回の記事で述べたように,スポットマーケットの購入オーダーのオーダー金額は通常,金額です (プラットフォームのほんの一部だけが他の設定を有し,一般的にこれらの特別なプラットフォーム設定はFMZ APIのドキュメントで説明されます).例えば,私はテストするためにOKEX V5シミュレーションボットを使用しました:
  
  取引ペアを以下のように設定する.LTC_USDT
```
function main() {
    exchange.IO("simulate", true)   // switch to OKEX simulated bot 
    exchange.Buy(-1, 1)             // the price is -1, representing the placed order is market order; the amount of 1 means the order amount of 1 USDT
}
```
  プラットフォームには通常,注文金額の制限があるため,制限額未満の注文は行われない (例えば,Binance Spotでは5USDT以上の金額の注文のみが成功させられる必要があります).したがって,このような注文をするとエラーが報告されます:
```
error	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:]
```
- 期貨の注文方向
  
  フューチャーストラテジーを行うとき,初心者はしばしば順序の方向に間違いを犯します. FMZ Quant で戦略を書く例を挙げると,まず API ドキュメンテーションの説明を見てみましょう:https://www.fmz.com/api#exchange.setdirection...
  
  注文する機能は,BuyそしてSellしかし,先物 (もちろん,スポットには問題はありません.スポットには買いと売りのみがあります) は,長開,長閉,短開,短閉の方向性があります. したがって,明らかに,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")   // set the current contract to a quarterly contract 
    exchange.SetDirection("sell")
    var id = exchange.Sell(-1, 1)    
    Log("placed market order, executed, get positions", exchange.GetPosition())    
    exchange.SetDirection("closebuy")   // use closebuy and Sell together, yes, no problem 
    exchange.Sell(-1, 1)
}
```
  ポジションを閉じる方向が間違っています. ローグポジションを閉じたのです. ローグポジションを閉じる方向は間違っています. さらに,このエラーは別の状況でもあり得る: 接近位置方向の設定が正しく,オーダー配置機能の使用も正しく,また位置を方向に保持してもエラーが報告されます. 原因は,プログラムが多くのオーダーを交付し,最初は実行されず,閉じるポジションのオーダーが現在市場にあり,実行を待っています.その時点で,プログラムは閉じるポジションを継続し,閉じるポジションを上回るエラーを提示します.
- ログの輸出と取引情報表示プログラミングおよび定量的な取引戦略の設計と書き込みは,データ表示や操作日記輸出などの人間・コンピュータの相互作用の設計と切り離せない.通常,ローカルプログラミング言語を使用してボットスクリプトや戦略プログラムを書く.現在の言語の出力機能を直接使用する. 例えば: python の使い方printわかった javascript の使い方console.logわかったゴランの用途fmt.Println()- わかった C++ の使い方cout.
  
  FMZ Quantでは,主に2つの場所が表示されています.
  - ステータスバーボットが起動すると,ボットページは次のようになります:
    
    状態バーの表示部分は,状態バー情報である.状態バーは,主にリアルタイムで変化するデータを表示するために使用される (リアルタイムの変化はリアルタイムで観察する必要があるため,毎回ログとして印刷することはできません.このタイプのデータは,状態バーで表示できます.各々のログをプリントすると,多くの意味のない重複データがあり,クエリに影響します). 状態バーに表示されるデータは,LogStatus詳細については FMZ API 文書を参照してください.
  - ログバーこの画像はボットページにも表示されます
    
    ログバーは,主に特定の時点での特定のデータを永久に記録したり,特定の時点での特定の戦略の操作を記録するために使用されます. ログは様々な種類に分かれます.
    1. 共通のログ; FMZ ストラテジーは,ストラテジーのログで出力してプリントするために,Log 関数を使用します.
    1. 注文日記exchange.Sell/exchange.BuyFMZの戦略ではログの記録を自動的に出力します
    1. キャンセル日記exchange.CancelOrderFMZ戦略で使用され,キャンセルログは自動的にログに出力されます.
    1. エラーログ: FMZ 戦略が実行され,ネットワークリクエストのインターフェースに呼び出しエラーがあり,例外が投げられます (例えば,throw 命令など),エラーログは自動的にログに出力されます.
  FMZ API関数の中で,Log ((...), exchange.Buy ((Price, Amount), exchange.CancelOrder ((Id) などなどのログ出力を生成できる関数は,必要なパラメータの後にいくつかの追加の出力パラメータが続くことができます.例えば: exchange. CancelOrder ((orders[j].Id, orders[j]);注文の順序[j]がキャンセルされたときに追加的に注文情報を出力します.
```
function main() {
    Log("data1", "data2", "data3", "...")
    var data2 = 200
    var id = exchange.Sell(100000, 0.1, "additional data1", data2, "...")
    exchange.CancelOrder(id, "additional data1", data2, "...")
    LogProfit(100, "additional data1", data2, "...")
}
```
- インディケーター機能の使用インディケーター関数について話す前に,まずインディケーターとは何かを理解しましょう.簡単に言うと,移動平均値,MACD,またはATRのような線です.
  
  Q:これらの指標はどのように生成されますか? A: 計算によって生成されます
  
  Q:何で計算されるの? A:K線データ
  
  Q: 例を挙げられますか? A: 最も単純な移動平均指標を例として挙げます. 日々のK線 (すなわち,陽線または陰線が1日を表す) のデータを指標計算のデータ源として使用します. 移動平均指標パラメータは10,計算された移動平均指標は10日移動平均です.
  
  Q: K線 BAR の数は 10 未満である場合,移動平均指標を計算できますか? A: 移動平均指標が計算できないだけでなく,K線データ BARの数は指標周期パラメータを満たしていない場合,任意の指標が有効指標値を計算することはできません. 計算された配列の対応位置は空値で満たされます.nullと表示される.JavaScript戦略は計算された指標データを印刷します
  
  広場で教える例がありますhttps://www.fmz.com/strategy/125770テストシステムと10期間の移動平均値によって生成されたグラフを見ることができます.
  
  戦略のカスタム図,描かれたK線,移動平均グラフによって:
  
  Q: 10時間の移動平均値を使いたい場合は? A: 1時間単位のK線データを使用します.
  
  簡単に言うと,私たちが見るK線は,数値化した後,配列です (配列の概念を理解していない場合は,Baiduで検索できます),配列の各要素は,順番に並べたK線バーです.配列の最初の要素は,現在の時間から最も遠いもので,配列の最後の要素は,現在の時間から最も近いものです. 通常,K線データの最後のバーは,現在の期間のバーで,リアルタイムで変化し,完了しない (プラットフォームページにログインしてそのK線を観察することによって変更を観察することができます).計算された指標は,K線バーと1対1の対応も行っています.上記の例では,指標値がK線バーに対応していることを見ることができます.最後のK線バーがリアルタイムで変化し,計算された指標もK線バーの変化とともに変化します.
  
  FMZ Quant Trading Platformでは,TAライブラリ (FMZが実装したライブラリ,ドッカーに統合され,さまざまな言語で直接使用できます) またはtalib (古い有名な指標ライブラリtalib,JS,C++に統合されています. Pythonは追加的にインストールする必要があります) を使用できます. 例えば,上記の例の平均値の計算は, FMZ TA ライブラリを使用:
```
function main() {
    var records = exchange.GetRecords()
    var ma = TA.MA(records, 10)
    Log(ma)       // print average
}
```
  タリブを使う
```
function main() {
    var records = exchange.GetRecords()
    var ma = talib.MA(records, 10)
    Log(ma)       // print average 
}      
```
  計算されたインデックスデータ ma は配列であり,各要素は K 線配列 (レコード) に一つずつ対応します.ma[ma.length -1]対応するrecords[records.length - 1]そしてこれからも
  
  MACDなどの指標にも注意を払う必要があります.
```
var macd = TA.MACD(records)   // In this way, only the K-line data is passed in, and no indicator parameters are passed in. The indicator parameters use the default values, and that is the same for other indicator functions
```
  この時点で,変数 macd は二次元配列です (概念を理解していない場合は Baidu で確認できます).二次元配列は単に配列であり,その各要素も配列です.
  
  Q:なぜ MACD インディケーターデータが 2 次元の配列なのか? A: MACD指標は2つの線 (diff線とdea線) と一組のボリュームバー (MacDボリュームバーのデータも線とみなすことができます) から構成されているため,MacD変数は以下に分けることができます.
```
var dif = macd[0]
var dea = macd[1]
var macdbar = macd[2]
```
  興味のある方は,これを勉強できます:https://www.fmz.com/strategy/151972