Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)

Dans l’article précédent, nous avons parlé des scripts de trading programmatique. En fait, une stratégie de trading est un programme de script de trading. L’article parle principalement de la nécessité d’un support matériel pour le programme de script de trading (où le programme s’exécute), du langage de programmation informatique qui peut être utilisé pour écrire ce programme de trading de script (liste l’utilisation de la plateforme de trading quantitatif Inventor Il existe trois langages de programmation. Bien entendu, vous pouvez utiliser n’importe quel langage de programmation pour mettre en œuvre des stratégies de trading programmatique). Dans cet article, nous continuons à discuter de l’analyse quantitative du cercle des crypto-monnaies et à comprendre les connaissances de l’analyse quantitative du cercle des crypto-monnaies.

Scripts de trading programmatique

• Types de stratégies de trading Les débutants qui découvrent le trading programmatique et le trading quantitatif peuvent être déroutés par divers termes tels que les stratégies de tendance, les stratégies d’arbitrage, les stratégies à haute fréquence, les stratégies de grille, etc. En fait, les types de stratégies courants du trading programmatique et du trading quantitatif peuvent être simplement décrit comme suit : Plusieurs directions.

  • Stratégie de couverture d’arbitrage En termes simples, la stratégie consistant à détenir une position longue d’un côté et une position courte de l’autre côté peut être classée comme une stratégie d’arbitrage. Il existe de nombreux types spécifiques, notamment le marché au comptant croisé, la période à terme croisée, l’arbitrage au comptant et à terme, l’arbitrage entre produits croisés, etc.
  • Stratégie de tendance En termes simples, il s’agit d’une stratégie consistant à suivre les tendances pour passer des ordres et conserver des positions, telles que les moyennes mobiles doubles, le MACD et d’autres stratégies.
  • Stratégie de régression Par exemple, la stratégie de réseau peut générer des bénéfices grâce aux fluctuations de prix sur des marchés volatils.
  • Stratégies à haute fréquence En termes simples, il s’agit d’une stratégie de trading à haute fréquence via certains algorithmes pour découvrir les microstructures du marché, les règles, les opportunités, etc.

Ce qui précède est divisé du point de vue des stratégies de trading. Du point de vue de la conception de la stratégie sur la plateforme de trading quantitatif Inventor, les stratégies peuvent également être divisées en :

• Stratégie de produit unique C’est-à-dire que cette stratégie n’exploite qu’un seul produit, comme le trading BTC ou le trading ETH.

• Stratégie multi-produits En termes simples, il s’agit d’exploiter plusieurs variétés selon une logique stratégique.

• Stratégie multi-comptes Pour faire simple, il s’agit de configurer plusieurs objets d’échange sur un disque réel (le concept d’échange a été introduit dans l’article précédent, et l’objet d’échange avec la CLÉ API configurée représente un compte d’échange). Par exemple, certaines stratégies de copy trading impliquent plusieurs comptes suivant l’opération (il peut s’agir de la même bourse ou de bourses différentes). En bref, plusieurs objets d’échange (comptes) sont gérés sur un seul compte réel.

• Stratégies logiques multiples Par exemple, sur un marché réel, la stratégie MACD, la stratégie de moyenne mobile, la stratégie de grille, etc. sont conçues en même temps (bien entendu, elles fonctionnent sur des objets d’échange différents. Si vous exploitez le même objet d’échange, vous devez voir si les stratégies spécifiques ont des conflits logiques)

• Interface API Exchange Comment les scripts de trading programmés fonctionnent-ils sur les comptes d’échange ? La réponse se fait via l’interface API ouverte par l’échange. Alors quels types d’interfaces sont ouvertes aux échanges ? Dans l’article précédent, nous avons parlé de la section « Exchange », qui disait que les échanges ont généralement des interfaces REST et Websocket. Nous ajoutons ici quelques concepts du niveau du programme stratégique. Les interfaces d’échange sont divisées en deux types : vérifiées et non vérifiées, selon qu’elles sont vérifiées ou non (REST et Websocket).

  • Interfaces qui ne nécessitent pas d’authentification Généralement appelé « interface publique », ce type d’interface ne nécessite pas de vérificationAPI KEY(Si vous oubliez ce qu’est la CLÉ API, vous pouvez vous référer à l’article précédent). Ce type d’interface est généralement une interface de marché, telle que l’interrogation d’informations approfondies sur le marché, l’interrogation de données K-line, l’interrogation de taux de financement, l’interrogation d’informations relatives aux produits de transaction, l’interrogation des horodatages des serveurs d’échange, etc. En termes simples, une interface qui n’a rien à voir avec votre compte peut être considérée comme une interface publique (aucune vérification requise)
    Sur la plateforme de trading quantitatif Inventor, lors de l’appel d’une fonction API non vérifiée (encapsulant l’interface non vérifiée de la bourse, l’interface publique), même si la CLÉ API est configurée de manière incorrecte, les données renvoyées par l’interface peuvent être obtenues normalement. (Parce que ce n’est pas vérifié)

  • Interfaces qui doivent être vérifiées En termes simples, il s’agit d’une interface qui doit être vérifiée (vérifiée par une clé API). Ce type d’interface est appelé interface privée. Ce type d’interface est généralement lié à certaines opérations ou informations de votre compte, telles que l’interrogation des actifs du compte, l’interrogation des positions du compte, l’interrogation des commandes en attente, l’interrogation des transferts, le transfert de pièces, le réglage de l’effet de levier, la définition des modes de position, etc. Ces opérations doivent être vérifiées. Sur la plateforme de trading quantitative Inventor, lors de l’appel d’une fonction API qui nécessite une vérification (l’interface que l’échange encapsulé doit vérifier, l’interface privée), si la CLÉ API est configurée de manière incorrecte, une erreur sera signalée lors de l’appel de l’interface et un une valeur nulle sera renvoyée.

Alors, comment ces interfaces sont-elles utilisées sur la plateforme de trading quantitatif Inventor ?

La plateforme de trading quantitative Inventor encapsule le comportement de l’échange et définit des interfaces cohérentes (telles que l’interface K-line, l’interface de marché profond, l’interface de requête d’actif actuel, l’interface de commande, l’interface de retrait d’ordre, etc.). Ces interfaces sont appelées Les fonctions API de l’ La plateforme de trading quantitative Inventor peut être consultée en interrogeant la documentation de l’API (https://www.fmz.com/api).

Alors, comment utiliser certaines interfaces d’échange avec des comportements et des définitions incohérentes sur la plateforme de trading quantitatif Inventor ?

Ces interfaces d’échange comprennent : le transfert d’actifs, la confiance conditionnelle, le placement d’ordres par lots, l’annulation d’ordres par lots, la modification d’ordres, etc. Certaines bourses disposent de ces interfaces, tandis que d’autres n’en ont pas. Leurs fonctions et leurs détails d’utilisation peuvent varier considérablement. Par conséquent, ces interfaces sont disponibles sur la plateforme de trading quantitative Inventor.exchange.IOCette fonction est utilisée pour accéder (pour plus de détails, veuillez vous référer au document API de la plateforme de trading quantitative Inventor : https://www.fmz.com/api#exchange.io…). Il existe également quelques exemples de stratégies d’E/S pratiques sur la plateforme de trading quantitative Inventor Strategy Square.

Toutes les fonctions API de la documentation de l’API de la plateforme de trading quantitative Inventor génèrent-elles des requêtes réseau ?

Disons tout d’abord que l’interface API d’échange a une limite de fréquence d’accès (par exemple, 5 fois par seconde). L’accès ne peut pas être trop fréquent, sinon une erreur http 429 sera signalée et l’accès sera refusé (la plupart des échanges signalent 429) . La même limitation s’applique également à l’appel de l’interface d’échange packagée sur la plateforme de trading quantitatif Inventor. Il n’existe aucune limitation de ce type pour les fonctions API sur la plateforme de trading quantitatif Inventor qui ne génèrent pas de requêtes réseau. Toutes les fonctions API de la plateforme de trading quantitative Inventor ne génèrent pas de requêtes réseau. Certaines fonctions API d’Inventor modifient uniquement certains paramètres locaux, tels que la définition de la paire de trading actuelle, la définition du code de contrat, la fonction de calcul de l’indicateur, l’obtention du nom de l’objet d’échange, etc. Fondamentalement, vous pouvez juger si une demande réseau se produit à partir de l’objectif de la fonction. Tant qu’il s’agit d’obtenir des données d’échange, d’opérer sur des comptes d’échange, etc., une demande réseau sera générée. Ces interfaces doivent prêter attention à la fréquence d’appel.

• Parlons de certains problèmes et expériences courants lors de l’utilisation des fonctions API dans la plateforme de trading quantitatif Inventor.

  • Tolérance aux pannes Il s’agit de l’erreur la plus courante, qui perturbe de nombreux débutants. Souvent, le backtest de la stratégie est normal, mais pourquoi le marché réel s’effondre-t-il après un certain temps d’exécution (qui peut être déclenché à tout moment) ?

  

  Lors de l’écriture de stratégies, nous devons juger et vérifier les données renvoyées par l’interface. Par exemple, cette ligne de code est utilisée pour obtenir des informations sur le marché sur la plateforme de trading quantitatif Inventor (il en va de même lors de l’écriture d’un programme pour accéder directement à la bourse). interface):var ticker = exchange.GetTicker()Si nous devons utiliser cecitickerVariable (voir la structure renvoyée par la fonction GetTicker)Last(dernier prix) données, nous devons utiliservar newPrice = ticker.LastObtenez les données comme ceci (qu’est-ce que newPrice ? new : latest, Price : price, oui ! Mettez-les ensemble !) À ce stade, siGetTicker()Ce n’est pas grave si la fonction renvoie des données normales, mais si la requête expire, des erreurs réseau se produisent, le commutateur débranche le câble réseau, le câble est coupé, un enfant méchant tire sur l’interrupteur d’alimentation, etc., cela provoqueraGetTicker()Fonction Renvoienull. à ce moment-làtickerLa valeur de estnullJe le visiterai à nouveau.LastUne exception de programme se produira, provoquant l’arrêt du programme de stratégie. Il semble que l’échec de l’appel d’interface (l’appel GetTicker a échoué et a renvoyé null) ne soit pas la cause directe de l’arrêt réel du trading de la stratégie (la cause directe est l’accès à unnullLes propriétés variables, l’échec de l’appel d’interface et l’erreur n’entraîneront pas l’arrêt du trading réel (soulignement ajouté). Alors que pouvons-nous faire pour éviter une suspension anormale des échanges réels ? La réponse consiste à effectuer un traitement de tolérance aux pannes sur les données renvoyées par l’interface. Il est très simple de déterminer si les données renvoyées sontnull(JavaScript est utilisé comme exemple, les autres langages sont fondamentalement les mêmes) Écrivez un petit extrait de code pour expliquer (ce n’est qu’une explication, cela ne fonctionnera pas si vous l’exécutez directement !)

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

  Pas seulementGetTickerL’interface doit être tolérante aux pannes. Toutes les interfaces avec des requêtes réseau doivent être tolérantes aux pannes pour les valeurs de retour (si vous utilisez la valeur de retour de la fonction) Il existe de nombreuses façons de tolérer les défauts, vous pouvez utiliser_C()Fonction (voir la documentation de l’API FMZ), écrivez votre propre fonction tolérante aux pannes et concevez votre propre mécanisme et logique tolérants aux pannes. à propos_C()Lors de l’utilisation de fonctions, de nombreux nouveaux étudiants sont susceptibles de les utiliser de manière incorrecte._C()Les paramètres de fonction sont des références de fonction et non des appels de fonction. En termes simples : _C(funcName, param1, param2), l’appel est correct, funcName n’a pas de parenthèses, param1 et param2 sont les paramètres à passer à la fonction funcName. _C(funcName(param1, param2)), erreur d’appel, généralement les débutants qui ne lisent pas attentivement la documentation de l’API FMZ l’écriront comme ceci.

  • Quantité commandée de l’ordre d’achat sur le marché au comptant La quantité commandée d’un ordre d’achat sur le marché spot est également souvent confondue par de nombreux nouveaux traders. Dans l’article précédent, nous avons mentionné que la quantité commandée d’un ordre d’achat sur le marché spot est généralement le montant (certaines bourses peuvent avoir d’autres paramètres, généralement sur FMZ, Ces paramètres d’échange spéciaux sont décrits dans la documentation de l’API FMZ). Par exemple, j’ai utilisé le disque de simulation OKEX V5 pour les tests : Les paramètres de la paire de trading sont :LTC_USDT

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

  Étant donné que les échanges ont généralement des limites de montant de commande, les commandes inférieures à la limite ne seront pas soumises (par exemple, Binance Spot exige que chaque commande soit supérieure à 5 USDT pour être soumise avec succès). Ainsi, passer une commande comme celle-ci entraînera une erreur :

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

  • Direction lors de la passation d’un ordre à terme Lors de l’élaboration de stratégies de contrats à terme, les débutants commettent souvent des erreurs dans le sens de l’ordre, ce qui entraîne des problèmes. Prenons comme exemple la rédaction de stratégies sur la plateforme de trading quantitatif Inventor. Commençons par regarder la description dans la documentation de l’API : https://www.fmz.com/api#exchange.setdirection...

  

  Étant donné que la fonction de commande n’a queBuy,Sell. Cependant, les contrats à terme (bien entendu, il n’y a pas de problème avec le spot, le spot ne comporte que des achats et des ventes) ont des directions telles que l’ouverture à la hausse, la clôture à la hausse, l’ouverture à la baisse et la clôture à la baisse. De toute évidence, l’achat/la vente ne peuvent pas représenter des opérations dans autant de directions . À ce stade, il est nécessaire d’introduire le réglage de la direction des transactions à terme. Cette fonctionexchange.SetDirection()。 Sur FMZ exchange.SetDirection("buy")(définir d’abord la direction) etexchange.BuyLorsqu’ils sont utilisés ensemble, cela signifie que l’ordre passé est un ordre d’ouverture d’une position longue. Et ainsi de suite: exchange.SetDirection("sell")etexchange.SellLorsqu’ils sont utilisés ensemble, cela signifie que l’ordre passé est un ordre d’ouverture d’une position courte. exchange.SetDirection("closebuy")etexchange.SellLorsqu’ils sont utilisés ensemble, cela signifie que l’ordre passé est un ordre de fermeture d’une position longue. exchange.SetDirection("closesell")etexchange.BuyLorsqu’ils sont utilisés ensemble, cela signifie que l’ordre passé est un ordre de fermeture d’une position courte. En général, les débutants le ferontexchange.SetDirection("sell")etexchange.BuyUtilisé en conjonction avec d’autres, ou d’autres combinaisons incorrectes. Ensuite, il a signalé une erreur (le backtesting peut ne pas signaler d’erreur, mais il s’agit évidemment d’une erreur logique, et les personnes atteintes de troubles obsessionnels compulsifs ne peuvent pas la tolérer…). Une autre erreur courante commise par les débutants

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

  
  En voyant cela, vous vous demandez peut-être : « Pourquoi ai-je une position et utilise-je closebuy et sell ensemble, mais cela donne une erreur et je ne peux pas fermer la position ? » Je répondrais : « J’ai fermé dans la mauvaise direction ! J’ai fermé la position longue. » Une autre situation possible pour l’erreur ci-dessus est la suivante : la direction de fermeture est correctement définie, la fonction de commande est utilisée correctement et la position est maintenue dans cette direction, mais cette erreur est toujours signalée. La raison est que votre programme a peut-être placé plusieurs ordres, mais l’ordre initial n’a pas été exécuté et l’ordre de clôture était suspendu sur le marché en attendant d’être exécuté. À ce moment-là, le programme continue de fermer la position et il vous demandera une erreur de dépassement de la position de fermeture.

  • Sortie du journal et affichage des informations sur les transactions La conception et la rédaction de stratégies de trading programmées et quantitatives sont indissociables de la conception de l’interaction homme-machine telle que « l’affichage des données » et la « sortie du journal des opérations ». Les scripts en temps réel et les programmes de stratégie sont généralement écrits dans des langages de programmation natifs. Utilisez directement la fonction de sortie de la langue actuelle. Par exemple: Pythonprint。 JavaScriptconsole.log。 Golangfmt.Println()。 C++cout

  Parlons des informations affichées sur la plateforme FMZ. Sur la plateforme de trading quantitatif Inventor, il existe deux emplacements principaux où les informations sont affichées.

   - Barre d'état
  Une fois le disque réel exécuté, la page du disque réel est celle illustrée dans la figure
  
  
  ![Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)](/upload/asset/16bafc3d4df6dfa18102.png)
  
  
  La partie affichage est la barre d'information d'état. La barre d'état est principalement utilisée pour afficher certaines données changeantes en temps réel (car les changements en temps réel doivent être observés en temps réel et ils ne peuvent pas être imprimés dans les journaux à chaque fois, donc ce type des données peuvent être affichées dans la barre d'état. Si chacune d'elles est imprimée, le journal contiendra beaucoup de données répétées et dénuées de sens, ce qui affectera la requête).
  Afficher l'utilisation des données sur la barre d'état`LogStatus`Fonction, veuillez vous référer à la documentation API de FMZ pour plus de détails.
  
   - Colonne de journal
  Également sur la page du marché réel, comme indiqué sur la figure :
  
  
  ![Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)](/upload/asset/16cf9d61e66384022a76.png)
  
  
  La partie d'affichage est la barre de journal, qui est principalement utilisée pour enregistrer de manière permanente certaines données à un certain moment, ou pour enregistrer une certaine opération d'une stratégie à un certain moment.
  Il existe plusieurs types de journaux :
  1. Journal ordinaire : la stratégie FMZ utilise la fonction Journal pour générer et imprimer le journal de stratégie.
  
  
  ![Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)](/upload/asset/16ddc72e1f7d07dcfa5a.png)
  
  
  2. Journal des commandes, utilisé dans la stratégie FMZ`exchange.Sell`/`exchange.Buy`Il sera automatiquement enregistré dans la sortie du journal.
  
  
  ![Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)](/upload/asset/172aac2089e93865e3c2.png)
  
  
  3. Journal des annulations de commandes, utilisé dans la stratégie FMZ`exchange.CancelOrder`, le journal d'annulation de commande sera automatiquement affiché dans le journal.
  
  
  ![Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)](/upload/asset/15e90c7be742743c7421.png)
  
  
  4. Journal des erreurs. Lorsque la stratégie FMZ est en cours d'exécution, si une erreur d'appel se produit dans l'interface pour une demande réseau ou si une exception est levée (comme une instruction comme throw), un journal des erreurs sera automatiquement généré dans le journal.
  
  
  ![Débutants dans le trading quantitatif dans les cercles de crypto-monnaie, veuillez jeter un œil à ceci - Vous rapprocher du trading quantitatif dans les cercles de crypto-monnaie (partie 2)](/upload/asset/166196451439434a800f.png)
  

  Les fonctions API FMZ qui peuvent générer une sortie de journal, telles que Log(…), exchange.Buy(Price, Amount), exchange.CancelOrder(Id), etc., peuvent être suivies de certains paramètres de sortie supplémentaires après les paramètres requis, comme par exemple : exchange.CancelOrder(commandes[j].Id, orders[j]) Ceci est pour annuler les commandes[j] Lorsque vous passez cette commande, les informations de la commande seront affichées.

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

  • Utilisation des fonctions indicatrices Avant de parler des fonctions indicatrices, commençons par comprendre ce que sont les indicateurs. En termes simples, il s’agit de lignes telles que les moyennes mobiles, le MACD et l’ATR. Q : D’où viennent ces indicateurs ? Réponse : Bien sûr que c’est calculé. Q : Quelle est la base du calcul ? Réponse : Calculé sur la base des données de la ligne K. Q : Pouvez-vous donner un exemple ? Réponse : Prenons l’exemple de l’indicateur le plus simple, l’indicateur de moyenne mobile. Si nous utilisons les données quotidiennes de la ligne K (une ligne positive ou négative représente un jour) comme source de données pour le calcul de l’indicateur. Si le paramètre de l’indicateur de moyenne mobile est 10, alors l’indicateur de moyenne mobile calculé est la moyenne mobile sur 10 jours. Question : Si le nombre de barres K-line est inférieur à 10, l’indicateur de moyenne mobile peut-il être calculé ? Réponse : Non seulement l’indicateur de moyenne mobile ne peut pas être calculé, mais aucun indicateur ne peut calculer une valeur d’indicateur valide lorsque le nombre de barres de données de la ligne K ne correspond pas aux paramètres du cycle de l’indicateur. Les positions correspondantes du tableau calculé seront remplies de valeurs vides valeurs, par exempleJavaScriptLa stratégie linguistique sera affichée lors de l’impression des données de l’indicateur calculénull。

  Il existe un exemple pédagogique sur Strategy Square : https://www.fmz.com/strategy/125770 En testant cet exemple de stratégie de tutoriel, vous pouvez voir le graphique généré par le système de backtesting et la moyenne mobile sur 10 périodes :

  

  Dessin personnalisé de stratégie, ligne K dessinée et graphique de moyenne mobile :

  

  Q : Que faire si je veux la moyenne mobile sur 10 heures ? Réponse : Les données de la ligne K peuvent utiliser les données de la ligne K de la période horaire.

  En termes simples, la ligne K que nous voyons est un tableau après l’avoir numérisé (si vous ne comprenez pas le concept de tableau, vous pouvez rechercher sur Baidu), dans lequel chaque élément est une colonne de ligne K, qui est organisée dans l’ordre. Le premier élément est le plus éloigné de l’heure actuelle et le dernier élément du tableau est le plus proche de l’heure actuelle. Habituellement, la dernière barre de données de la ligne K est la barre de la période en cours, qui change en temps réel et n’est pas terminée (vous pouvez observer les changements en vous connectant à la page d’une bourse et en observant sa ligne K). Les indicateurs calculés correspondent également un à un aux barres de la ligne K. Dans l’exemple ci-dessus, vous pouvez voir qu’une valeur d’indicateur correspond à une barre de la ligne K. Notez que la dernière colonne de la ligne K change en temps réel et que les indicateurs calculés changeront également avec les changements dans la colonne de la ligne K.

  Sur la plateforme de trading quantitatif Inventor, vous pouvez utiliser la bibliothèque TA (une bibliothèque implémentée par la plateforme FMZ, intégrée au dépositaire et utilisable directement dans différentes langues) ou la bibliothèque talib (talib est une bibliothèque d’indicateurs bien établie, intégré avec JS et C++, et Python doit être écrit par vous-même) Installer). Par exemple, dans l’exemple ci-dessus, la moyenne mobile est calculée : Utilisation de la bibliothèque TA :

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

  Utilisation de la bibliothèque talib :

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

  Les données de l’indicateur calculé ma sont un tableau dont chaque élément correspond au tableau K-line (enregistrements), c’est-à-dire,ma[ma.length -1]correspondrerecords[records.length - 1], et ainsi de suite.

  La même chose s’applique à d’autres indicateurs complexes, et vous devez prêter attention à des indicateurs tels que le MACD.

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

  À l’heure actuelle, la variable macd est un tableau à deux dimensions (si vous ne comprenez pas le concept, vous pouvez effectuer une recherche sur Baidu). En termes simples, un tableau à deux dimensions est un tableau et chaque élément de celui-ci est également un tableau . Question : Pourquoi les données de l’indicateur MACD sont-elles un tableau bidimensionnel ? Réponse : Étant donné que l’indicateur MACD est composé de deux lignes (ligne DIF et ligne DEA) et d’un ensemble de barres de volume (barre de volume MACD, en fait, ces données de barre de volume peuvent également être considérées comme une ligne). Ainsi, la variable macd peut être divisée en :

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

  Il existe également un exemple pédagogique prêt à l’emploi ici, si vous êtes intéressé, veuillez l’étudier : https://www.fmz.com/strategy/151972