Critère de sélection automatique des résultats d'optimisation. - page 6

Nouveau commentaire
 
Figar0 >>:

Т.е. если я правильно понял, как бы оценивать не результат, а качество сделок, насколько сделки отвечают тому, что заложено в систему?

Надо покрутить в голове.

En général, oui. L'essentiel est de pouvoir se faire une idée des métiers autant que possible. Même si le filtre rate les transactions dangereuses, vous devez les marquer d'une manière ou d'une autre et voir les chances qu'elles se déclenchent. Si le filtre déplace les risques sur la probabilité de déclenchement de l'opération plus près que le rayon du signal principal, alors ce filtre se mettra en place dans le futur. Et c'est mauvais si cela mange une grande partie de ceux qui sont rentables. Il est plus facile d'ouvrir tout ce qui se trouve dans le rayon d'ouverture le plus proche du signal et d'essayer de le conserver. L'essentiel est de définir clairement le rayon.

 

Si le TS est bien rentable, que tous les trades possibles sont ouverts et que seul le drawdown vient gâcher le tableau, alors il existe aussi un remède à cette maladie...

L'essentiel est d'avoir tous les métiers sous les yeux...

 
Voici d'ailleurs une réflexion sur le sujet...
 

Lisez la suite, lisez la suite...


J'ai oublié de vous dire que la formule que j'ai donnée n'est applicable qu'avec un lot proportionnellement croissant.

 
ivandurak >>:
А как же распределение результатов сделок . Львиная доля прибыли может быть и в начале исследуемого периода .

Je l'aime bien. Nous échangeons en temps astronomique, pas en temps tic-tac. Un conseiller expert construit dans un temps proportionnel au nombre de transactions peut présenter une ligne droite presque idéale, bien qu'elle ne soit "pas si bonne", pour ne pas dire plus : la moitié du profit est réalisée au début, sur les 100 premières transactions et au cours de la première année, tandis que l'autre moitié est réalisée sur les 100 dernières, mais dans cinq ans (également une ligne droite, avec la même pente, car il y a approximativement le même nombre de transactions réussies). Pensons à la formalisation, quelque chose comme la dépendance du bénéfice relatif du système sur l'intervalle de temps lui-même.

Bien entendu, il n'existe pas et ne peut exister un seul critère d'optimisation. Formellement, il est possible de créer un tel critère à partir de quelques dizaines de critères différents, mais à quoi cela sert-il ?

 
Mathemat >>:


Единого критерия, конечно, нет и не может быть. Ну формально такой можно составить из пары десятков разнородных критериев, но какой от него толк?

Mathemat, puis-je vous demander votre avis - quel seuil faut-il fixer pour les paramètres : nombre de transactions, gain attendu et rentabilité dans l'optimisation, disons, pendant un an avant de se soucier du filtrage par indice intégral ? Par exemple, après avoir rejeté les résultats suivants : transactions < 50, gain attendu < 50 et rentabilité < 2, je n'ai aucun problème à choisir parmi des milliers de résultats, car je dispose soit d'une mouche aléatoire, soit d'un cluster, mais maintenant on parle de nuage. A partir du nuage, je laisse la machine choisir celui qui a le plus grand Profit * Rentabilité / Drawdown en %.

Je suis intéressé par votre avis d'expert sur le nombre de transactions, le gain attendu et la rentabilité pendant l'optimisation pour l'année.

 

Vita писал(а) >> Я, к примеру, после отметания результатов: сделок < 50; матожидание < 50 и прибыльность < 2 не испытываю пробелемы выбора среди тысячи результатов, т.к. остаются либо случайные залетные, либо кластер, но нынче модно говорить облако. Из облака я для себя позволил автомату выбирать у кого больше Прибыль * Прибыльность / Просадка в %.

Vita, OK en principe. La présélection se fait sur la base du nombre d'accords, du M.O.S. et du PF, et la sélection finale se fait sur la base d'un critère intégral assez décent et de la "nébulosité". En effet, l'ensemble de la procédure implique un filtrage selon environ cinq critères différents.

Les chiffres de présélection eux-mêmes (m.o., si possible dans les anciens points pleins, c'est-à-dire à quatre chiffres ?) sont assez logiques. J'augmenterais probablement le nombre minimum de transactions (disons à 200) pour accroître la validité statistique des résultats.

 

Au fait,cet article est intéressant. J'aime la théorie de la régression, ça peut valoir la peine de l'appliquer...

Profit * Rentabilité / Drawdown en %. C'est bien, mais pour que la période de test n'affecte pas l'indice de profit, il est préférable de remplacer le pourcentage de profit par jour (pour un lot croissant proportionnellement au solde), ou l'indice de profit par jour (pour un lot fixe). Si vous ne savez pas comment calculer le pourcentage par jour, voici la formule :

Pr - pourcentage par jour/par transaction

Days_Sdelki - nombre de jours ou de transactions (selon l'objectif, pourcentage de la transaction ou pourcentage par jour)

Bal_begin - solde en début de période

Bal_end - solde en fin de période

Pr=(MathExp(((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin))))-1)*100 ;

 

ou voici la fonction


double Procent(double Days_Sdelki,double Bal_begin,double Bal_end)
{
if(Days_Sdelki>1 && Bal_begin!=0) return((MathExp((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin))))-1)*100) ;
else return(0) ;
}

 

J'ai introduit une variable utile et je teste une nouvelle version de ma formule :


PipBar - Pips/Bars (somme des pips pour toutes les transactions divisée par le nombre de barres utilisées)

PF - Facteur de profit

SdDay - nombre de transactions par jour

ProcDay - pourcentage de profit par jour (formule complexe avec logarithmes)

MD - Débit maximal

SrD - drawdown moyen (somme des drawdowns de chaque ordre divisée par le nombre d'ordres)


Si(PF>3), Vigoda=2*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)) ;
else Vigoda=(PF-1)*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)) ;


C'est une variante d'essai pour l'instant, mais je suis déjà satisfait des résultats...

12345678910
Nouveau commentaire