Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)

Dalam artikel sebelum ini, kami bercakap tentang skrip perdagangan terprogram. Sebenarnya, strategi perdagangan ialah program skrip dagangan Artikel ini terutamanya membincangkan tentang keperluan pembawa perkakasan untuk program skrip dagangan (tempat program dijalankan), bahasa pengaturcaraan komputer yang boleh digunakan untuk menulis program perdagangan skrip ini (penyenaraian. penggunaan Platform Dagangan Kuantitatif Pencipta Terdapat tiga bahasa pengaturcaraan Sudah tentu, anda boleh menggunakan mana-mana bahasa pengaturcaraan untuk melaksanakan strategi untuk perdagangan terprogram). Dalam artikel ini, kami terus membincangkan analisis kuantitatif bulatan mata wang kripto dan memahami pengetahuan analisis kuantitatif bulatan mata wang kripto.

Skrip dagangan terprogram

• Jenis Strategi Perdagangan Pemula yang baru dalam perdagangan program dan perdagangan kuantitatif mungkin keliru dengan pelbagai istilah seperti strategi trend, strategi arbitraj, strategi frekuensi tinggi, strategi grid, dll. Malah, jenis strategi biasa perdagangan program dan perdagangan kuantitatif boleh menjadi mudah. diterangkan seperti berikut: Beberapa arah.

  • Strategi lindung nilai arbitraj Ringkasnya, pada asasnya, strategi memegang kedudukan panjang di satu pihak dan kedudukan pendek di pihak yang lain boleh diklasifikasikan sebagai strategi arbitraj. Terdapat banyak jenis khusus, termasuk pasaran rentas titik, tempoh masa hadapan, arbitraj spot-future, arbitraj rentas produk, dsb.
  • Strategi Trend Ringkasnya, ia adalah strategi mengikut arah aliran untuk membuat pesanan dan memegang kedudukan, seperti purata bergerak berganda, MACD dan strategi lain.
  • Strategi regresi Sebagai contoh, strategi grid boleh memperoleh keuntungan daripada turun naik harga dalam pasaran yang tidak menentu.
  • Strategi Frekuensi Tinggi Ringkasnya, ia adalah strategi perdagangan frekuensi tinggi melalui beberapa algoritma untuk menemui struktur mikro pasaran, peraturan, peluang, dsb.

Perkara di atas dibahagikan dari perspektif strategi perdagangan Dari perspektif reka bentuk strategi pada Platform Dagangan Kuantitatif Inventor, strategi juga boleh dibahagikan kepada:

• Strategi produk tunggal Maksudnya, strategi ini hanya mengendalikan satu produk, seperti perdagangan BTC atau perdagangan ETH.

• Strategi pelbagai produk Ringkasnya, ia adalah untuk mengendalikan pelbagai jenis mengikut logik strategi.

• Strategi berbilang akaun Ringkasnya, ia adalah untuk mengkonfigurasi berbilang objek pertukaran pada cakera sebenar (konsep pertukaran telah diperkenalkan dalam artikel sebelumnya, dan objek pertukaran dengan API KEY dikonfigurasikan mewakili akaun pertukaran). Sebagai contoh, beberapa strategi perdagangan salinan melibatkan berbilang akaun selepas operasi (ia mungkin pertukaran yang sama atau pertukaran yang berbeza Secara ringkasnya, berbilang objek pertukaran (akaun) diuruskan pada satu akaun sebenar.

• Pelbagai strategi logik Sebagai contoh, dalam pasaran sebenar, strategi MACD, strategi purata bergerak, strategi grid, dll. direka pada masa yang sama (sudah tentu, mereka beroperasi pada objek pertukaran yang berbeza. Jika anda mengendalikan objek pertukaran yang sama, anda perlu melihat sama ada strategi khusus mempunyai konflik logik)

• Exchange API Bagaimanakah skrip dagangan yang diprogramkan mengendalikan akaun pertukaran? Jawapannya adalah melalui antara muka API yang dibuka oleh pertukaran. Jadi apakah jenis antara muka yang terbuka kepada pertukaran? Dalam artikel sebelumnya, kami bercakap tentang bahagian “Pertukaran”, yang mengatakan bahawa pertukaran biasanya mempunyai antara muka REST dan Websocket. Di sini kami menambah beberapa konsep dari peringkat program strategik. Antara muka pertukaran dibahagikan kepada dua jenis: disahkan dan tidak disahkan, bergantung pada sama ada ia disahkan atau tidak (kedua-dua REST dan Websocket).

  • Antara muka yang tidak memerlukan pengesahan Biasanya dipanggil “antara muka awam”, antara muka jenis ini tidak memerlukan pengesahanAPI KEY(Jika anda terlupa apa itu API KEY, anda boleh rujuk artikel sebelum ini). Jenis antara muka ini secara amnya ialah antara muka pasaran, seperti menanyakan maklumat pasaran yang mendalam, menanyakan data K-line, menanyakan kadar pembiayaan, menanya maklumat berkaitan produk transaksi, menanya cap waktu pelayan pertukaran, dsb. Ringkasnya, antara muka yang tiada kaitan dengan akaun anda boleh ditentukan secara kasar sebagai antara muka awam (tiada pengesahan diperlukan)
    Pada Platform Dagangan Kuantitatif Pencipta, apabila memanggil fungsi API yang tidak disahkan (merangkum antara muka tidak disahkan bursa, antara muka awam), walaupun API KUNCI dikonfigurasikan secara tidak betul, data yang dikembalikan oleh antara muka boleh diperoleh seperti biasa. (Kerana ia tidak disahkan)

  • Antara muka yang perlu disahkan Ringkasnya, ia adalah antara muka yang perlu disahkan (disahkan oleh API KEY). Antara muka jenis ini dipanggil antara muka peribadi. Jenis antara muka ini biasanya berkaitan dengan beberapa operasi atau maklumat akaun anda, seperti pertanyaan aset akaun, pertanyaan kedudukan akaun, pertanyaan pesanan belum selesai, pertanyaan pindahan, pemindahan syiling, pelarasan leveraj, tetapan mod kedudukan, dsb. Operasi ini mesti disahkan. Pada Platform Dagangan Kuantitatif Pencipta, apabila memanggil fungsi API yang memerlukan pengesahan (antara muka yang perlu disahkan oleh pertukaran terkapsul, antara muka peribadi), jika KUNCI API dikonfigurasikan secara tidak betul, ralat akan dilaporkan semasa memanggil antara muka dan nilai null akan dikembalikan.

Jadi bagaimana antara muka ini digunakan pada Platform Dagangan Kuantitatif Pencipta?

Platform Dagangan Kuantitatif Inventor merangkum tingkah laku pertukaran dan mentakrifkan antara muka yang konsisten (seperti antara muka K-line, antara muka pasaran dalam, antara muka aset semasa pertanyaan, antara muka pesanan, antara muka pengeluaran pesanan, dll.). Platform Dagangan Kuantitatif Pencipta boleh dilihat dengan menanyakan dokumentasi API (https://www.fmz.com/api).

Jadi bagaimana untuk menggunakan beberapa antara muka pertukaran dengan gelagat dan definisi yang tidak konsisten pada Platform Dagangan Kuantitatif Pencipta?

Antara muka pertukaran ini termasuk: pemindahan aset, amanah bersyarat, penempatan pesanan kelompok, pembatalan pesanan kelompok, pengubahsuaian pesanan, dsb. Sesetengah bursa mempunyai antara muka ini, manakala yang lain tidak Fungsi dan butiran penggunaannya mungkin berbeza-beza Oleh itu, antara muka ini tersedia pada Platform Dagangan Kuantitatif.exchange.IOFungsi ini digunakan untuk mengakses (untuk butiran, sila rujuk dokumen API Platform Dagangan Kuantitatif Pencipta: https://www.fmz.com/api#exchange.io…). Terdapat juga beberapa strategi contoh IO praktikal di Dataran Strategi Platform Dagangan Kuantitatif Pencipta.

Adakah semua fungsi API dalam dokumentasi API Platform Dagangan Kuantitatif Pencipta menjana permintaan rangkaian?

Katakan dahulu antara muka API pertukaran mempunyai had kekerapan untuk akses (contohnya, 5 kali sesaat Akses tidak boleh terlalu kerap, jika tidak ralat http 429 akan dilaporkan dan akses akan dinafikan (kebanyakan laporan pertukaran 429). . Had yang sama juga digunakan untuk memanggil antara muka pertukaran berpakej pada Platform Dagangan Kuantitatif Pencipta Tiada had sedemikian untuk fungsi API pada Platform Dagangan Kuantitatif Pencipta yang tidak menjana permintaan rangkaian. Tidak semua fungsi API Platform Dagangan Kuantitatif Pencipta akan menjana permintaan rangkaian Sesetengah fungsi API Pencipta hanya mengubah suai beberapa tetapan tempatan, seperti menetapkan pasangan dagangan semasa, menetapkan kod kontrak, fungsi pengiraan penunjuk, mendapatkan nama objek pertukaran, dll. Pada asasnya, anda boleh menilai sama ada permintaan rangkaian berlaku dari tujuan fungsi Selagi ia adalah untuk mendapatkan data pertukaran, beroperasi pada akaun pertukaran, dll., permintaan rangkaian akan dihasilkan kekerapan antara muka ini.

• Mari bercakap tentang beberapa masalah dan pengalaman biasa apabila menggunakan fungsi API dalam Platform Dagangan Kuantitatif Pencipta.

  • Toleransi Kesalahan Ini adalah ralat yang paling biasa, yang menyusahkan ramai pemula Selalunya, ujian belakang strategi adalah perkara biasa, tetapi mengapa pasaran sebenar runtuh selepas berjalan untuk seketika (yang mungkin dicetuskan pada bila-bila masa)?

  

  Semasa menulis strategi, kita perlu menilai dan mengesahkan data yang dikembalikan oleh antara muka Contohnya, baris kod ini digunakan untuk mendapatkan maklumat pasaran pada Platform Dagangan Kuantitatif Pencipta (begitu juga apabila menulis program untuk mengakses bursa secara langsung. antara muka):var ticker = exchange.GetTicker()Jika kita perlu menggunakan initickerPembolehubah (lihat struktur yang dikembalikan oleh fungsi GetTicker)Last(harga terkini) data, kita perlu gunakanvar newPrice = ticker.LastDapatkan data seperti ini (apa yang baruHarga? baharu: terkini, Harga: harga, ya! Letakkannya bersama-sama!) Pada masa ini, jikaGetTicker()Tidak mengapa jika fungsi mengembalikan data biasa, tetapi jika permintaan tamat, ralat rangkaian berlaku, pertukaran mencabut kabel rangkaian, kabel dipotong, kanak-kanak nakal menarik suis kuasa, dan lain-lain, ia akan menyebabkanGetTicker()Pengembalian Fungsinull. pada masa initickerNilai ialahnullSaya akan melawatnya lagi.LastPengecualian program akan berlaku, menyebabkan program dasar dihentikan. Nampaknya kegagalan panggilan antara muka (panggilan GetTicker gagal dan dikembalikan batal) bukanlah punca langsung strategi berhenti perdagangan sebenar (sebab langsung adalah mengakses anullSifat boleh ubah), kegagalan panggilan antara muka dan ralat tidak akan menyebabkan dagangan sebenar berhenti (penekanan ditambah). Jadi apa yang boleh kita lakukan untuk mengelakkan penggantungan tidak normal perdagangan sebenar? Jawapannya adalah untuk melakukan pemprosesan toleransi kesalahan pada data yang dikembalikan oleh antara muka Sangat mudah untuk hanya menentukan sama ada data yang dikembalikannull(JavaScript digunakan sebagai contoh, bahasa lain pada dasarnya sama) Tulis coretan kod kecil untuk dijelaskan (ini hanyalah penjelasan, ia tidak akan berfungsi jika anda menjalankannya secara langsung!)

    var ticker = exchange.GetTicker()
    if (ticker) {
        var newPrice = ticker.Last
        Log("打印最新价格：", newPrice)
    } else {
        // 数据为null，不做操作就不会出问题
    }
  

  Bukan sahajaGetTickerAntara muka perlu toleran kesalahan Semua antara muka dengan permintaan rangkaian perlu toleransi kesalahan untuk nilai pulangan (jika anda menggunakan nilai pulangan fungsi). Terdapat banyak cara untuk bertolak ansur dengan kesalahan, anda boleh gunakan_C()Fungsi (lihat dokumentasi API FMZ), tulis fungsi toleransi kesalahan anda sendiri, dan reka mekanisme dan logik toleransi kesalahan anda sendiri. kira-kira_C()Apabila menggunakan fungsi, ramai pelajar baharu berkemungkinan menggunakan fungsi tersebut secara salah._C()Parameter fungsi ialah rujukan fungsi, bukan panggilan fungsi. Secara ringkas: _C(funcName, param1, param2), panggilan adalah betul, funcName tidak mempunyai kurungan, param1 dan param2 ialah parameter yang akan dihantar ke fungsi funcName. _C(funcName(param1, param2)), ralat panggilan, biasanya newbie yang tidak membaca dokumentasi FMZ API dengan teliti akan menulisnya seperti ini.

  • Kuantiti pesanan pesanan belian pasaran spot Kuantiti pesanan pesanan belian pasaran spot juga sering disalah anggap oleh ramai pedagang baru Dalam artikel sebelumnya, kami telah menyebut bahawa kuantiti pesanan pesanan belian pasaran spot biasanya adalah jumlah (sesetengah bursa mungkin mempunyai tetapan lain, secara amnya pada. FMZ, Tetapan pertukaran khas ini diterangkan dalam dokumentasi API FMZ). Sebagai contoh, saya menggunakan cakera simulasi OKEX V5 untuk ujian: Tetapan pasangan dagangan ialah:LTC_USDT

    function main() {
        exchange.IO("simulate", true)   // 切换为OKEX交易所的模拟盘
        exchange.Buy(-1, 1)             // 价格是-1，表示下的订单为市价单，数量为1表示下单量是1USDT
    }
  

  Memandangkan bursa biasanya mempunyai had jumlah pesanan, pesanan yang kurang daripada had tidak akan diserahkan (contohnya, Binance spot memerlukan setiap pesanan melebihi 5 USDT untuk berjaya diserahkan). Jadi meletakkan pesanan seperti ini akan mengakibatkan ralat:

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

  • Arah apabila membuat pesanan niaga hadapan Apabila membangunkan strategi niaga hadapan, pemula sering membuat kesilapan dalam arah pesanan, yang membawa kepada masalah Ambil strategi penulisan pada Platform Dagangan Kuantitatif Inventor sebagai contoh. Mari kita lihat terlebih dahulu penerangan dalam dokumentasi API: https://www.fmz.com/api#exchange.setdirection...

  

  Oleh kerana fungsi pesanan hanya mempunyaiBuy,Sell. Walau bagaimanapun, niaga hadapan (sudah tentu, tiada masalah dengan spot, spot hanya ada jual beli) mempunyai arah seperti buka panjang, tutup panjang, buka pendek, dan tutup pendek Jelas sekali, Beli/Jual tidak boleh mewakili operasi dalam banyak arah Pada masa ini, adalah perlu untuk memperkenalkan penetapan arah perdagangan niaga hadapan Fungsi iniexchange.SetDirection()。 Di FMZ exchange.SetDirection("buy")(tetapkan arah dahulu) danexchange.BuyApabila digunakan bersama, bermakna pesanan yang dibuat adalah pesanan untuk membuka kedudukan panjang. Dan seterusnya: exchange.SetDirection("sell")danexchange.SellApabila digunakan bersama, ia bermakna pesanan yang dibuat adalah pesanan untuk membuka kedudukan pendek. exchange.SetDirection("closebuy")danexchange.SellApabila digunakan bersama, ia bermakna pesanan yang dibuat adalah pesanan untuk menutup kedudukan panjang. exchange.SetDirection("closesell")danexchange.BuyApabila digunakan bersama, ia bermakna pesanan yang dibuat adalah pesanan untuk menutup kedudukan pendek. Biasanya newbie akanexchange.SetDirection("sell")danexchange.BuyDigunakan bersama-sama dengan orang lain, atau gabungan lain yang salah. Kemudian ia melaporkan ralat (ujian belakang mungkin tidak melaporkan ralat, tetapi ini jelas ralat logik, dan orang yang mengalami gangguan obsesif kompulsif tidak boleh bertolak ansur…). Satu lagi kesilapan biasa yang dilakukan oleh pemula

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

  
  Melihat perkara ini, anda mungkin bertanya: “Mengapa saya mempunyai kedudukan dan menggunakan closebuy dan menjual bersama-sama, tetapi ia memberikan ralat dan saya tidak boleh menutup kedudukan?” Saya akan menjawab: “Saya menutup arah yang salah! Saya menutup kedudukan panjang.” Satu lagi situasi yang mungkin untuk ralat di atas ialah: arah penutupan ditetapkan dengan betul, fungsi pesanan digunakan dengan betul, dan kedudukan dipegang dalam arah ini, tetapi ralat ini masih dilaporkan. Sebabnya ialah program anda mungkin telah membuat beberapa pesanan, tetapi pesanan awal tidak dilaksanakan, dan pesanan penutup tergantung di pasaran menunggu untuk dilaksanakan Pada masa ini, program terus menutup kedudukan, dan ia akan menggesa ralat melebihi kedudukan penutup.

  • Output log dan paparan maklumat transaksi Mereka bentuk dan menulis strategi dagangan terprogram dan kuantitatif tidak dapat dipisahkan daripada reka bentuk interaksi manusia-komputer seperti “paparan data” dan “output log operasi”. Skrip masa nyata dan program strategi biasanya ditulis dalam bahasa pengaturcaraan asli. Gunakan secara langsung fungsi output bahasa semasa. Contohnya: Ular sawaprint。 JavaScriptconsole.log。 Golangfmt.Println()。 C++cout

  Mari kita bincangkan tentang maklumat yang dipaparkan pada platform FMZ Pada Platform Dagangan Kuantitatif Inventor, terdapat dua lokasi utama di mana maklumat dipaparkan.

   - Bar Status
  Selepas cakera sebenar berjalan, halaman cakera sebenar adalah seperti yang ditunjukkan dalam rajah
  
  
  ![Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)](/upload/asset/16bafc3d4df6dfa18102.png)
  
  
  Bahagian paparan ialah maklumat bar status Bar status digunakan terutamanya untuk memaparkan beberapa data perubahan masa nyata (kerana perubahan masa nyata perlu diperhatikan dalam masa nyata, dan ia tidak boleh dicetak ke dalam log setiap kali, jadi jenis ini. daripada data boleh dipaparkan dalam bar status Jika setiap satu dicetak Log akan mengandungi banyak data berulang dan tidak bermakna, yang akan menjejaskan pertanyaan).
  Paparkan penggunaan data pada bar status`LogStatus`Fungsi, sila rujuk dokumentasi API FMZ untuk butiran.
  
   - Lajur log
  Juga pada halaman pasaran sebenar, seperti yang ditunjukkan dalam rajah:
  
  
  ![Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)](/upload/asset/16cf9d61e66384022a76.png)
  
  
  Bahagian paparan ialah bar log, yang digunakan terutamanya untuk merekodkan data tertentu secara kekal pada masa tertentu, atau untuk merekodkan operasi strategi tertentu pada masa tertentu.
  Terdapat beberapa jenis log:
  1. Log biasa: Strategi FMZ menggunakan fungsi Log untuk mengeluarkan dan mencetak dalam log strategi.
  
  
  ![Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)](/upload/asset/16ddc72e1f7d07dcfa5a.png)
  
  
  2. Log pesanan, digunakan dalam strategi FMZ`exchange.Sell`/`exchange.Buy`Ia akan direkodkan secara automatik dalam output log.
  
  
  ![Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)](/upload/asset/172aac2089e93865e3c2.png)
  
  
  3. Log pembatalan pesanan, digunakan dalam strategi FMZ`exchange.CancelOrder`, log pembatalan pesanan akan dikeluarkan secara automatik dalam log.
  
  
  ![Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)](/upload/asset/15e90c7be742743c7421.png)
  
  
  4. Log ralat Apabila strategi FMZ berjalan, jika ralat panggilan berlaku dalam antara muka untuk permintaan rangkaian atau pengecualian dilemparkan (seperti pernyataan seperti lontaran), log ralat akan dikeluarkan secara automatik dalam log.
  
  
  ![Pemula dalam Perdagangan Kuantitatif dalam Kalangan Cryptocurrency, sila lihat ini - Membawa Anda Lebih Dekat dengan Perdagangan Kuantitatif dalam Kalangan Cryptocurrency (Bahagian 2)](/upload/asset/166196451439434a800f.png)
  

  Fungsi API FMZ yang boleh menjana keluaran log, seperti Log(…), tukar.Beli(Harga, Amaun), tukar.BatalPesan(Id), dsb., boleh diikuti oleh beberapa parameter keluaran tambahan selepas parameter yang diperlukan, seperti: pertukaran BatalPesanan(pesanan[j].Id, orders[j]) Ini adalah untuk membatalkan pesanan[j] Apabila membuat pesanan ini, maklumat pesanan akan dikeluarkan.

    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, "...")
    }
  

  • Penggunaan fungsi penunjuk Sebelum bercakap tentang fungsi penunjuk, mari kita fahami terlebih dahulu apakah penunjuk itu. Ringkasnya, ia adalah garisan seperti purata bergerak, MACD, dan ATR. S: Dari mana datangnya penunjuk ini? Jawapan: Sudah tentu ia dikira. S: Apakah asas untuk pengiraan? Jawapan: Dikira berdasarkan data K-line. S: Bolehkah anda berikan contoh? Jawapan: Mengambil penunjuk paling mudah, penunjuk purata bergerak, sebagai contoh, jika kita menggunakan data K-line harian (garisan positif atau negatif mewakili hari) sebagai sumber data untuk pengiraan penunjuk. Jika parameter penunjuk purata bergerak ialah 10, maka penunjuk purata bergerak yang dikira ialah purata bergerak 10 hari. Soalan: Jika bilangan BAR garisan K kurang daripada 10, bolehkah penunjuk purata bergerak dikira? Jawapan: Bukan sahaja penunjuk purata bergerak tidak boleh dikira, tetapi mana-mana penunjuk tidak boleh mengira nilai penunjuk yang sah apabila bilangan BAR data K-line tidak memenuhi parameter kitaran penunjuk Kedudukan yang sepadan bagi tatasusunan yang dikira akan diisi dengan kosong nilai, contohnyaJavaScriptStrategi bahasa akan dipaparkan semasa mencetak data penunjuk yang dikiranull。

  Terdapat contoh pengajaran di Dataran Strategi: https://www.fmz.com/strategy/125770 Menguji semula strategi contoh tutorial ini, anda boleh melihat carta yang dijana oleh sistem ujian belakang dan purata bergerak 10 tempoh:

  

  Lukisan tersuai strategi, garis K yang dilukis dan carta purata bergerak:

  

  S: Bagaimana jika saya mahukan purata pergerakan 10 jam? Jawapan: Data K-line boleh menggunakan data K-line bagi tempoh setiap jam.

  Dalam istilah awam, garisan K yang kita lihat ialah tatasusunan selepas kita mendigitalkannya (jika anda tidak memahami konsep tatasusunan, anda boleh mencari di Baidu), di mana setiap elemen adalah lajur baris K, yang disusun mengikut urutan. Elemen pertama adalah yang paling jauh dari masa semasa, dan elemen terakhir tatasusunan adalah yang paling hampir dengan masa semasa. Biasanya bar terakhir data K-line ialah bar tempoh semasa, yang berubah dalam masa nyata dan belum selesai (anda boleh melihat perubahan dengan log masuk ke halaman bursa dan memerhatikan K-linenya). Penunjuk yang dikira juga sepadan dengan bar garis K Dalam contoh di atas, anda boleh melihat bahawa satu nilai penunjuk sepadan dengan bar garis K. Ambil perhatian bahawa lajur K-line terakhir berubah dalam masa nyata dan penunjuk yang dikira juga akan berubah dengan perubahan dalam lajur K-line.

  Pada Platform Dagangan Kuantitatif Inventor, anda boleh menggunakan perpustakaan TA (perpustakaan yang dilaksanakan oleh platform FMZ, disepadukan dalam penjaga, dan boleh digunakan secara langsung dalam pelbagai bahasa) atau perpustakaan talib (talib ialah perpustakaan penunjuk yang mantap, disepadukan dengan JS dan C++, dan Python perlu ditulis sendiri) Pasang). Sebagai contoh, dalam contoh di atas, purata bergerak dikira: Menggunakan perpustakaan TA:

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

  Menggunakan perpustakaan talib:

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

  Data penunjuk yang dikira ma ialah tatasusunan, setiap elemen yang sepadan dengan tatasusunan garis-K (rekod), iaitu,ma[ma.length -1]sepadanrecords[records.length - 1], dan seterusnya.

  Perkara yang sama berlaku untuk penunjuk kompleks lain, dan anda perlu memberi perhatian kepada penunjuk seperti MACD.

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

  Pada masa ini, macd pembolehubah ialah tatasusunan dua dimensi (jika anda tidak memahami konsepnya, anda boleh mencari di Baidu Secara ringkasnya, tatasusunan dua dimensi ialah tatasusunan dan setiap elemennya juga tatasusunan). . Soalan: Mengapakah data penunjuk macd ialah tatasusunan dua dimensi? Jawapan: Kerana penunjuk MACD terdiri daripada dua baris (garisan DIF dan baris DEA) dan satu set bar volum (bar volum MACD, sebenarnya, data bar volum ini juga boleh dianggap sebagai garis). Jadi pembolehubah macd boleh dibahagikan kepada:

    var dif = macd[0]
    var dea = macd[1]
    var macdColumn = macd[2]
  

  Terdapat juga contoh pengajaran yang telah siap di sini, jika anda berminat, sila kaji: https://www.fmz.com/strategy/151972