ForumSections

Algorithmes, méthodes de résolution, comparaison de leurs performances - page 23

Nouveau commentaire
Andrey Khatimlianskii:

Vous pourriez simplement avoir un intervalle plus long. Au moins 30 secondes pour le test.

Avec la normalisation.

pass 0 returned result 100000.000000 in 0:00:35.296
pass 1 returned result 100000.000000 in 0:00:29.361
pass 2 returned result 100000.000000 in 0:00:24.549
pass 3 returned result 100000.000000 in 0:00:25.067
pass 4 returned result 100000.000000 in 0:00:24.578
pass 5 returned result 100000.000000 in 0:00:24.634
pass 6 returned result 100000.000000 in 0:00:25.079
optimization finished, total passes 7
optimization done in 3 minutes 09 seconds
shortest pass 0:00:24.549, longest pass 0:00:35.296, average pass 0:00:26.937


Sans normalisation.

pass 0 returned result 100000.000000 in 0:00:33.035
pass 1 returned result 100000.000000 in 0:00:26.020
pass 2 returned result 100000.000000 in 0:00:20.137
pass 3 returned result 100000.000000 in 0:00:20.859
pass 4 returned result 100000.000000 in 0:00:21.130
pass 5 returned result 100000.000000 in 0:00:20.664
pass 6 returned result 100000.000000 in 0:00:21.001
optimization finished, total passes 7
optimization done in 2 minutes 50 seconds
shortest pass 0:00:20.137, longest pass 0:00:33.035, average pass 0:00:23.263


Les mêmes 20%.

fxsaber:

C'est ainsi que fonctionne un agent, qui compte toujours la même chose. Si vous enlevez tout le caractère aléatoire, la performance nette est proche de la plus courte.

Net n'est pas intéressant, car il n'est pas réalisable dans la réalité.

Merci pour les tests.

fxsaber:

Avec la normalisation.

Sans normalisation.

Les mêmes 20%.


20% pour une EA factice qui ne fait rien... Ce n'est pas très significatif. Dans un code réel, le chiffre serait beaucoup moins élevé. Cela vaut-il la peine de perdre du temps sur de telles futilités ?

En parlant d'optimisation des calculs, commençons par le fait qu'il n'est pas nécessaire de surveiller constamment les niveaux de tous les ordres en attente. Nous devons seulement vérifier le plus proche. S'il est atteint, on passe au niveau suivant et ainsi de suite.

Alexey Navoykov:

20% pour une EA factice qui ne fait rien... Ce n'est pas très significatif. Dans un code réel, le chiffre serait beaucoup moins élevé. Cela vaut-il la peine de perdre du temps avec de telles futilités ?

L'observation est juste. Sur mon robot normal, je vois trop de décalage dans le Tester. Il y a plusieurs raisons à cela. Et c'est l'un d'entre eux. Un passage correspond à 100 millions de tics. Prenons la génétique standard pour les passages de 10K. C'est un trillion de tics au moins. À chaque tic, le testeur effectue au moins une normalisation. Alors qu'elle ne pouvait rien faire du tout. Quelle est l'économie d'une telle optimisation ? De plus, s'embêter, c'est faire une normalisation à chaque comparaison, comme c'est le cas actuellement. Il est en fait plus facile et plus efficace de normaliser uniquement les prix entrants.

Et en parlant de l'optimisation des calculs, nous devons commencer par le fait que nous n'avons pas besoin de surveiller constamment les niveaux de tous les ordres en attente. Nous devons seulement vérifier le plus proche. S'il est atteint, le niveau suivant est vérifié, etc.

Le testeur intégré accuse un retard considérable lorsque le nombre de commandes augmente. Les TS du réseau sont ses "tueurs". J'ai suggéré une telle optimisation algorithmique. Je ne pense pas qu'ils l'entreprendront.

Nous ne parlons pas ici d'une grande quantité de calculs internes accompagnant chaque tic-tac du testeur.

1...1617181920212223
Nouveau commentaire