Que faut-il ajouter pour une prise en charge supplémentaire des calculs mathématiques universels dans MQL5 et MQL5 Cloud Network ? - page 2
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
C'est un peu différent. Ce que je voulais, c'était contrôler le cours de l'optimisation.
Grosso modo, voulez-vous votre génétique ?
A l'origine, oui, il a été demandé de la génétique.
Et je ne l'utiliserais que pour l'auto-optimisation (sélection des zones de paramètres en fonction des résultats précédents).
Et je ne l'utiliserais que pour l'auto-optimisation (sélectionner les zones de paramètres en fonction des résultats précédents).
En gros, vous voulez votre génétique ?
Dans cette direction, mais ce n'est pas si unilatéral.
Tout d'abord, si le GA standard était satisfait de tout (~10K paramètres complets, optimisation multi-paramètres), alors la plupart des insatisfaits seraient réduits au silence.
Mais il y a un autre inconvénient, parfois vous voulez arrêter l'optimisation par une sorte d'instinct, et continuer plus loin. Celles-ci permettent d'apporter des corrections manuelles au FF automatique.
Si c'est le cas, même une petite partie des utilisateurs exigeants finira par régler le problème avec GA.
Et ne laissez pas les développeurs être gênés par un petit nombre d'utilisateurs mécontents, ce sont généralement les plus avancés et c'est vers eux qu'il faut se tourner.
ZZY Mais en fait tu as raison, sa génétique est plus proche du corps, et la faire tourner dans les cludes serait cool. Au fait, il serait alors possible de résoudre le problème des tests valk-forward par eux-mêmes et de ne pas avoir à mendier ce mode auprès de MQ.
Et que les développeurs ne soient pas gênés par le fait qu'il y ait quelques mécontents, généralement les plus avancés.
En fait, ce facteur est le plus important dans le processus de rejet.
En substance, ils devront être distraits par une tâche qui ne sera utilisée que par un cercle étroit de personnes avancées.
En fait, c'est le facteur le plus important dans les refus.
En substance, ils devront être distraits par une tâche qui sera utilisée par un cercle étroit d'utilisateurs avancés.
C'est le problème, un utilisateur avancé voit plus qu'un novice, avec le temps, sa vision des problèmes s'étendra aux autres et ils voudront aussi utiliser la fonctionnalité que l'utilisateur avancé veut déjà utiliser.
Si vous vous concentrez sur le courant dominant, la plate-forme sera toujours un peu dans le passé.
Avant que Kodak ne crée une caisse à savon et un réseau de machines à développer, les touristes n'avaient aucune envie de prendre des photos eux-mêmes, c'était l'apanage des utilisateurs avancés et des professionnels de la photographie (qui étaient nombreux dans toute attraction touristique).
Mais un innovateur est arrivé et a créé un nouveau service, bouleversant ainsi le secteur et le faisant connaître aux masses.
C'est le problème, l'utilisateur avancé voit plus que l'utilisateur novice, avec le temps sa vision des problèmes se répandra aux autres et ils voudront eux aussi utiliser la fonctionnalité que l'utilisateur avancé veut déjà utiliser.
Si vous vous concentrez sur le courant dominant, la plate-forme sera toujours un peu dans le passé.
L'essentiel est qu'avant que Kodak ne crée la caisse à savon et son réseau de machines à développer, les touristes n'avaient aucune envie de prendre leurs propres photos - c'était l'apanage des utilisateurs avancés et des professionnels de la photographie (qui étaient nombreux dans toute attraction touristique).
Mais un innovateur est arrivé et a créé un nouveau service, bouleversant ainsi le secteur et le faisant connaître aux masses.
Je suis d'accord. Avec les deux. :)))
L'interface doit être pensée. Qu'est-ce que la génétique personnalisée ? Si l'interface avec la claude à faire au niveau de "SetPopullationForCalc() ; GetPopulationFitnessFuncs() ;" alors un schéma flexible et puissant ne fonctionnera pas.Il serait préférable d'implémenter l'échange avec claud au niveau des paquets de travaux à volume aléatoire où la taille de la population n'est pas fixée et est passée en paramètre avec le tableau de paramètres. De plus, il faut détacher complètement (enfin !) les données de la population.!) "optimisation" et "test", en donnant (en parallèle, arbitrairement !) des possibilités d'alterner et de combiner les demandes de (1) calcul massif et léger par la foule (analogue à l'optimisation) de matrices de paramètres avec (2) des exécutions individuelles détaillées (analogue au "test"). Ensuite, les avancées en masse sont construites sans problèmes, et toutes sortes d'autres caca et thé, qui ne sont même pas encore dans nos esprits.
Telles sont les pensées.
La conclusion est la suivante : pensez à une couche API flexible entre le testeur et les programmes dans le terminal, ce qui résoudra le vieux problème du "lancement de l'optimisation génétique en cours de négociation avec correction à la volée des paramètres du robot" ainsi que d'autres problèmes de manière discrète.En particulier, le nuage deviendra un méga-ordinateur de masse super-universel, capable de résoudre des tâches arbitraires avec de grands volumes de calculs de type unique.
Pour une bonne auto-optimisation, le testeur doit être écarté de la chaîne.
Je ne parle pas de l'auto-optimisation de l'EA au moment de l'exécution, mais, par exemple, de l'avancement du loup par vous-même.
La sélection de plages de paramètres pour les exécutions futures résoudrait ce problème à 100% (les dates peuvent être limitées de manière programmatique en utilisant les mêmes paramètres).
Mais ceci, compte tenu de l'utilisation des cludes, n'est pas aussi simple et sans ambiguïté qu'il n'y paraît.
Je ne parle pas de l'auto-optimisation del'EA en cours d'exécution, mais, par exemple, de son transfert de loup en interne.
Um, c'est la même chose de mon point de vue :)
Premièrement, si l'AG standard était satisfait en tout (~10K paramètres complets, optimisation multi-paramètres), alors la plupart des insatisfaits seraient réduits au silence.
Oui, la plupart des 5-10 insatisfaits :)