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 554 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.