1. 消化する
  2. 議論
  3. コイン・サイクルの量化取引は,新しいものに見えます.

コイン・サイクルの量化取引は,新しいものに見えます.

作者: リン・ハーン小さな夢, 作成日:2021-04-19 14:16:21, 更新日:2023-09-24 19:30:05

img

円量化取引は新鮮に見えますが,円量化に近寄ります (二)

前回の記事では,プログラム化取引脚本について語りました. 実際,取引戦略は取引脚本です. この記事では,取引脚本がハードウェアキャリア (プログラムが動作する場所) を必要とすることを主に述べています. この脚本取引プログラムは,コンピュータプログラミング言語で記述することができます.

プログラム化された取引脚本

  • 取引戦略の種類 初心者のプログラム化取引,量化取引の新人達は,トレンド戦略,スロット戦略,高周波戦略,格子戦略などの名詞に惑わされるかもしれません.実際には,プログラム化取引,量化取引の一般的な戦略タイプは,簡単にいくつかの方向に述べることができます.

    • 利息をカバーする戦略 簡単に言えば,基本的には,一方の側が多見と片方の側が空見のポジションを持つような戦略は,利息戦略に分類できる.具体的な種類はたくさんあり,現金市場横断,先物間断,期日利息,品種横断等である.
    • トレンド戦略 簡単に言えば,トレンドをフォローする戦略,双等線,MACDなどの戦略です.
    • 返還戦略 例えば,格子戦略は,波動する市場での価格変動から利益を得る.
    • 高周波戦略 簡単に言うと,あるアルゴリズムを使って市場微小構造,規則,機会などを探索し,高周波取引を行う戦略である.

    上記は取引戦略の観点から分類され,発明者による量化取引プラットフォームの戦略設計の観点から,戦略は以下に分けられる:

    • 単品戦略 この戦略は,BTC取引やETH取引など,一つの品種のみを操作するということです.
    • 多種戦略 簡単に言うと,複数の品種を戦略的論理に従って操作することである.
    • 多アカウント戦略 簡単に言えば,複数の取引所オブジェクトを実体上で配置する (前回の記事で取引所の概念を紹介した.API KEYの取引所オブジェクトを配置すると,取引所アカウントを代表する).例えば,いくつかのリストのポリシー,複数のアカウントが一緒に操作をフォローする (同じ取引所,または異なる取引所かもしれない),つまり,実体上で複数の取引所オブジェクトを管理する (アカウント).
    • 多論理的戦略 リアルディスク上で,例えばMACD戦略,均線戦略,格子戦略等を同時に設計する (もちろん,異なる取引所のオブジェクトを操作し,同じ取引所のオブジェクトを操作する場合は,特定の戦略が論理的に衝突しているかどうかを確認する)

  • エクスチェンジ API インターフェース プログラム化取引スクリプトが取引所のアカウントを操作する方法は? 答えは,取引所のオープンAPIインターフェースです. では,取引所が開いているインターフェースにはどのような種類がありますか? 前回の記事では",取引所"のセクションで,取引所には一般的にREST,Websocketインターフェースがあることを説明しました. ここで,策略プログラムレベルから概念を少し追加します. 取引所のインターフェースは,認証されているか否かによって区分されています. (REST,Websocketも) 認証されているか否かです.

    • 認証を必要としないインターフェース 一般的に公共インターフェースと呼ばれますが,この種のインターフェースは検証を必要としません.API KEY(API KEYとは忘れているので,前回の記事に転覆できます).この種のインターフェースは,一般的に深層市場,K線データ,金利率,取引品種に関する情報,取引所サーバーの時間帯などの市場インターフェースです. 簡単に言うと,あなたのアカウントとは全く関係のないインターフェースは,ほぼ公的なインターフェースであることを確認できます (認証は必要ありません).
      発明者の量化取引プラットフォームでは,未確認のAPI関数を呼び出すとき (包装取引所未確認インターフェース,公共インターフェース) API KEYの配置が間違っていたとしても,インターフェースが返したデータを正常に取得することができる.

    • 認証が必要なインターフェース 簡単に言うと,認証が必要なインターフェース (API KEYによる認証) です. このようなインターフェースはプライベートインターフェースと呼ばれます. これらのインターフェイスは,通常,アカウントの操作や情報に関連しています. たとえば,アカウント資産の検索,アカウント保有の検索,アンケートハング,単一のアンケート転送,転送,通貨調整レバレッジ,保有モードの設定などです. この操作は検証しなければならない. 発明者による量化取引プラットフォームでは,API関数を呼び出すときに検証を必要とする (包装された取引所が検証を必要とするインターフェース,プライベートインターフェース) が,API KEYが誤った配置であれば,インターフェースを呼び出すときにエラーが返され,空白値が返されます.

    では,これらのインターフェースが発明者の量化取引プラットフォームでどのように使用されているのでしょうか?

    発明者量化取引プラットフォームは,取引所の動作を包み込み,一貫性のあるインターフェースを定義する (例えば,K線インターフェース,深層市場インターフェイス,現在の資産のインタフェースを問い合わせ,下单インターフェイス,注文を取り除くインターフェイスなど).これらのインターフェースは,発明者量化取引プラットフォームで発明者量化取引プラットフォームAPI機能と呼ばれる.APIドキュメントを問い合わせることで閲覧できます.https://www.fmz.com/api ）。

    では,ある行動や定義が統一されていない取引所のインターフェースが,発明者の量化取引プラットフォームでどのように使用されるのでしょうか?

    これらのインターフェースは,例えば:資産分割,条件委託,大量注文,大量撤回,変更注文などである.これらのインターフェースは,ある取引所であるが,ある取引所でないが,機能や使用詳細は大きく異なる可能性があるため,これらのインターフェースは,発明者の量化取引プラットフォームで通過される.exchange.IOこの関数へのアクセスについては,発明者の量化取引プラットフォームAPI文書を参照してください:https://www.fmz.com/api#exchange.io..発明者の量化取引プラットフォーム戦略広場にも,実用的なIOの例策があります.

    発明者による量化取引プラットフォームAPIのドキュメントに含まれるすべてのAPI機能がネットワークリクエストを生成するのでしょうか?

    まず,取引所APIのアクセス頻度が制限されている (例えば,秒間に5回など) といった場合,アクセス頻度が頻繁すぎない場合,http 429エラーを報告し,アクセスが拒否される (ほとんどの取引所が429を報告している).そうであれば,発明者の量化取引プラットフォームで包装された取引所インターフェースを呼び出すことも同じ制限があります.発明者の量化取引プラットフォームでネットワークリクエストを生成しないAPI機能には,この制限はありません. すべての発明者による量化取引プラットフォームのAPI機能がネットワークリクエストを生むわけではありません.一部の発明者によるAPI機能は,現在の取引ペアを設定する,契約コードを設定する,指標計算機能,取引所のオブジェクト名を取得するなど,いくつかのローカル設定を変更するだけです. 基本的には,関数の用途から,ネットワークリクエストが発生しているかどうかを判断することができる.ただし,取引所のデータを取得し,取引所の口座操作などにネットワークリクエストが生成される限り,これらのインターフェースは呼び出し頻度に注意する必要があります.

    • 発明者によるQTプラットフォームのAPI機能の利用に関するいくつかの一般的な問題や経験です

      • 間違いを許す これは最も一般的なエラーで,無数のニュースを悩ます,常に戦略を復元します. すべては正常です. なぜリアルディスクがしばらく (いつでも起動する可能性があります) 実行され,リアルディスクが掛かります~

        img

        インターフェースが返したデータに対して,策略を書く時,我々は検証を判断する必要があります. 例えば,発明者の量化取引プラットフォームでこの行のコードを得ること (自分でプログラムを書くことは,直接取引所のインターフェースにアクセスすることと同じです):var ticker = exchange.GetTicker()必要なのは,この2つの要素です.ticker変数 (GetTicker関数返した構造を参照)Lastこのデータを使ってvar newPrice = ticker.Lastこの時点で,newPriceは,new:最新,Price:価格,yes!合わさった!)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 に渡すパラメータは,param2 です._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 現金で5USDT以上の注文が成功するために要求される).

        错误	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:]

      • フューチャー取引時の方向性 フューチャー戦略を策定する際の"つの方向性もまた,発明者の量化取引プラットフォームで策略を書き出す例として,新人達がしばしば間違いを犯して問題を引き起こすものです. 詳細は,APIのドキュメントに記載されています.https://www.fmz.com/api#exchange.setdirection...

        img

        この関数は,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複習は失敗かもしれないが,これは明らかに論理的間違いで,強迫症は耐えられない...). 新さんがよく犯すもう1つの間違い

        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)
}

        img
        このページを見ると,なぜ私が持てる株があって,ClosebuyとSellも一緒に使っているのか,なぜ報告が間違って,平衡できないのか,と聞くでしょう. 上記のこの報告の誤りが発生する可能性のあるケースは,平衡方向を正しく設定し,下記関数を使用することも正しいこと,またこの方向を保持しても,このエラーを報告することである. 原因は,あなたのプログラムが複数の注文を出した可能性があり,最初の注文は取引されず,平成の注文は取引を待っています. この時点でプログラムは平成を続け,平成のポジションを超えたエラーを提示します.

      • ログの出力,取引情報の表示 設計書編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編編 例えば: Python で使っていますprint│ │ JavaScriptを使用するconsole.log│ │ ゴラング用fmt.Println()│ │ C++を使用するcout

        FMZの情報表示は,発明者の量化取引プラットフォーム上で,情報表示の2つの主要位置を示しています.

        • ステータスバー 仮想ディスクが起動すると,このページが表示されます.

          img

          状態欄の部分表示は状態欄の情報であり,状態欄は主にリアルタイムに変化するデータを表示するために使用されている. (リアルタイムの変化はリアルタイムで観察する必要があるため,毎回ログに印刷することはできません.したがって,このようなデータは状態欄で表示できます. ステータスバーでデータ使用を表示しますLogStatusFMZのAPIドキュメントを参照してください.

        • 日記 リアルディスクのページでも,図のように:

          img

          ログバーは,ある時点で特定のデータを永久に記録する,またはある時点で策略された特定の操作を記録する. この日記には,以下のような種類があります. 1, 一般ログ,FMZのポリシーでLog関数を出力,ポリシーログでプリントする.

          img

          2 フォロー・ログ,FMZの戦略で使用exchange.Sell/exchange.Buy自動でログに記録を出力します.

          img

          3 撤収日記,FMZの戦略で使用exchange.CancelOrderローグに自動的に削除ログを出力します.

          img

          4. エラーログ,FMZのポリシーを実行しているときに,ネットワーク要求を行うインターフェースに呼び出しが間違えた場合,異常 (例えばthrowのような文) が投げられた場合,自動的にログにエラーログを出力します.

          img

        FMZのAPI関数は,ログ出力関数であるLog ((...),exchange.Buy ((Price, Amount),exchange.CancelOrder ((Id) などを生成することができる.必要パラメータの後には,Exchange.CancelOrder ((orders[j].Id, orders[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: これらの指標はどこから来たのですか? A: もちろん計算されています. Q:何に基づいて計算したのですか? A:K線データに基づいて計算します. Q:例を挙げてください. 答え: 最も簡単な指標均線指標例では,日線K (つまり日を表す日線または陰線) を指標計算のデータ源として使用した場合.均線指標のパラメータが10である場合,計算された均線指標は10日均線である. Q:K線BARが10個未満の場合は均線指数を計算できますか? 答え: 均線指標が計算できないだけでなく,K線データBARの数が指標周期参数を満たさない場合,有効な指標値は計算できない.計算された配列の対応位置は空白値で満たされます.JavaScript言語戦略は,印刷された指標データを表示します.null。

        戦略広場では,この教材の例が示されています.https://www.fmz.com/strategy/125770この教学例の戦略を復習すると,復習システムが生成したグラフと10周期間の平均線が表示されます:

        img

        戦略は,カスタマイズされたグラフ,描かれたK線,および均線グラフ:

        img

        Q:もし10時間の平均線が欲しいとしたら? 答え:K線データは,時間周期のK線データでよい.

        俗説では,私たちが見るK線は,それをデータ化した後,数列である (数列の概念は理解できない,百度で説明できます),その各要素はK線柱であり,順序で並べられています.数列の最初の要素は,現在の時間から最も遠いもので,数列の最後の要素は,現在の時間から最も近いものです. 通常,K線データの最後の線柱は,現在の周期の線柱であり,リアルタイムに変化し,未完成である.計算された指標は,K線柱に1対1に対応している.上記の例では,指標の数値がK線柱に対応していることが見られます.注意してください.最後のK線柱は,リアルタイムに変化し,計算された指標も,K線柱の変化に伴い変化します.

        発明者の量化取引プラットフォームでは,TA庫 (FMZプラットフォームで実装された庫,ホストで統合され,さまざまな言語で直接利用可能) またはtalib庫 (talib老牌指標庫,JS,C++統合,Pythonは自社インストールが必要です) を使用できます. 例えば,上記の例では,平均線を計算します. タリバラの利用:

        function main() {
    var records = exchange.GetRecords()
    var ma = TA.MA(records, 10)
    Log(ma)       // 打印均线
}

        タリブ庫の利用者:

        function main() {
    var records = exchange.GetRecords()
    var ma = talib.MA(records, 10)
    Log(ma)       // 打印均线
}

        計算された指標データ ma は,各要素が 1 つずつ対応する K 線数列 (records) で,ma[ma.length -1]対応するrecords[records.length - 1]メディアの報道によると,

        他のより複雑な指標も同理的であるため,MACDのような指標に注意を払う必要があります.

        var macd = TA.MACD(records)   // 这样只传入K线数据，不传入指标参数，指标参数采用的就是默认值，其它指标函数也是同理

        このとき macd の変数は 2 次元の行列である (この概念は理解できない). 2 次元の行列は,単に行列であり,その各要素も行列である. Q:なぜ 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

        img

関連性
もっと

2019 FMZ - すべての権利は保護されています.