Aide Algo Stanisme

Falex, Trendline merci du rappelle

bear merci pour la ref je vais y jeter un coup d’œil

Je fais actuellement face a un probleme, je voudrais que mon algo ne trade pas entre 21H29 et 02H00 j'ai essayer ce code la qui ne marche pas

Code : #

DEFPARAM CumulateOrders = False // Cumul des positions désactivé

// Empêche le système de placer des ordres pour entrer sur le marché ou augmenter la taille d'une position avant l'heure spécifiée
noEntryBeforeTime = 020000
timeEnterBefore = time >= noEntryBeforeTime

// Empêche le système de placer des ordres pour entrer sur le marché ou augmenter la taille d'une position après l'heure spécifiée
noEntryAfterTime = 212900
timeEnterAfter = time < noEntryAfterTime

Edit : je viens de trouver !

Code : #

DEFPARAM CumulateOrders = False // Cumul des positions désactivé
// Annule tous les ordres en attente et ferme toutes les positions à 0:00, puis empêche toute création d'ordre avant l'heure "FLATBEFORE".
DEFPARAM FLATBEFORE = 020000
// Annule tous les ordres en attente et ferme toutes les positions à l'heure "FLATAFTER"
DEFPARAM FLATAFTER = 212900

Bonsoir Scalper,
Par curiosité, de tester l'algo en tick par tick change les résultats dans quels sens?

bon alors cet algo il ressemble à quoi à présent ?
Quel ut utilises-tu ?

Salut jjerome pas encore testé sur les ticks mais je pense qu'il faudra changer pas mal de réglage, mm simple par moyenne TS,ZR ou Hull

Trendline> J'ai fait un test sur le nasdasq, lancement a 15H48, pas du tout concluant, remarque ça vient de moi je me suis trompé dans un paramétrage résultat ce bougre n’arrêtait pas d'acheter dans la baisse de 20H a maintenant il a seulement comprit qu'il fallait vendre a 21H39... bref résultat décevant

Capture dax config.PNG (66.58 Kio) Vu 940 fois

"Si tu n'utilise pas le tick par tick, les stops seront touchés prioritairement aux TP.
Le backtest donnera donc - a priori - des résultats moins bons qu'en réalité."

Ce n'est pas plutôt l'inverse ? Sans le tick par tick, le TP est touché avant le SL sur une même Bougie. Le résultat des backtests est donc surévalué

Exact Anewa, merci de la correction.
C'est donc encore moins judicieux de ne pas utiliser le tick par tick.

Scalper, un conseil: je ne prétends pas avoir la science infuse mais ce que je vais te dire fait partie du principe de "walk forward", qui est dans le bouquin et utilisé ailleurs: en fait, il ne faut pas tester l'algo sur toute l'historique dont tu disposes, car sinon tu n'auras plus d'historique "vierge", sur laquelle effectuer des vérifications quant à la validité de ton algo.

J'entends par là, si tu modifies "à tâton" des paramètres de ton programme (par exemple la longueur de la moyenne mobile, ou encore la moyenne ou l'écart type utilisés pour ton bollinger) et que tu lances le test sur TOUTE l'historique dont tu disposes, forcément va arriver un moment où il sera gagnant, car tu auras adapté ton programme ("to fit" en anglais) à l'historique du sous-jacent. Bon, pendant que j'écris, je me rends compte que le "walk forward" et le principe des "in sample" et "out of sample" seront difficile à expliquer sans schéma :p regarde peut-être sur le net, il doit y avoir quelques trucs.

Disclaimer : l'optimisation d'algo est un principe qui semble déconseillé par certains, mais perso je ne vois pas d'alternative à ça, et puis ça me semble sensé d'adapter le comportement à une période donnée (in sample data) et la tester sur une plage inconnue (out of sample data). Je rationalise (et me rassure ) en me disant que c'est adapter l'algo, dont on pense que le principe est "logique", aux conditions de marché changeantes.

(mais promis je me mets à l'IA bientôt xD)

L'optimisation abouti à un algo parfait pour être gagnant dans le passé.
Découper les données entre vues et non vues est un artifice qui n'y change rien.
Car on va, bien sûr, laisser tomber les configurations rentables sur l'historique de test, mais mauvaises sur le non vu.
Au final, cela reviens à optimiser l'algo sur tout l'historique.

Voici donc mes conseils personnels, Scalper :

1) Absolument backtester sur le tick par tick (en prenant bien entendu en compte les frais de transaction et/ou le spread)

2) Ne pas céder à la tentation de l'optimisation

Le seul paramétrage ayant du sens est d'ajuster les ordres de grandeurs. Par exemple, la valeur d'un TP ne sera pas le même si l'on est en UT15 ou en 50 ticks.

Bear> merci je vois ce que tu veux dire
Takapoto> mon dernier test sur le dax30 historique de 570 trades avec tick par tick et sans tick par tick
10% d'écart

Spoiler:

Capture dax config.PNG (119.01 Kio) Vu 1028 fois

Spoiler:

Capture dax config.PNG (132.26 Kio) Vu 1028 fois

Welcome xxxx. Take a seat and some pop corn if you like.

L'optimisation abouti à un algo parfait pour être gagnant dans le passé

J'extrapole un peu sur ton propos, car je sais que tu parles de l'optimisation en particulier mais => j'ai déjà lu plusieurs fois sur Andlil qu'on ne pouvait pas se "baser sur la passé" => je ne vois pas ce qui existe, hormis le passé, qui puisse être utilisé pour imaginer le comportement futur des cours (Je ne cherche pas à te tirer les vers du nez sur ta propre stratégie :p.) Tout ce que je peux imaginer d'autre c'est une "modélisation du comportement des foules", trop abstrait pour moi.

Car on va, bien sûr, laisser tomber les configurations rentables sur l'historique de test, mais mauvaises sur le non vu.
Au final, cela reviens à optimiser l'algo sur tout l'historique.

Désolé tu m'as perdu là Taka . Pas compris ce que tu expliquais.

Au final, je ne recommande à personne l'optimisation de quoique ce soit, c'est juste une façon de faire qui marche, ou pas.

(Bon sinon il faut que je me mette à l'IA, au moins ça travaillera tout seul pour moi en comprenant mieux les occurences du passé, et en plus elle se sentira à l'aise sur le marché parmi ses petits collègues IA )

Optimiser en stop and reverse est la voie la plus rapide de la ruine (normal sur un phénomène chaotique)

Merci xxxx de rappeler régulièrement cette notion de "chaos". Je ne saisis pas bien ce que ça englobe, mais ça doit être important. J'ai un livre (conseillé par Swing il me semble) dans ma TODO concernant le chaos dans le trading => https://www.goodreads.com/book/show/621895.Trading_Chaos (il y en a un autre, plus ancien qui date de 1995).

Une réflexion sur l'optimisation, et 'l'analyse technique" en général:

Je pense qu'on peut résumer le travail des traders discrétionnaires ainsi => ils observent les graphiques pour y chercher des récurrences, adaptant parfois leurs indicateurs (longueur du RSI, de la moyenne mobile...), pour ceux qui en utilisent, aux conditions de marché qu'ils ont sous les yeux.

Une fois qu'ils ont repéré une stratégie qui fonctionne sur le passé, ils l'exécutent en temps réel en espérant que le comportement observé dans le passé continue à se reproduire. Parfois même, ils reprennent une même stratégie, un même principe, en le faisant légèrement évoluer pour prendre en compte les nouvelles conditions de marché (changement de volatilité notamment).

Je ne vois pas en quoi c'est différent de la phase d'optimisation d'un algorithme. [mode plaidoyer pour l'optimisation OFF ]
(je suis bien conscient qu'il y a des limites à l'optimisation, et qu'on risque entre autre de basculer rapidement vers la sur-optimisation ("overfitting")).

Edit: en conclusion, je précise que je ne cherche pas à avoir raison, ni à convaincre qui que ce soit. , j'échange simplement mon point de vue concernant cette façon de faire, à laquelle je ne vois pas d'alternative.

Car on va, bien sûr, laisser tomber les configurations rentables sur l'historique de test, mais mauvaises sur le non vu.
Au final, cela reviens à optimiser l'algo sur tout l'historique.

Désolé tu m'as perdu là Taka . Pas compris ce que tu expliquais.

Spoiler:

Je te parle à la première personne uniquement pour faciliter la démonstration. Je ne présuppose en rien de ce que tu penses réellement. Et je ne cherche pas à te convaincre, mais seulement à expliquer ma conviction.

a) Tu développes un très joli algo
b) Tu découpes ton historique en deux parties A et B
La partie A pour la mise au point et la partie B que tu appelles "non vue" et qui doit servir à valider le système une fois mis au point.

c) Tu fais tourner ton algo sur la partie A
....c1) Tu n'es pas satisfait du résultat, tu modifies certains paramètres et tu recommence en c)
....c2) Tu es satisfait : tu passes en d)

d) Tu fais maintenant tourner ton algo sur la partie "non vue" B pour le valider
.....d1) Tu n'est pas satisfait : tu recommence en c)
.....d2) tu es satisfait : tu passes en e)

e) Ton backtest est satisfaisant : tu lance ton algo en réel

Et bien, au final, c'est exactement comme si tu avais également optimisé sur la partie B, soi-disant non vue !

Donc, découper ses data en "vues" et "non vues" est juste de la masturbation intellectuelle pour se rassurer autant que faire se peut sur son algo.

Cet algo sera génial pour prédire le passé. Mais il sera juste bon à produire une belle equity pour être vendu aux pigeons.

Mes propos ne remettent pas du tout en cause le principe du backtest. Je pense même que c'est indispensable. Sinon, je ne me serais pas embêté à développer TakaPeek3 et louer un serveur AWS pour récupérer les historiques depuis quatre ans.

C'est juste cette méthode qui consiste à optimiser les paramètres de manière itérative, qui est illusoire.

Spoiler:

J'ai même rencontré un jour sur les forums, une personne qui soutenant qu'il était indispensable de découper les données de test en 3 parties :
- Une pour optimiser le système
- Une pour le valider
- Un troisième pour la validation finale.
Mais attention ! pour que le résultat final soit valable, il fallait absolument que la troisième partie ne soit jamais stockées sur le même support que les autres !!!
Il avait certainement peur d'une contamination

Je pense qu'on peut résumer le travail des traders discrétionnaires ainsi => ils observent les graphiques pour y chercher des récurrences, adaptant parfois leurs indicateurs (longueur du RSI, de la moyenne mobile...), pour ceux qui en utilisent, aux conditions de marché qu'ils ont sous les yeux.

C'est encore pire que l'optimisation d'un algo, car avec des moyens humains on ne peut pas trouver des récurrences sur une grande période. Ils ont une idée, par exemple utiliser un nouvel indicateur, ils la testent sur les deux dernières semaine, et ils décrètent : XYZmoku est génial !!! Ca marche un certain temps, puis ça ne marche plus. Alors ils recommencent avec un nouvel indicateur et cette fois c'est XYZhull qui est génial !!!
... et ainsi de suite.
Les vrais bons discrétionnaires ont des années d'expérience, d'études, de corrélations, etc... et leur cerveau, pour prendre la décision d'acheter ou de vendre, se base, inconsciemment, sur des milliers de données emmagasinées par des heures d'observation et ne pourra jamais être dépassé par un algo.

Bonjour, je crois que vous avez raison, je vais tout recommencer
pour l'instant débriefing de la mi séance sur l'ago dax qui tourne depuis 8H
UT 5minutes ça m'a pas l'air rentable sur le long terme

Spoiler:

Capture dax config.PNG (114.29 Kio) Vu 940 fois

UT 15 ça parait mieux

Spoiler:

Capture dax30 config.PNG (132.95 Kio) Vu 940 fois

pour la réponse détaillée Taka. Cependant, perso je ne pratique pas le "walk forward" de la manière dont tu l'exposes.

d) Tu fais maintenant tourner ton algo sur la partie "non vue" B pour le valider
.....d1) Tu n'est pas satisfait : tu recommence en c)
.....d2) tu es satisfait : tu passes en e)

=> c'est là que je diffère : si d1) je ne suis pas satisfait, je ne reviens pas en c) . En effet, les données utilisées pour faire d) sont à présent "consommées", elles n'ont plus d'utilité. En fait, je pense qu'il faut répéter l'opération plusieurs fois en déplacant la fenêtre le long de l'historique.

Exemple:
1) on optimise sur Janvier à Avril 2018 , et on teste ensuite les résultats sur Mai 2018
2) quelque soit le résultat de 1), on continue en optimisant sur Février à Mai 2018 et en testant sur Juin 2018
3) puis Mars à Juin 2018 / Juillet 2018
etc...

Et en ce qui me concerne, je m'arrête de tester et je mets l'algo de côté (ou souvent en fait je le mets carrément à la poubelle) dés que je considère que j'ai trop de mois rouges à l'étape d). J'ai constaté que très très peu d'algos survivent en faisant comme ça. (peut-être malheureusement que du coup je jette des algos qui constituaient en fait une base de travail intéressante, je ne saurais pas dire...)

Note: dans mon exemple j'ai pris 4 mois de "in sample" et 1 mois de "out of sample", mais il n'y a pas de "règle" absolue pour choisir la taille des fenêtres.

@bear, Tvede explique assez bien la problématique déjà il y a plus de 20 ans.

J'avais oublié que tu avais fait une file sur ce fameux Tvede. Je vais la lire à tête reposée (si je la retrouve :p)