Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)

Trong bài viết trước, chúng ta đã nói về các tập lệnh giao dịch theo chương trình. Trên thực tế, một chiến lược giao dịch là một chương trình kịch bản giao dịch. Bài viết chủ yếu nói về nhu cầu về một thiết bị phần cứng cho chương trình kịch bản giao dịch (nơi chương trình chạy), ngôn ngữ lập trình máy tính nào có thể được sử dụng để viết chương trình giao dịch kịch bản này (niêm yết việc sử dụng Nền tảng giao dịch định lượng Inventor Có ba ngôn ngữ lập trình. Tất nhiên, bạn có thể sử dụng bất kỳ ngôn ngữ lập trình nào để triển khai các chiến lược cho giao dịch theo chương trình). Trong bài viết này, chúng ta tiếp tục thảo luận về phân tích định lượng vòng tròn tiền điện tử và tìm hiểu kiến ​​thức về phân tích định lượng vòng tròn tiền điện tử.

Các tập lệnh giao dịch theo chương trình

• Các loại chiến lược giao dịch Những người mới tham gia giao dịch theo chương trình và giao dịch định lượng có thể bị nhầm lẫn bởi nhiều thuật ngữ khác nhau như chiến lược xu hướng, chiến lược chênh lệch giá, chiến lược tần suất cao, chiến lược lưới, v.v. Trên thực tế, các loại chiến lược phổ biến của giao dịch theo chương trình và giao dịch định lượng có thể chỉ đơn giản là được mô tả như sau: Nhiều hướng.

  • Chiến lược phòng ngừa chênh lệch giá Nói một cách đơn giản, về cơ bản, chiến lược nắm giữ vị thế mua ở một bên và vị thế bán ở bên kia có thể được phân loại là chiến lược chênh lệch giá. Có nhiều loại cụ thể, bao gồm thị trường giao ngay chéo, thị trường tương lai chéo, chênh lệch giá giao ngay-tương lai, chênh lệch giá sản phẩm chéo, v.v.
  • Chiến lược xu hướng Nói một cách đơn giản, đây là chiến lược theo dõi xu hướng để đặt lệnh và giữ vị thế, chẳng hạn như đường trung bình động kép, MACD và các chiến lược khác.
  • Chiến lược hồi quy Ví dụ, chiến lược lưới có thể kiếm được lợi nhuận từ biến động giá trên thị trường đầy biến động.
  • Chiến lược tần số cao Nói một cách đơn giản, đây là chiến lược giao dịch tần suất cao thông qua một số thuật toán để khám phá các cấu trúc vi mô, quy tắc, cơ hội, v.v. của thị trường.

Trên đây được chia theo góc nhìn chiến lược giao dịch. Theo góc nhìn thiết kế chiến lược trên Nền tảng giao dịch định lượng Inventor, chiến lược cũng có thể được chia thành:

• Chiến lược sản phẩm đơn lẻ Có nghĩa là, chiến lược này chỉ vận hành một sản phẩm, chẳng hạn như giao dịch BTC hoặc giao dịch ETH.

• Chiến lược đa sản phẩm Nói một cách đơn giản, đó là vận hành nhiều loại hình khác nhau theo một logic chiến lược.

• Chiến lược nhiều tài khoản Nói một cách đơn giản, đó là cấu hình nhiều đối tượng trao đổi trên một đĩa thực (khái niệm trao đổi đã được giới thiệu trong bài viết trước và đối tượng trao đổi có API KEY được cấu hình đại diện cho một tài khoản trao đổi). Ví dụ, một số chiến lược giao dịch sao chép liên quan đến nhiều tài khoản sau khi thực hiện giao dịch (có thể là cùng một sàn giao dịch hoặc nhiều sàn giao dịch khác nhau). Tóm lại, nhiều đối tượng giao dịch (tài khoản) được quản lý trên một tài khoản thực.

• Nhiều chiến lược logic Ví dụ, trong một thị trường thực tế, chiến lược MACD, chiến lược trung bình động, chiến lược lưới, v.v. được thiết kế cùng một lúc (tất nhiên, chúng hoạt động trên các đối tượng trao đổi khác nhau. Nếu bạn vận hành cùng một đối tượng trao đổi, bạn cần xem liệu các chiến lược cụ thể có xung đột về mặt logic)

• API trao đổi Các tập lệnh giao dịch được lập trình vận hành tài khoản giao dịch như thế nào? Câu trả lời nằm ở giao diện API do sàn giao dịch mở. Vậy những loại giao diện nào được mở để trao đổi? Trong bài viết trước, chúng ta đã nói về phần “Exchange”, trong đó nói rằng các exchange thường có giao diện REST và Websocket. Ở đây chúng tôi bổ sung thêm một số khái niệm từ cấp độ chương trình chiến lược. Giao diện trao đổi được chia thành hai loại: đã xác minh và chưa xác minh, tùy thuộc vào việc chúng đã được xác minh hay chưa (cả REST và Websocket).

  • Giao diện không yêu cầu xác thực Nói chung được gọi là “giao diện công cộng”, loại giao diện này không yêu cầu xác minhAPI KEY(Nếu bạn quên API KEY là gì, bạn có thể tham khảo bài viết trước). Loại giao diện này thường là giao diện thị trường, chẳng hạn như truy vấn thông tin thị trường chuyên sâu, truy vấn dữ liệu K-line, truy vấn tỷ lệ tài trợ, truy vấn thông tin liên quan đến sản phẩm giao dịch, truy vấn dấu thời gian của máy chủ trao đổi, v.v. Nói một cách đơn giản, một giao diện không liên quan gì đến tài khoản của bạn có thể được xác định sơ bộ là giao diện công khai (không cần xác minh)
    Trên Nền tảng giao dịch định lượng Inventor, khi gọi một hàm API chưa được xác minh (bao gồm giao diện chưa được xác minh của sàn giao dịch, giao diện công khai), ngay cả khi API KEY được cấu hình không đúng cách, dữ liệu do giao diện trả về vẫn có thể được lấy bình thường. (Vì chưa được kiểm chứng)

  • Giao diện cần được xác minh Nói một cách đơn giản, đây là một giao diện cần được xác minh (xác minh bằng API KEY). Loại giao diện này được gọi là giao diện riêng tư. Loại giao diện này thường liên quan đến một số hoạt động hoặc thông tin của tài khoản của bạn, chẳng hạn như truy vấn tài sản tài khoản, truy vấn vị thế tài khoản, truy vấn lệnh chờ, truy vấn chuyển khoản, chuyển tiền, điều chỉnh đòn bẩy, thiết lập chế độ vị thế, v.v. Những hoạt động này phải được xác minh. Trên Nền tảng giao dịch định lượng Inventor, khi gọi một hàm API yêu cầu xác minh (giao diện mà sàn giao dịch được đóng gói cần xác minh, giao diện riêng tư), nếu cấu hình API KEY không chính xác, lỗi sẽ được báo cáo khi gọi giao diện và giá trị null sẽ được trả về.

Vậy những giao diện này được sử dụng như thế nào trên Nền tảng giao dịch định lượng Inventor?

Nền tảng giao dịch định lượng Inventor bao gồm hành vi trao đổi và xác định các giao diện nhất quán (như giao diện K-line, giao diện thị trường sâu, giao diện tài sản hiện tại truy vấn, giao diện lệnh, giao diện rút lệnh, v.v.). Các giao diện này được gọi là Các hàm API của Có thể xem Nền tảng giao dịch định lượng Inventor bằng cách truy vấn tài liệu API (https://www.fmz.com/api).

Vậy làm thế nào để sử dụng một số giao diện trao đổi có hành vi và định nghĩa không nhất quán trên Nền tảng giao dịch định lượng Inventor?

Các giao diện trao đổi này bao gồm: chuyển giao tài sản, ủy thác có điều kiện, đặt lệnh hàng loạt, hủy lệnh hàng loạt, sửa đổi lệnh, v.v. Một số sàn giao dịch có các giao diện này, trong khi một số khác thì không. Chức năng và chi tiết sử dụng của chúng có thể khác nhau rất nhiều. Do đó, các giao diện này có sẵn trên Nền tảng giao dịch định lượng Inventor.exchange.IOChức năng này được sử dụng để truy cập (để biết chi tiết, vui lòng tham khảo tài liệu API của Nền tảng giao dịch định lượng Inventor: https://www.fmz.com/api#exchange.io…). Ngoài ra còn có một số ví dụ chiến lược IO thực tế trên Strategy Square của Nền tảng giao dịch định lượng Inventor.

Có phải tất cả các chức năng API trong tài liệu API của Inventor Quantitative Trading Platform đều tạo ra các yêu cầu mạng không?

Trước tiên, hãy nói rằng giao diện API trao đổi có giới hạn tần suất truy cập (ví dụ: 5 lần mỗi giây). Không được truy cập quá thường xuyên, nếu không sẽ báo lỗi http 429 và quyền truy cập sẽ bị từ chối (hầu hết các sàn giao dịch báo cáo 429) . Giới hạn tương tự cũng áp dụng cho việc gọi giao diện trao đổi đóng gói trên Nền tảng giao dịch định lượng Inventor. Không có giới hạn nào như vậy đối với các hàm API trên Nền tảng giao dịch định lượng Inventor không tạo ra yêu cầu mạng. Không phải tất cả các hàm API của Nền tảng giao dịch định lượng Inventor đều tạo ra các yêu cầu mạng. Một số hàm API của Inventor chỉ sửa đổi một số cài đặt cục bộ, chẳng hạn như cài đặt cặp giao dịch hiện tại, cài đặt mã hợp đồng, hàm tính toán chỉ báo, lấy tên đối tượng trao đổi, vân vân. Về cơ bản, bạn có thể đánh giá xem yêu cầu mạng có xảy ra hay không từ mục đích của chức năng. Miễn là để lấy dữ liệu trao đổi, hoạt động trên tài khoản trao đổi, v.v., yêu cầu mạng sẽ được tạo. Bạn cần chú ý đến việc gọi tần suất của các giao diện này.

• Chúng ta hãy cùng thảo luận về một số vấn đề và kinh nghiệm thường gặp khi sử dụng các hàm API trong Nền tảng giao dịch định lượng Inventor.

  • Khả năng chịu lỗi Đây là lỗi phổ biến nhất, gây rắc rối cho vô số người mới. Thường thì chiến lược kiểm tra ngược là bình thường, nhưng tại sao thị trường thực tế lại sụp đổ sau khi chạy một thời gian (có thể xảy ra bất cứ lúc nào)?

  

  Khi viết chiến lược, chúng ta cần đánh giá và xác minh dữ liệu được giao diện trả về. Ví dụ, dòng mã này được sử dụng để lấy thông tin thị trường trên Nền tảng giao dịch định lượng Inventor (điều tương tự cũng đúng khi viết chương trình truy cập trực tiếp vào sàn giao dịch) giao diện):var ticker = exchange.GetTicker()Nếu chúng ta cần sử dụng cái nàytickerBiến (xem cấu trúc được trả về bởi hàm GetTicker)Last(giá mới nhất) dữ liệu, chúng ta cần sử dụngvar newPrice = ticker.LastLấy dữ liệu như thế này (newPrice là gì? new: latest, Price: price, đúng rồi! Ghép chúng lại với nhau!) Lúc này, nếuGetTicker()Sẽ ổn nếu hàm trả về dữ liệu bình thường, nhưng nếu yêu cầu hết thời gian, xảy ra lỗi mạng, tổng đài rút cáp mạng, cáp bị cắt, trẻ em nghịch ngợm kéo công tắc nguồn, v.v., thì sẽ gây raGetTicker()Hàm trả vềnull. vào thời điểm nàytickerGiá trị của lànullTôi sẽ ghé thăm nơi đó lần nữa.LastSẽ xảy ra ngoại lệ chương trình, khiến chương trình chính sách dừng lại. Có vẻ như lỗi của lệnh gọi giao diện (lệnh gọi GetTicker không thành công và trả về giá trị null) không phải là nguyên nhân trực tiếp khiến chiến lược dừng giao dịch thực tế (nguyên nhân trực tiếp là truy cập vàonull(thuộc tính biến), lỗi gọi giao diện và lỗi sẽ không khiến giao dịch thực tế dừng lại (được nhấn mạnh thêm). Vậy chúng ta có thể làm gì để tránh việc tạm dừng giao dịch thực tế một cách bất thường? Câu trả lời là thực hiện xử lý chịu lỗi trên dữ liệu được giao diện trả về. Rất đơn giản để xác định xem dữ liệu trả về cónull(JavaScript được dùng làm ví dụ, các ngôn ngữ khác về cơ bản cũng giống vậy) Viết một đoạn mã nhỏ để giải thích (đây chỉ là một lời giải thích, nó sẽ không hoạt động nếu bạn chạy trực tiếp!)

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

  Không chỉGetTickerGiao diện cần phải có khả năng chịu lỗi. Tất cả các giao diện có yêu cầu mạng cần phải có khả năng chịu lỗi đối với các giá trị trả về (nếu bạn sử dụng giá trị trả về của hàm) Có nhiều cách để chịu đựng lỗi, bạn có thể sử dụng_C()Chức năng (xem tài liệu API FMZ), viết chức năng chịu lỗi của riêng bạn và thiết kế cơ chế và logic chịu lỗi của riêng bạn. Về_C()Khi sử dụng các hàm, nhiều học sinh mới có thể sử dụng chúng không đúng cách._C()Tham số hàm là tham chiếu hàm, không phải lệnh gọi hàm. Nói một cách đơn giản: _C(funcName, param1, param2), lệnh gọi là đúng, funcName không có dấu ngoặc đơn, param1 và param2 là các tham số được truyền cho hàm funcName. _C(funcName(param1, param2)), lỗi gọi, thông thường những người mới không đọc kỹ tài liệu API FMZ sẽ viết như thế này.

  • Số lượng đặt hàng của lệnh mua thị trường giao ngay Số lượng lệnh của lệnh mua trên thị trường giao ngay cũng thường bị nhiều nhà giao dịch mới nhầm lẫn. Trong bài viết trước, chúng tôi đã đề cập rằng số lượng lệnh của lệnh mua trên thị trường giao ngay thường là số tiền (một số sàn giao dịch có thể có các thiết lập khác, thường là FMZ, Các thiết lập trao đổi đặc biệt này được mô tả trong tài liệu API FMZ). Ví dụ, tôi đã sử dụng đĩa mô phỏng OKEX V5 để thử nghiệm: Cài đặt cặp giao dịch là:LTC_USDT

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

  Vì các sàn giao dịch thường có giới hạn số tiền đặt hàng nên các lệnh nhỏ hơn giới hạn sẽ không được gửi (ví dụ: Binance spot yêu cầu mỗi lệnh phải lớn hơn 5 USDT mới được gửi thành công). Vì vậy, việc đặt hàng như thế này sẽ dẫn đến lỗi:

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

  • Hướng dẫn khi đặt lệnh tương lai Khi phát triển các chiến lược tương lai, người mới thường mắc lỗi về hướng lệnh, dẫn đến vấn đề. Lấy chiến lược viết trên Nền tảng giao dịch định lượng Inventor làm ví dụ. Trước tiên chúng ta hãy xem mô tả trong tài liệu API: https://www.fmz.com/api#exchange.setdirection...

  

  Vì hàm thứ tự chỉ cóBuy,Sell. Tuy nhiên, hợp đồng tương lai (tất nhiên, không có vấn đề gì với giao ngay, giao ngay chỉ có mua và bán) có các hướng như mở lệnh mua, đóng lệnh mua, mở lệnh bán và đóng lệnh bán. Rõ ràng, Mua/Bán không thể đại diện cho các hoạt động theo nhiều hướng như vậy . Lúc này, cần phải giới thiệu thiết lập hướng giao dịch tương lai. Chức năng nàyexchange.SetDirection()。 Trên FMZ exchange.SetDirection("buy")(đặt hướng trước) vàexchange.BuyKhi sử dụng cùng nhau, điều này có nghĩa là lệnh được đặt là lệnh mở vị thế mua. Và cứ thế: exchange.SetDirection("sell")Vàexchange.SellKhi sử dụng cùng nhau, điều này có nghĩa là lệnh được đặt là lệnh mở vị thế bán khống. exchange.SetDirection("closebuy")Vàexchange.SellKhi sử dụng cùng nhau, điều này có nghĩa là lệnh được đặt là lệnh đóng một vị thế mua. exchange.SetDirection("closesell")Vàexchange.BuyKhi sử dụng cùng nhau, điều này có nghĩa là lệnh được đặt là lệnh đóng vị thế bán khống. Thông thường người mới sẽexchange.SetDirection("sell")Vàexchange.BuyĐược sử dụng kết hợp với các từ khác hoặc các kết hợp không chính xác khác. Sau đó nó báo lỗi (kiểm thử ngược có thể không báo lỗi, nhưng rõ ràng đây là lỗi logic và những người mắc chứng rối loạn ám ảnh cưỡng chế không thể chịu đựng được điều này…). Một lỗi phổ biến khác mà người mới mắc phải

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

  
  Khi thấy điều này, bạn có thể thắc mắc: “Tại sao tôi có một vị thế và sử dụng closebuy và sell cùng nhau, nhưng nó lại báo lỗi và tôi không thể đóng vị thế đó?” Tôi sẽ trả lời: “Tôi đã đóng sai hướng! Tôi đã đóng vị thế mua.” Một tình huống có thể xảy ra khác đối với lỗi trên là: hướng đóng được đặt đúng, hàm lệnh được sử dụng đúng và vị trí được giữ theo hướng này nhưng lỗi này vẫn được báo cáo. Lý do là chương trình của bạn có thể đã đặt nhiều lệnh, nhưng lệnh ban đầu không được thực hiện và lệnh đóng đang treo trên thị trường chờ được thực hiện. Vào thời điểm này, chương trình tiếp tục đóng vị thế và sẽ nhắc nhở lỗi vượt quá vị trí đóng.

  • Hiển thị thông tin giao dịch và đầu ra nhật ký Việc thiết kế và viết các chiến lược giao dịch được lập trình và định lượng là không thể tách rời khỏi việc thiết kế tương tác giữa con người và máy tính như “hiển thị dữ liệu” và “xuất nhật ký hoạt động”. Các chương trình chiến lược và kịch bản thời gian thực thường được viết bằng ngôn ngữ lập trình gốc. Sử dụng trực tiếp chức năng đầu ra của ngôn ngữ hiện tại. Ví dụ: Trănprint。 JavaScriptconsole.log。 Golangfmt.Println()。 C++cout

  Chúng ta hãy nói về thông tin được hiển thị trên nền tảng FMZ. Trên Nền tảng giao dịch định lượng Inventor, có hai vị trí chính để hiển thị thông tin.

   - Thanh trạng thái
  Sau khi đĩa thực chạy, trang đĩa thực sẽ như trong hình
  
  
  ![Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)](/upload/asset/16bafc3d4df6dfa18102.png)
  
  
  Phần hiển thị là thông tin thanh trạng thái. Thanh trạng thái chủ yếu được sử dụng để hiển thị một số dữ liệu thay đổi theo thời gian thực (vì các thay đổi theo thời gian thực cần được quan sát theo thời gian thực và chúng không thể được in vào nhật ký mọi lúc, vì vậy loại này của dữ liệu có thể được hiển thị trên thanh trạng thái. Nếu mỗi dữ liệu được in ra, nhật ký sẽ chứa nhiều dữ liệu lặp lại và vô nghĩa, điều này sẽ ảnh hưởng đến truy vấn).
  Hiển thị mức sử dụng dữ liệu trên thanh trạng thái`LogStatus`Chức năng, vui lòng tham khảo tài liệu API của FMZ để biết chi tiết.
  
   - Cột nhật ký
  Ngoài ra trên trang thị trường thực tế, như thể hiện trong hình:
  
  
  ![Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)](/upload/asset/16cf9d61e66384022a76.png)
  
  
  Phần hiển thị là thanh nhật ký, chủ yếu được sử dụng để ghi lại vĩnh viễn một số dữ liệu nhất định tại một thời điểm nhất định hoặc để ghi lại một hoạt động nhất định của chiến lược tại một thời điểm nhất định.
  Có một số loại nhật ký:
  1. Nhật ký thông thường: Chiến lược FMZ sử dụng hàm Nhật ký để xuất và in nhật ký chiến lược.
  
  
  ![Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)](/upload/asset/16ddc72e1f7d07dcfa5a.png)
  
  
  2. Nhật ký lệnh, được sử dụng trong chiến lược FMZ`exchange.Sell`/`exchange.Buy`Nó sẽ tự động được ghi lại trong nhật ký đầu ra.
  
  
  ![Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)](/upload/asset/172aac2089e93865e3c2.png)
  
  
  3. Nhật ký hủy lệnh, được sử dụng trong chiến lược FMZ`exchange.CancelOrder`, nhật ký hủy đơn hàng sẽ tự động được đưa vào nhật ký.
  
  
  ![Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)](/upload/asset/15e90c7be742743c7421.png)
  
  
  4. Nhật ký lỗi. Khi chiến lược FMZ đang chạy, nếu lỗi cuộc gọi xảy ra trong giao diện yêu cầu mạng hoặc ngoại lệ được đưa ra (chẳng hạn như câu lệnh như throw), nhật ký lỗi sẽ tự động được đưa ra trong nhật ký.
  
  
  ![Những người mới tham gia giao dịch định lượng trong giới tiền điện tử, vui lòng xem qua phần này - Đưa bạn đến gần hơn với giao dịch định lượng trong giới tiền điện tử (Phần 2)](/upload/asset/166196451439434a800f.png)
  

  Các hàm API FMZ có thể tạo đầu ra nhật ký, chẳng hạn như Log(…), exchange.Buy(Price, Amount), exchange.CancelOrder(Id), v.v., có thể theo sau một số tham số đầu ra bổ sung sau các tham số bắt buộc, chẳng hạn như: trao đổi. CancelOrder(orders[j].Id, orders[j]) Đây là để hủy đơn hàng[j] Khi thực hiện lệnh này, thông tin lệnh sẽ được đưa ra.

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

  • Sử dụng các hàm chỉ báo Trước khi nói về các chức năng của chỉ báo, trước tiên chúng ta hãy tìm hiểu chỉ báo là gì. Nói một cách đơn giản, chúng là các đường như đường trung bình động, MACD và ATR. H: Những chỉ số này đến từ đâu? Trả lời: Tất nhiên là phải tính toán. H: Cơ sở để tính toán là gì? Trả lời: Tính toán dựa trên dữ liệu đường K. H: Bạn có thể đưa ra ví dụ không? Trả lời: Lấy chỉ báo đơn giản nhất, chỉ báo trung bình động, làm ví dụ, nếu chúng ta sử dụng dữ liệu đường K hàng ngày (đường dương hoặc âm biểu thị một ngày) làm nguồn dữ liệu để tính toán chỉ báo. Nếu tham số chỉ báo trung bình động là 10, thì chỉ báo trung bình động được tính toán là trung bình động 10 ngày. Câu hỏi: Nếu số lượng thanh K-line nhỏ hơn 10 thì có thể tính được chỉ báo trung bình động không? Trả lời: Không chỉ không thể tính toán được chỉ báo trung bình động mà bất kỳ chỉ báo nào cũng không thể tính toán được giá trị chỉ báo hợp lệ khi số lượng BAR dữ liệu dòng K không đáp ứng được các tham số chu kỳ chỉ báo. Các vị trí tương ứng của mảng được tính toán sẽ được điền bằng các ô trống giá trị, ví dụJavaScriptChiến lược ngôn ngữ sẽ được hiển thị khi in dữ liệu chỉ số đã tính toánnull。

  Có một ví dụ giảng dạy trên Strategy Square: https://www.fmz.com/strategy/125770 Khi kiểm tra lại chiến lược hướng dẫn này, bạn có thể thấy biểu đồ được tạo ra bởi hệ thống kiểm tra lại và đường trung bình động 10 kỳ:

  

  Chiến lược vẽ tùy chỉnh, vẽ biểu đồ K-line và biểu đồ trung bình động:

  

  H: Tôi phải làm sao nếu muốn có đường trung bình động 10 giờ? Trả lời: Dữ liệu K-line có thể sử dụng dữ liệu K-line của chu kỳ hàng giờ.

  Nói một cách dễ hiểu, K-line mà chúng ta thấy là một mảng sau khi chúng ta số hóa nó (nếu bạn không hiểu khái niệm về mảng, bạn có thể tìm kiếm trên Baidu), trong đó mỗi phần tử là một cột K-line, được sắp xếp theo thứ tự. Phần tử đầu tiên là phần tử xa nhất so với thời gian hiện tại và phần tử cuối cùng của mảng là phần tử gần nhất với thời gian hiện tại. Thông thường, thanh dữ liệu K-line cuối cùng là thanh của giai đoạn hiện tại, thay đổi theo thời gian thực và chưa hoàn thành (bạn có thể quan sát những thay đổi bằng cách đăng nhập vào trang của sàn giao dịch và quan sát K-line của sàn đó). Các chỉ số được tính toán cũng tương ứng một-một với các thanh dòng K. Trong ví dụ trên, bạn có thể thấy rằng một giá trị chỉ số tương ứng với một thanh dòng K. Lưu ý rằng cột K-line cuối cùng thay đổi theo thời gian thực và các chỉ số được tính toán cũng sẽ thay đổi theo những thay đổi trong cột K-line.

  Trên Nền tảng giao dịch định lượng Inventor, bạn có thể sử dụng thư viện TA (một thư viện được triển khai bởi nền tảng FMZ, tích hợp trong đơn vị lưu ký và có thể sử dụng trực tiếp bằng nhiều ngôn ngữ khác nhau) hoặc thư viện talib (talib là một thư viện chỉ báo đã được thiết lập tốt, tích hợp với JS và C++, và Python cần phải do chính bạn viết) Cài đặt). Ví dụ, trong ví dụ trên, đường trung bình động được tính toán: Sử dụng thư viện TA:

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

  Sử dụng thư viện talib:

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

  Dữ liệu chỉ báo được tính toán ma là một mảng, mỗi phần tử của mảng này tương ứng với mảng K-line (bản ghi), nghĩa là,ma[ma.length -1]tương ứngrecords[records.length - 1]và vân vân.

  Điều tương tự cũng áp dụng cho các chỉ báo phức tạp khác và bạn cần chú ý đến các chỉ báo như MACD.

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

  Lúc này, biến macd là một mảng hai chiều (nếu bạn không hiểu khái niệm này, bạn có thể tìm kiếm trên Baidu). Nói một cách đơn giản, một mảng hai chiều là một mảng và mỗi phần tử của nó cũng là một mảng . Câu hỏi: Tại sao dữ liệu chỉ báo MACD lại là mảng hai chiều? Trả lời: Bởi vì chỉ báo MACD bao gồm hai đường (đường DIF và đường DEA) và một tập hợp các thanh khối lượng (thanh khối lượng MACD, trên thực tế, dữ liệu thanh khối lượng này cũng có thể được coi là một đường). Vì vậy, biến macd có thể được chia thành:

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

  Ngoài ra còn có một ví dụ giảng dạy có sẵn ở đây, nếu bạn quan tâm, vui lòng nghiên cứu: https://www.fmz.com/strategy/151972