L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 3383

 
mytarmailS #:

Je pense qu'il confond FF et surface d'optimisation.

Je ne sais plus ce que les gens pensent, c'est une sorte de badinage.
Et tout cela ne sert à rien en termes de recherche de modèles ou d'évaluation de la robustesse.
 
Andrew, par exemple, n'a jamais eu de CT normal, mais il croit si pieusement qu'il a raison depuis 20 ans et qu'il fait quelque chose de vraiment significatif.
Et tous ces arguments sont aussi bons que des cataplasmes morts
 
fxsaber #:

Il y a une certaine sournoiserie là-dedans. Les liens ne servent qu'à s'assurer qu'ils s'ouvrent. Aucune personne "intéressée" ne les consultera. Personne ne lira les articles mâchés d'Andrei, sans parler des travaux de nature académique.


Quelqu'un a-t-il vu ce TOP facile à comprendre qui permet de calculer le classement de son propre algorithme d'optimisation ?

https://habr.com/ru/users/belyalova/publications/articles/


Il s'agit de méthodes d'optimisation basées sur le gradient pour les neurones,

et nous parlons de méthodes d'optimisation globalesans gradient,

Allez, Saber.

C'est l'ABC.

Ce dont, d'ailleurs, votre expert local en optimisations n'a rien dit dans ses articles (parce qu'il est lui-même un chêne arborescent en AO).

 
Aleksey Nikolayev #:

Lisez ceci, en particulier la section "Loss function != quality metric". Je peux difficilement écrire plus clairement.

Impossible de l'ouvrir, nous sommes un peu bloqués(

Aleksey Nikolayev #:
Cela conduit à un nombre potentiellement illimité de paramètres, puisque les espaces de fonctions sont infiniment dimensionnés. En pratique, il est nécessaire de contrôler le nombre de paramètres d'une manière ou d'une autre - pour les arbres, il s'agit de l'élagage des feuilles, par exemple.

Par exemple, les forêts AMO, les boosts consistent en des primitives, des règles.


Nous pouvons créer une grammaire Beckus Naur des règles dont nous avons besoin.

comme ceci.

grammarDef
<ex3> ::= <ex2> | <ex2> & <ex2> | <ex2> & <ex3>
<ex2> ::= <ex1> | <com>(<ex1>, <ex1>)
<ex1> ::= <op>(<var>, <var>)
<com> ::= "&" | "|"
<op>  ::= ">=" | "<=" | "==" | "!="
<var> ::= x1 | x2 | x3 | x4

Derrière chaque règle, il y a un code/chaîne/génotype.

2 3 1 3 2 4 3 2 3 1 4 4 1 2 1 4 3 2 4 3 4 1 3 4 3 1 2 1 1 3 2 4 1 4 2 4 3 3 1 4 3 2 3  ->  (x1 == x4 | x2 != x1) & (x4 >= x3 & x1 != x2) & (x3 <= x2 & x3 != x1) 
1 1 4 4 1 4 1 4 2 3 1 4 1 1 1 3 1 4 2 3 4 1 1 3 4 3 2 4 1 4 2 3 4 3 3 2 3 4 2 2 4 4 3  ->  x1 <= x2 & x4 == x2 & x2 <= x4 
2 4 1 4 1 1 1 2 1 4 4 1 2 1 3 1 2 3 3 3 3 4 4 2 2 3 1 3 4 2 2 1 2 4 2 1 4 4 3 3 1 4 3  ->  x2 >= x2 & x1 >= x2 & x2 != x3 
4 3 1 3 2 4 2 2 3 4 4 1 1 2 2 1 3 2 4 3 4 3 3 1 3 1 3 2 2 2 4 4 2 3 2 1 4 1 3 1 3 2 4  ->  (x1 == x3 | x1 != x1) & (x2 == x4 | x4 >= x1) 
1 3 3 1 4 2 2 3 4 3 3 4 4 2 2 4 3 1 4 2 1 1 3 4 2 3 1 2 3 1 1 1 3 3 2 2 2 2 2 3 3 1 2  ->  (x3 >= x3 | x4 >= x4) & x3 == x1 
2 1 2 1 3 3 1 2 3 3 2 3 3 3 2 3 4 4 4 3 4 3 2 2 3 1 4 3 4 2 4 3 4 1 2 3 1 2 1 3 1 4 3  ->  x4 != x2 & x4 != x3 & (x1 != x1 | x1 != x4) 
3 3 1 1 3 3 3 2 4 2 2 3 1 2 2 3 2 4 1 4 3 4 4 2 2 4 1 2 2 4 3 4 2 2 3 4 3 4 4 3 4 4 2  ->  x4 != x4 | x3 >= x3 
3 2 1 1 3 4 2 3 2 2 2 4 3 2 3 4 2 2 4 4 1 1 3 1 2 3 2 4 1 2 1 2 1 2 1 4 3 2 4 1 1 4 2  ->  x4 <= x1 
4 2 3 2 4 4 3 3 3 4 1 4 3 3 3 2 4 3 1 3 4 4 1 4 4 2 1 2 3 1 3 3 4 2 4 1 4 2 3 4 3 4 3  ->  x1 == x1 & (x2 >= x1 | x4 != x3) 
3 2 2 1 2 3 2 4 3 3 4 2 4 4 2 4 3 4 2 2 1 1 2 2 1 3 1 4 3 4 3 2 4 4 3 2 2 2 2 2 3 1 1  ->  x3 <= x4 

A gauche se trouve le génotype, à droite se trouve la règle générée, ce génotype peut être recherché avec l'aide d'AO.

La somme des règles est le même coup de pouce ou la forêt...

C'est en quelque sorte une évidence.


Voici le code qui implémente tout cela

library(gramEvol)
grammarDef <- CreateGrammar(list(
  ex3 = grule(ex2, ex2 & ex2, ex2 & ex3),
  ex2 = grule(ex1, com(ex1, ex1)),
  ex1 = grule( op(var, var) ),
  com = grule("&","|"),
  op = grule(">=","<=","==","!="),
  var = grule(x1,x2,x3,x4)))


for(i in 1:10){
  genotype <- sample(1:4,size = 43,replace = T)
  rule <- as.character(GrammarMap(genotype, grammarDef))
  cat(as.character(genotype), " -> ", rule, "\n")
}

Documentation du paquet

Je ne vois donc pas d'obstacle à la mise en œuvre de mon AMO purement axée sur l'optimisation et la grammaire.


Et nous avons les mains libres sur tous les fronts, toutes les fonctions, les transformations, toutes les données, en général, tout peut être implémenté.



Le même Forrest, aucune différence.

X <- iris[,1:(ncol(iris)-1)]
target <- iris[,"Species"] 


library(inTrees)
library(RRF)

target |> 
as.factor() |> 
RRF(x = X,ntree=100) |> 
RF2List() |> 
extractRules(X = X) 






697 rules (length<=6) were extracted from the first 100 trees.
       condition                                                                        
  [1,] "X[,4]<=0.8"                                                                     
  [2,] "X[,4]>0.8 & X[,4]<=1.65 & X[,4]<=1.45"                                          
  [3,] "X[,3]<=4.95 & X[,4]>0.8 & X[,4]<=1.65 & X[,4]>1.45 & X[,4]<=1.55"               
  [4,] "X[,3]>4.95 & X[,4]>0.8 & X[,4]<=1.65 & X[,4]>1.45 & X[,4]<=1.55"                
  [5,] "X[,4]>0.8 & X[,4]<=1.65 & X[,4]>1.45 & X[,4]>1.55"                              
  [6,] "X[,3]<=4.75 & X[,4]>0.8 & X[,4]>1.65 & X[,4]<=1.85 & X[,4]<=1.75"               
  [7,] "X[,3]>4.75 & X[,4]>0.8 & X[,4]>1.65 & X[,4]<=1.85 & X[,4]<=1.75"                
  [8,] "X[,1]<=5.95 & X[,3]<=4.85 & X[,4]>0.8 & X[,4]>1.65 & X[,4]<=1.85 & X[,4]>1.75"  
  [9,] "X[,1]>5.95 & X[,3]<=4.85 & X[,4]>0.8 & X[,4]>1.65 & X[,4]<=1.85 & X[,4]>1.75"   
 [10,] "X[,3]>4.85 & X[,4]>0.8 & X[,4]>1.65 & X[,4]<=1.85 & X[,4]>1.75"                 
 [11,] "X[,4]>0.8 & X[,4]>1.65 & X[,4]>1.85"                                            
 [12,] "X[,4]<=0.8"                                                                     
 [13,] "X[,3]<=4.95 & X[,4]>0.8 & X[,4]<=1.55"                                          
 [14,] "X[,3]>4.95 & X[,4]>0.8 & X[,4]<=1.55"                                           
 [15,] "X[,1]<=5.45 & X[,4]>0.8 & X[,4]>1.55 & X[,4]<=1.75"                             
 [16,] "X[,1]>5.45 & X[,3]<=5.45 & X[,4]>0.8 & X[,4]>1.55 & X[,4]<=1.75"                
 [17,] "X[,1]>5.45 & X[,3]>5.45 & X[,4]>0.8 & X[,4]>1.55 & X[,4]<=1.75"                 
 [18,] "X[,1]<=5.95 & X[,3]<=4.9 & X[,4]>0.8 & X[,4]>1.55 & X[,4]>1.75"                 
 [19,] "X[,1]>5.95 & X[,3]<=4.9 & X[,4]>0.8 & X[,4]>1.55 & X[,4]>1.75"                  
 [20,] "X[,3]>4.9 & X[,4]>0.8 & X[,4]>1.55 & X[,4]>1.75"                                
 [21,] "X[,4]<=0.8"                                                                     
 [22,] "X[,3]<=4.85 & X[,4]>0.8 & X[,4]<=1.7"                                           
 [23,] "X[,1]<=5.95 & X[,3]<=4.85 & X[,4]>0.8 & X[,4]>1.7"                              
 [24,] "X[,1]>5.95 & X[,3]<=4.85 & X[,4]>0.8 & X[,4]>1.7"                               
 [25,] "X[,1]<=6.6 & X[,3]>4.85 & X[,4]>0.8 & X[,4]<=1.65"                              
 [26,] "X[,1]>6.6 & X[,3]>4.85 & X[,4]>0.8 & X[,4]<=1.65"                               
 [27,] "X[,3]>4.85 & X[,4]>0.8 & X[,4]>1.65"                                            
 [28,] "X[,3]<=2.45"                                                                    
 [29,] "X[,3]>2.45 & X[,3]<=5.35 & X[,4]<=1.75"                                         
 [30,] "X[,3]>2.45 & X[,3]>5.35 & X[,4]<=1.75"                                          
 [31,] "X[,1]<=5.95 & X[,3]>2.45 & X[,3]<=4.85 & X[,4]>1.75"                            
 [32,] "X[,1]>5.95 & X[,3]>2.45 & X[,3]<=4.85 & X[,4]>1.75"                             
 [33,] "X[,3]>2.45 & X[,3]>4.85 & X[,4]>1.75"                                           
 [34,] "X[,3]<=2.45"           
...
..
..
..
.
.
.
 
mytarmailS #:
Impossible de l'ouvrir, nous sommes un peu bloqués(

Nous sommes souvent bloqués, mais nous nous adaptons d'une manière ou d'une autre.

mytarmailS #:
Eh bien, par exemple, les forêts AMO, les boosts sont constitués de primitives, de règles.

Je n'ai pas prétendu que l'absence d'un ensemble fixe de paramètres rendait l'apprentissage (l'optimisation) impossible. Je parlais seulement de différences significatives par rapport à l'optimisation conventionnelle avec un ensemble fixe de paramètres. Si vous ne me croyez pas, vous pouvez essayer d'implémenter des arbres ou des grammaires dans MT5 (où l'optimiseur travaille pour un ensemble fixe). Ce n'est pas que ce soit absolument impossible, mais c'est extrêmement gênant.

 
Aleksey Nikolayev #:

Je n'ai pas prétendu que l'absence d'un ensemble fixe de paramètres rendait l'apprentissage (l'optimisation) impossible. Je parlais seulement de différences significatives par rapport à l'optimisation conventionnelle avec un ensemble fixe de paramètres. Si vous ne me croyez pas, vous pouvez essayer d'implémenter des arbres ou des grammaires dans MT5 (où l'optimiseur travaille pour un ensemble fixe). Ce n'est pas que ce soit absolument impossible, mais c'est extrêmement gênant.

Le langage MQL5 vous permet de compenser l'absence de toute caractéristique standard du testeur et de l'optimiseur. Lorsqu'un ensemble dynamique de paramètres est nécessaire, vous pouvez écrire un optimiseur externe pour le modèle en MQL5.

 
Andrey Dik #:

Le langage MQL5 vous permet de compenser l'absence de caractéristiques standard du testeur et de l'optimiseur. Lorsqu'un ensemble dynamique de paramètres est nécessaire, vous pouvez écrire un optimiseur externe pour le modèle en MQL5.

Il est obligatoire d'écrire le gradient bousting en MQL5 pour devenir le créateur de la bicyclette la plus exiguë.
 

Un étudiant pose des questions à une intelligence artificielle.

Question: Quel est votre nom ?

Réponse : Vasya. Va au diable.

Question : Qu'est-ce que l'enfer ?

Réponse : C'est la réponse à votre deuxième question, Vasya.

P.Z.

La question choque le système neuronal.

 
Aleksey Nikolayev #:
Il est obligatoire d'écrire le gradient bousting en mql5 pour devenir le créateur de la bicyclette la plus merdique.

Et quelle est la différence fondamentale entre un bousting en mql5 et un bousting écrit dans n'importe quel autre langage ? mql5 est aussi rapide que C# et presque aussi rapide que C++. La syntaxe n'est pas très différente de ces langages. Pour les besoins du MO, de nombreuses fonctionnalités intégrées au langage ont été ajoutées récemment.
Un testeur standard est pratique en tant qu'environnement de négociation prêt à l'emploi, mais tout ce qui concerne la MO et l'optimisation peut être mis en œuvre sans lui si quelqu'un s'y sent à l'étroit.
Il n'y a pas de limitations fondamentales dans MT5.
 
Andrey Dik #:

Et quelle est la différence fondamentale entre le bousinage en mql5 et le bousinage écrit dans n'importe quel autre langage ? mql5 est aussi rapide que C# et presque aussi rapide que C++. La syntaxe n'est pas très différente de ces langages. Pour les besoins du MO, de nombreuses fonctionnalités intégrées au langage ont été ajoutées récemment.
Le testeur standard est pratique en tant qu'environnement de négociation prêt à l'emploi, mais tout ce qui concerne la MO et l'optimisation peut être mis en œuvre sans lui, si quelqu'un est à l'étroit dans ce langage.
Il n'y a pas de limitations fondamentales dans MT5.
Quels mécanismes de parallélisation des calculs sur le CPU dans mql5 connaissez-vous ?