Gamme d'optimisation - page 4

 

La tâche de l'optimisation est de trouver les paramètres de TS, auxquels nous obtenons un résultat stable sur la période testée... Plus l'intervalle de temps est large, plus vous pouvez faire confiance aux résultats obtenus à l'avenir..... Lors des tests, nous obtenons des informations presque complètes... J'aimerais également voir des courbes d'équilibre et d'équité en fonction de l'horizon temporel... Mais c'est probablement juste un rêve...

Question : à quoi servent ces courbes ? Pour y tracer des lignes brisées, ou plutôt des zigzags pour déterminer l'extrema.... Les hauts et les bas... Nous analysons les résultats et sélectionnons les paramètres...

Aujourd'hui, après avoir effectué des tests, nous ne connaissons qu'un seul extremum : le drawdown maximal qui n'est évidemment pas suffisant ...

 
Vinsent_Vega писал(а) >>

ce qui est vrai est vrai... alors je me demande si je dois prendre Neutron au mot ou pas...

Optimisé - comment ? Juste optimisé son conseiller ou quoi ? Je pensais que des recherches sérieuses avaient été faites... (Je n'ai pas lu Yezhov moi-même, donc j'ai pensé que c'était son chiffre - "4")


Vinsent, je nesuis pas un apôtre à croire. Tout ce que j'ai cité dans mes posts est facilement vérifiable par une répétition triviale.

Quant au coefficient, il peut être déterminé de deux manières non superposables : par déduction directe, ce qui m'est difficile, et par estimation. Ezhov et Shumsky ont montré la dépendance analytique de la longueur optimale de l'histoire sur le nombre de paramètres ajustables à une constante de précision de l'ordre de l'unité. Cette dépendance n'est pas limitée par le domaine d'application, il suffit donc de trouver sa valeur optimale à travers plusieurs exemples et de s'assurer de sa stationnarité, afin de ne pas jouer sans grand besoin avec des calculs mathématiques compliqués. Cela a été fait.

 

OK, merci beaucoup... :)


Pourquoi je m'y attarde tant - pour moi cette question (gamme d'optimisation) est centrale en ce moment... Peut-être que Rider a raison - à bien des égards, c'est une question de psychologie - je veux me convaincre de la fiabilité de mon choix... Mais j'ai besoin d'avoir une bonne raison (de préférence une recherche scientifique sérieuse) pour choisir un schéma d'optimisation ou un autre...


mais apparemment, je ne dois compter que sur mon expérience et mon intuition...

 
Vinsent_Vega писал(а) >>

Pourquoi est-ce que j'insiste autant sur ce point ? Pour moi, cette question (la gamme d'optimisation) est centrale en ce moment... peut-être que Rider a raison...

En fait, ce n'est pas Rider qui a raison, mais plus probablement Kharko:

kharko a écrit >>

La tâche de l'optimisation est de trouver ces paramètres de TS, quand nous obtenons un résultat stable sur le délai testé... Plus l'intervalle de temps est large, plus vous pouvez faire confiance aux résultats obtenus à l'avenir.....

Le problème est beaucoup plus vaste et plus délicat, paradoxalement. En effet, si nous nous tournons vers la formule qui montre la dépendance de l'erreur de généralisation du testeur de stratégie, nous voyons qu'elle diminue de façon monotone avec l'augmentation du nombre de transactions P: E=Eapprox+ Ecomplex=d/W+W/P, c'est-à-dire que plus l'échantillon d'entraînement est grand, mieux c'est... Mais ceci est vrai dans l'hypothèse de l'immuabilité (stationnarité) du marché, mais en fait il est changeant, et à partir de certains P les exemples deviennent inutiles, plus encore - nuisibles. Dans ces conditions, il est important de définir la limite après laquelle l'augmentation du nombre d'exemples ne fait qu'aggraver la situation. Nous devons déterminer la limite gauche du paramètre P. Cela se produira lorsque l'erreur due à la complexité du modèle est comparable à l'erreur d'approximation ou légèrement inférieure à cette dernière, et ne tend pas vers zéro, comme ce serait le cas proposé par kharko. Par conséquent, il existe un optimum doux par le paramètre P=k*W autour de k=3-6.

C'est de là que vient le coefficient, il est de la nature de la non-stationnarité des processus sur le marché.

 
Neutron >> :

Ce n'est pas vraiment le cavalier qui a raison, mais plutôt kharko:

Le problème est beaucoup plus large et plus délicat, paradoxalement. En effet, si l'on se réfère à la formule qui montre la dépendance de l'erreur de généralisation du testeur de stratégie, on constate qu'elle diminue de façon monotone avec l'augmentation du nombre de transactions P : E=Eapprox+ Ecomplex=d/W+W/P, c'est-à-dire que plus l'échantillon d'entraînement est grand, mieux c'est... Mais ceci est vrai dans l'hypothèse de l'immuabilité (stationnarité) du marché, mais en fait il est changeant, et à partir de certains P les exemples deviennent inutiles, plus encore - nuisibles. Dans ces conditions, il est important de définir la limite après laquelle l'augmentation du nombre d'exemples ne fait qu'aggraver la situation. Nous devons déterminer la limite gauche du paramètre P. Cela se produira lorsque l'erreur due à la complexité du modèle est comparable à l'erreur d'approximation ou légèrement inférieure à cette dernière, et ne tend pas vers zéro, comme ce serait le cas proposé par kharko. Par conséquent, il existe un optimum doux par le paramètre P=k*W autour de k=3-6.

C'est de là que vient ce coefficient, il est dans la nature de la non-stationnarité des processus sur le marché.

Que Dieu soit avec elle avec la justesse.... je n'insiste pas, et je ne me trouve pas autorisé à le faire ;))..... j'aimerais beaucoup croire en votre k=3-6 et me passer de tout forwards...... (((..... mais quelque chose l'empêche, et surtout, que les opérations de routine ne deviennent pas moins nombreuses : vous pourriez fixer dans l'optimiseur le nombre de transactions pour un certain intervalle - une toute autre conversation aurait lieu......

Puis-je avoir un lien vers Yezhov etc. ?

 
rider писал(а) >>

et puis-je avoir un lien vers Yezhov, etc., s'il vous plaît ? ??

Catch, pages 64-66.

Dossiers :
ts.zip  1592 kb
 
Merci.
 
Neutron писал(а) >>

Non, non. Attendez !

La fréquence des transactions par elle-même, et leur nombre optimal sur l'historique des tests par elle-même. Vous optimisez les paramètres du TS en examinant les résultats des transactions - trouvez le maximum de certaines fonctionnalités, dans ce cas, il peut s'agir du revenu cumulatif ou de la rentabilité (nombre de points par transaction). Vous avez maintenant une question : étant donné le nombre de paramètres ajustables, vous devez trouver le nombre de transactions le plus optimal, sur lequel le testeur optimisera la stratégie. Attention, pas le temps, mais le nombre d'entrées et de sorties sur le marché.

En bref, la tâche comprend uniquement le nombre de transactions - elles ne doivent pas être supérieures ou inférieures au nombre optimal. Vous avez trouvé la rentabilité optimale - le commerce. Après un certain temps, on commence à sur-optimiser et à le faire tout le temps. Comment le mettre en œuvre dans le testeur de stratégie ? Vous devez penser...

....

Si nous avons 5 paramètres optimisés dans le testeur (par exemple, les périodes d'agitation), alors la longueur optimale de l'historique doit être telle que le testeur effectue 4*5=20 transactions sur celui-ci. Cela peut prendre de 1 à ...200 jours d'histoire, tout dépend de la stratégie adoptée. La réduction de ce nombre conduira à l'adaptation du testeur à l'historique, et l'augmentation - à la détérioration de la qualité de l'approximation et, par conséquent, à la détérioration de la précision de la prédiction.

Extraits cités de vos posts.... Conclusions...

Vous affirmez qu'il existe un nombre optimal de transactions, en fonction du nombre de paramètres d'ajustement... Ok... mettons-nous d'accord....

Notre tâche consiste maintenant à trouver pour chaque exécution la plage de temps optimale dans laquelle le TS a effectué le nombre optimal estimé de transactions..... C'est-à-dire que pour certains paramètres, l'historique d'un jour est suffisant, et pour d'autres, même un an n'est pas suffisant... Cette variante ne convient pas...

OK... Simplifions la tâche.... Laissons un intervalle de temps constant... Considérons uniquement les séries qui nous donnent le nombre optimal de transactions...

Lequel est le meilleur ? La réponse est évidente... Celui qui a la plus grande espérance mathématique....

Mais qu'en est-il de ces courses que nous avons écartées... ? Ne sont-elles pas utilisables ?

Supposons que le nombre optimal de transactions soit N... Il y a une course avec ce nombre d'échanges... Mais il y a une course avec K fois plus d'affaires...

Alors que notre course idéale fera 1 transaction, une autre, non idéale en nombre de transactions, fera déjà K transactions.....

Maintenant, comparons le bénéfice que nous obtiendrons des parcours parfaits et non parfaits... Pour ce faire, multipliez le nombre de transactions par la valeur correspondante du gain attendu...

Si le bénéfice d'une exécution non idéale apparaît plus important, cela signifie que nous avons pris une trop grande période de temps pour optimiser cette exécution, car nous avons obtenu un nombre de transactions différent de celui de l'exécution optimale... Il y a une autre divergence...

Même si nous prenons une exécution qui remplit la condition du nombre optimal de transactions, alors si nous déplaçons simplement l'intervalle de temps vers la droite ou la gauche, nous obtiendrons des résultats différents pour le nombre de transactions...

Conclusion : la méthode d'optimisation proposée est une utopie.

 

à Neutron

Une dernière chose à propos du nombre de transactions : dans mon EA, il y a un paramètre comme le nombre maximum d'ordres et si les paramètres sont choisis correctement, l'augmentation du nombre de transactions simultanées effectuées par l'EA augmente le profit, mais d'un autre côté, nous obtenons un nombre non optimal de transactions dans un délai donné par rapport au nombre de paramètres d'entrée pour l'EA, comment devons-nous gérer cela ?

 

Souhaitez-vous envisager ce type d'optimisation et de backtesting ?

int start()
{
   if(IsTesting()==true)
   {
      if(IsOptimization()==true && DayOfWeek()&0xE==DayOfWeek())return;
      if(IsOptimization()==false && DayOfWeek()&0xE!=DayOfWeek())return;
   }
//код советника
//код советника
}

Au lieu de

DayOfWeek()
vous pourriez mettre une autre fonction, par exemple,

Month()

ou dans l'autre sens, un plus petit.

  Hour()
Raison: