75 000 options - 4 Go de RAM et 4 Go de cache disque ne suffisent pas ??? - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
.... Mais pourquoi n'y a-t-il que 1000 dépassements dans un si grand espace ? C'est très approximatif. J'ai exécuté ce conseiller expert dans MT4 sur une zone de 1,5 milliard de valeurs et il a abouti à 4400 rebonds nets en 4 minutes sur un historique de 18000 barres EURUSD H1. ....
Elle dépend de la qualité de la fonction cible (fitness).
- max NetProfit
- max NetProfit et min DD
- max NetProfit et max PF
- quelque chose d'autre ?
Je n'ai pas vu une telle fonction cible dans votre code. Voici ce que nous avons comme paramètres d'optimisation :En outre, nous utilisons l'algorithme original, qui est un ordre de grandeur plus rapide que les autres algorithmes que nous connaissons.
Je doute fort de 100-200 runs. Quelle est la population utilisée ? 16 ans ? :) Lorsque vous commencez avec une grande zone de recherche, vous pouvez facilement obtenir 256 dépassements dans la première génération sur 256 populations sur l'estimation initiale. C'est la variante la plus sale. Est-ce ce que vous voulez dire (exécuter la première population et s'arrêter) ? Croyez-vous aux résultats de 100-200 passages sur un champ énorme de variantes ? Qui a besoin de résultats aussi sales ?1000 exécutions, c'est un peu trop, j'utilise généralement 100-200 exécutions (pour n'importe quel nombre de paramètres) pour évaluer une solution.
Voici ce que j'ai obtenu lorsque j'ai exécuté l'échantillon MACD dans 198 build sur vos conditions initiales de la première page de ce fil :
A partir d'une zone de recherche de 35 milliards de suréchantillons, 12800 passages ont été effectués en 8 minutes 46 secondes sur un historique de 18691 barres en mode "par prix d'ouverture". Le meilleur rapport de cas est joint.
En outre, il y a beaucoup de questions sur les données incohérentes (toutes issues de vos rapports dans le fichier ZIP). Les bénéfices, le nombre de transactions, etc. ne correspondent pas du tout aux données du rapport TSGO (fichier XLS créé pour l'exécution 880, comme indiqué à la dernière page du rapport).
Aussi, pourquoi le TakeProfit est à 80 pips et le trailing stop à 6700 ?
Quelle est l'explication de tout cela ? Il semble que votre test soit si défectueux qu'il ne peut être pris en compte d'aucune manière.
Les preuves/explications doivent être simples et faciles à comprendre, et ne pas être confuses au point de devoir poser des questions comme celle-ci. Une capture d'écran qui ne montre rien et une archive avec des données incohérentes sont des preuves pour ceux qui sont trop paresseux pour comprendre.
Il se peut que ce ne soit pas clair à la volée...
Laissez-moi vous expliquer les résultats.
1. Le critère d'optimisation peut être arbitraire.
(sur la fonction cible)
Il est calculé par l'utilisateur lui-même et transmis à TSGO.
C'est-à-dire que vous pouvez utiliser à la fois ceux que vous avez et tous les autres qu'un utilisateur peut imaginer.
Par exemple, vous pouvez utiliser les gains attendus comme critère.
(c'est-à-dire la probabilité que les transactions aient un gain attendu positif, ou en d'autres termes, que le système fonctionne du côté positif)
. Ou encore, certains critères décrivant la linéarité de l'équité (cela aide à résoudre des problèmes similaires à l'optimisation de la marche avant) ...
Le critère d'optimisation joue un rôle essentiel dans l'optimisation.
(pour obtenir le bon résultat, pas de CurveFitting)
2. L'optimisation peut se faire simultanément en fonction de nombreux critères.
(sur la fonction cible)
Je n'ai qu'un prototype de la prochaine version de TSGO à la maison.
Vous pouvez y définir plusieurs critères d'optimisation simultanément (voir la fonction TS.GO.Criterion(...)).
Dans l'exemple du tableau de la visionneuse, les critères utilisés sont mis en évidence par un fond jaune - il s'agit de NetProfit, MaxDD, ProfitFactor.
C'est-à-dire que TSGO a recherché des systèmes autour du maximum de ces trois critères (MaxDD dans Omega est avec un signe moins).
C'est-à-dire qu'il a cherché des systèmes avec de gros profits, avec un facteur de profit important et un DrawDown minimal.
Des résultats intéressants peuvent être obtenus en maximisant simultanément le NetProfit pour chaque année (ou mois),
c'est-à-dire en recherchant des systèmes ayant de bons résultats pour chaque année ou même mois de l'historique.
(dans TSGO les critères d'optimisation peuvent être définis jusqu'à 1000, en réalité j'ai essayé jusqu'à présent environ 150-200 - c'est NetProfit par mois sur MSFT)
3. La taille de notre population peut atteindre 1000 exemplaires (nous pourrions faire plus, mais cela semble trop important).
(Je doute fortement que 100-200 runs. Alors quel type de population est utilisé ? 16 ? :))
Dans cet exemple particulier, je pense que c'était 100 (voir la valeur du paramètre dans TS.GO.Popul(...))
J'utilise généralement des populations de 50-100, parfois 1000.
En général, cela a peu d'effet, vous pouvez toujours le régler sur 1000, cela n'a presque aucun effet sur la vitesse de recherche.
Les résultats sont très précis, même avec 500 exécutions avec une population de 1000 ... :))
Je vous ai dit que j'utilisais mon propre algorithme original, dont on n'a jamais entendu parler sur Internet.
Il est beaucoup plus rapide que tous les autres algorithmes que je connais (et que vous utilisez probablement).
La taille de la population qui s'y trouve n'a pas d'importance (tant qu'elle n'est pas trop petite) ...
Est-ce ce que vous voulez dire (exécuter la première population et s'arrêter) ?
C'est ce que vous dites, ça fonctionne différemment pour moi.
Croyez-vous aux résultats de 100-200 passages sur un champ énorme de variantes ?
C'est le cas. De plus, je suis pratiquement sûr que les résultats de CS sont indépendants du nombre de variantes dans l'espace des paramètres.
Qui a besoin de résultats aussi sales ?
Ils ne sont pas désordonnés, ils sont raisonnablement suffisants.
Il n'est jamais garanti d'obtenir des résultats précis en CS.
La seule façon d'obtenir un résultat précis est de faire un dépassement complet.
C'est-à-dire que vous avez toujours une estimation - un résultat approximatif.
Mon algorithme peut obtenir une bonne estimation dans la plupart des cas dès 100-200 passages.
Sur une zone de recherche de 35 milliards de recherches, 12800 passages ont été effectués
. Dans mon algorithme, 2000 passages étaient plus que suffisants.
Malheureusement, vos rapports ne sont pas aussi simples et indicatifs que ceux de MetaTrader. Vous avez posté le fichier de rapport XLS d'Omega avec le numéro d'exécution de population 880, bien qu'il n'y ait aucune description des paramètres trouvés de cette exécution 880 nulle part (ni dans le rapport XLS lui-même, ni dans le rapport TSGO, ni dans les captures d'écran de ce fil).
Ce qu'il faut faire...
Si Omega Research a acheté notre TSGO et l'a intégré dans son paquet, alors ce serait juste une case à cocher comme la vôtre.
Mais pour l'instant, ce n'est qu'une extension de TradeStation.
Tout est correct avec les résultats.
La passe 880 est la meilleure selon Omega (par le critère NetProfit),
mais pas la meilleure selon TSGO (simultanément par les critères NetProfit, MaxDD, ProfitFactor)
TSGO utilise Omega uniquement pour l'organisation des boucles de contournement.
En outre, vous pouvez choisir n'importe quel critère disponible dans Omega, et cela n'affecte pas le travail de TSGO.
TSGO effectue l'optimisation sur la base des critères spécifiés par l'utilisateur dans le code du signal.
Le numéro de la manche obtenue dans Omega ne joue pas non plus de rôle.
Lorsque l'optimisation est terminée, les résultats sont donnés pour l'instance de la première ligne du visualiseur.
En outre, il y a beaucoup de questions sur les données incohérentes (tout ceci provient de vos rapports dans le fichier ZIP). Les bénéfices, le nombre de transactions, etc. ne correspondent pas du tout aux données du rapport TSGO (le fichier XLS est créé pour l'exécution 880, qui est indiquée sur la dernière page du rapport).
Oui, on peut avoir ce sentiment, vous avez fait un excellent travail en analysant mon exemple ... :))
Une petite clarification s'impose ici.
Le fait est que TSGO utilise une caractéristique d'Omega pour signaler le meilleur système trouvé.
Le meilleur système est la première ligne du visualiseur, substituez ses paramètres et vous verrez une correspondance complète des résultats avec le rapport.
Omega recherche le système en fonction de ses critères (peu importe lesquels),
TSGO recherche le système en fonction de ses critères, définis dans le signal par l'utilisateur.
Pendant le processus d'optimisation, Omega fait passer le paramètre Gen de 1 à K (il s'agit du paramètre d'optimisation défini dans Omega).
La valeur de Gen est envoyée à TSGO.
Si Gen augmente, alors TSGO sort les paramètres du nouveau candidat pour tester les résultats de l'exécution.
Si Gen n'a pas augmenté, alors TSGO considère que l'optimisation est terminée (Omega recalcule le meilleur résultat à son avis),
dans ce cas TSGO sort les paramètres de la meilleure instance trouvée (de la première ligne du visualisateur).
En général, lorsque l'optimisation est terminée, le rapport Omega montre les résultats de l'instance dès la première ligne du visualiseur.
Comparez leurs paramètres et ils sont exactement les mêmes.
Tout cela parce que TSGO est une extension d'Omega et n'en fait pas partie.
Il n'y a pas d'autre moyen de le faire.
============================================================================
Renat, je vous assure que ces données sont absolument réelles, et que tout ce qu'elles contiennent est absolument correct.
La confusion vient du fait que nous ne sommes pas les développeurs d'Omega, et que nous ne pouvons pas construire l'optimiseur dans Omega.
Croyez-vous aux résultats de 100-200 passages sur un champ énorme de variantes ?
Ne soyez pas un croyant. Auriez-vous l'amabilité de prouver votre point de vue sur ce recomptage :Je le sais. De plus, je suis à peu près sûr que les résultats de CS ne dépendent pas du nombre de variantes dans l'espace des paramètres.
Tout est correct avec les résultats.
Donc :La course 880 est la meilleure selon Omega (selon le critère NetProfit),
mais pas le meilleur selon TSGO (par les critères NetProfit, MaxDD, ProfitFactor simultanément)
- Vous n'avez pas listé les paramètres de la meilleure course trouvée 880
- Vous nous dites que "le noir est blanc", en le justifiant par les particularités de votre addon.
- Vous avez envoyé un rapport Omega sciemment incorrect
- Vous n'avez pas indiqué exactement quelle fonction cible vous avez utilisée pour obtenir les résultats de 1000 passages, et vous êtes plutôt passé en mode "vous pouvez faire ceci ou cela" (le programmeur peut fixer lui-même le critère dans le code - montrez ce critère dans votre code EL)
Ne me confirmez pas. Mieux vaut _prouver_ les chiffres et les rapports. Vous nous avez obligés à passer au domaine de la résolution des problèmes au niveau des "chevaux dans un vide sphérique" (merci pour cela), nous avons bougé et résolu le problème. Mais vous ne l'avez résolu en aucune façon, et vous nous avez même induits en erreur avec des rapports erronés.Tout ce que vous avez cité comme preuve depuis le tout début de ce fil est une absurdité totale avec des jeux de mots. Il n'y a pas de preuve, juste un jeu de chiffres farfelus. Auriez-vous l'amabilité de prendre IBM Daily de 1970 à 1999 (exactement du début de 1970 au début de 1999) et d'exécuter les limites ci-dessus (exactement les leurs) et de publier un tel rapport afin qu'il n'y ait aucune revendication. Et je publierai le mien.
Et pourquoi je dois toujours trouver des excuses ici ?
Si vous voulez que je quitte le forum, je vous en prie.
Bannissez-moi ici aussi, et je ferai plus de travail et moins de distractions.
Si vous ne comprenez pas quelque chose, cela ne signifie pas qu'on vous a menti.
Ça veut juste dire que tu ne comprends pas, et en société polie.
les gens demandent juste des explications pour les choses qu'ils ne comprennent pas.
Les gens ont l'habitude de juger les autres par eux-mêmes.
Pour ma part, je n'ai jamais mis en doute l'honnêteté des participants au forum.
(Contrairement à vous...).
Je vais répondre dans l'ordre.
1. Dans un de mes posts, j'ai écrit :
En outre, nous utilisons l'algorithme original, qui est un ordre de grandeur plus rapide que les autres algorithmes que nous connaissons.
Pour l'estimation d'une solution, j'utilise généralement 100 à 200 exécutions (pour n'importe quel nombre de paramètres).
Vous m'avez répondu :
Croyez-vous vous-même aux résultats de 100-200 passages sur un champ énorme de variantes ?
N'ayez pas la foi. Auriez-vous l'amabilité de prouver vos dires sur ce nouveau calcul :Je le sais. De plus, je suis absolument certain que les résultats de CS ne dépendent pas du nombre de variantes dans l'espace des paramètres.
---
Qu'est-ce que je dois te prouver ?
Que "j'utilise généralement 100-200 passages (pour n'importe quel nombre de paramètres)" ?
Et je considère que ces résultats sont suffisamment fiables ?
C'est mon opinion, et pourquoi devrais-je la prouver ?
Vous ne le pensez pas ? - C'est votre droit.
Vous pouvez juste dire, "Je ne pense pas."
Il y aura deux opinions sur un même sujet.
2. Vous n'avez pas donné la liste des meilleurs paramètres trouvés pour la course 880.
La course 880 n'est pas la meilleure en termes de TSGO,
et il se peut qu'il ne fasse plus partie de la population.
Le meilleur résultat est 919, qui est montré dans la première ligne de la visionneuse TSGO.
C'est celui que vous voyez dans le rapport Omega.
Comparez.
Dans le visualiseur, ligne 1.
Gen = 919 (c'est le numéro de la manche)
Négociations = 52
Bénéfice net = 29312.07
MaxDD = -4939.19
PF = 7,42
Dans le rapport Omega
Bénéfice net total = 29 312,07 $.
Nombre total de transactions = 52
Max intraday drawdown = ($4,939.19)
Facteur de profit = 7,42
Pourquoi Omega a fait la course numéro 880, j'ai écrit dans un message précédent.
3. Vous m'avez envoyé un faux rapport d'Oméga.
J'ai envoyé un rapport délibérément faux à Omega, regardez plus attentivement.
4. Vous n'avez pas spécifié exactement quelle fonction cible vous avez utilisé pour obtenir les résultats pour 1000 passages
Je l'ai déjà écrit dans mon post précédent, l'optimisation a été effectuée simultanément en utilisant trois critères - NetProfit, MaxDD, ProfitFactor. Ils sont mis en évidence dans le visualiseur avec un fond jaune.
Dans le code de signal dans Easy, ils sont définis par la fonction TS.GO.Criterion.
Voici un extrait de code :
R = TS.GO.Method(1) ; -- permettant l'optimisation multicritères.
R = TS.GO.Criterion("NetProfit",1) ; -- premier critère
R = TS.GO.Criterion("MaxDD",1) ; -- deuxième critère
R = TS.GO.Criterion("PF",1) ; -- troisième critère
Les valeurs des critères sont attribuées à la fin du code, sur la dernière barre :
R = TS.GO.Set("NetProfit",NetProfit) ;
R = TS.GO.Set("MaxDD",MaxIDDrawDown) ;
R = TS.GO.Set("PF",GrossProfit/(0.001-GrossLoss)) ;
Je n'ai aucune envie d'écouter vos attaques.
Si nous devons parler, nous devons être sur un pied d'égalité.
Êtes-vous d'accord ?
Alors essayez de prouver vos affirmations.
1. Vous avez envoyé un rapport manifestement faux à Omega.
2. Vous n'avez pas indiqué exactement quelle fonction cible vous avez utilisée pour obtenir vos résultats.
3. Et vous ne l'avez pas résolu vous-même de quelque manière que ce soit, et vous l'avez également induit en erreur avec des rapports incorrects.
4. Tout ce que vous avez donné comme preuve depuis le début de ce fil est un non-sens complet avec des jeux de mots. (Ce n'est pas seulement une affirmation, c'est déjà une insulte).
5. Il n'y a aucune preuve, juste un jeu de chiffres farfelus.
Je ne cesse de suggérer de passer du domaine des jeux de mots au domaine des rapports pratiques. La dernière fois, j'ai suggéré que le problème soit à nouveau résolu. Pouvez-vous le résoudre et publier des rapports incontestables ?
Après cette tâche, nous pouvons passer sans problème à une déclaration sur la suffisance de 100-200 exécutions sur d'énormes champs de variantes.
Il n'y a eu qu'un seul malentendu avec le numéro de série d'Omega.
Dans le prochain billet, je vous expliquerai en détail de quoi il s'agit.
Environ la suffisance de 100-200 passages sur d'énormes champs de variantes.
Je n'ai pas fait de déclaration ou d'affirmation.
J'ai littéralement écrit ce qui suit :
... J'utilise généralement 100-200 exécutions (pour un nombre quelconque de paramètres) pour estimer une solution.
Comprenez-vous la différence entre "estimation" et "suffisance" ?
C'est particulièrement intéressant lorsqu'il s'agit de rapports et d'épreuves, comme je le demande généralement - tout simplement. Vous avez besoin de rapports informatiques comportant chacun au maximum une ligne de commentaire de l'auteur.
Je serais heureux de vous l'expliquer en deux mots, mais si vous ne le comprenez pas, je dois écrire des articles d'un kilomètre de long ...
Après cette mission...
Et vous m'avez engagé pour me donner des missions ?
J'attends toujours que vous prouviez vos CONCLUSIONS.
Si vous faites des déclarations techniques scandaleuses, ayez la gentillesse de les prouver.
Nous avons déjà eu affaire à 100-200 passages et les résultats se sont avérés absolument sales (bien qu'"estimés") (je l'ai dit tout de suite, mais vous n'étiez pas d'accord). Et vous avez dû l'admettre seulement sous la pression.
Je ne fais pas de déclarations techniques farfelues.
Pour être plus précis - pour vous, ils peuvent être hors limites, mais pour moi, ils sont tout à fait ordinaires et fonctionnent.
Nous avons déjà traité 100-200 passages et il s'avère que ces résultats sont absolument sales (bien qu'"estimés") (je l'ai dit tout de suite, mais vous n'étiez pas d'accord). Et cela, vous n'avez dû l'admettre que sous la pression.
Ce ne sont pas des résultats "absolument sales" mais tout à fait exploitables.
Et je n'ai accepté rien sous aucune pression.
J'ai dit la même chose depuis le début, je peux le dire encore.
Spécialement pour vous,
J'ai effectué une autre optimisation dans Omega.
Je n'ai laissé qu'un seul critère d'optimisation - NetProfit- pour vous faciliter la tâche.
Le même critère a été utilisé dans Omega.
Il y a eu 1000 passages au total.
IBM, 7800 barres, jusqu'au 31 décembre 1999
(Omega n'a pas de date de début de période, il a une date de fin et un nombre de barres)
Test sur les barres quotidiennes par la barre de fermeture (par l'ouverture Omega ne le fait pas)
Stops, toes et trailing dans le code fait par les ordres en attente,
comme Omega à l'intérieur de la barre ne fonctionne pas autrement et les données ont seulement des barres quotidiennes.
Dans la pièce jointe:
@Renat.txt - Code de signal EL, diffère du précédent en ce qu'il ne reste qu'un seul critère.
1000.XLS - rapport du système Omega (meilleure exécution selon Omega)
SOR.xls - rapport de test Omega (toutes les exécutions)
TSGO-1000.CSV - composition de la dernière population dans TSGO (taille de la population 100).
Le bloc de définition des critères a été modifié dans le code du signal:
R = TS.GO.Method(1) ;
R = TS.GO.Criterion("NetProfit",1) ; -- deuxième paramètre = 1 - recherche du critère maximum
R = TS.GO.Criterion("MaxDD",0) ; -- deuxième paramètre = 0 - l'optimisation par critère est désactivée
R = TS.GO.Criterion("NetProfit",1).GO.Criterion("PF",0) ; -- deuxième paramètre = 0 - l'optimisation par critère est désactivée
Veuillez noter
1. La première ligne dans le visualiseur correspond à la première ligne dans la population et correspond aux résultats dans Omega.
2. le numéro de la meilleure exécution dans le visualiseur est 401, dans Omega 948, si vous regardez dans SOR.xls vous verrez que ces exécutions ont les mêmes résultats. TSGO rejette les résultats de correspondance répétés.
3. si vous regardez la composition de la dernière population, vous verrez que le meilleur résultat trouvé a NetProfit 1891.86 (sur 401 runs), le résultat de 213 runs est 1814.16, le résultat de 93 runs est 1796.40. C'est-à-dire que le résultat de la 93ème exécution diffère de 5,3% du meilleur résultat après 1000 exécutions, ce qui n'est pas mauvais et peut être considéré comme une bonne estimation du NetProfit.
Voici une capture d'écran