Sur une application de l'OOP - page 2

 
Avals:
L'essentiel est de savoir comment l'utiliser ensuite. Pour essayer différentes entrées, vous pouvez le faire en vrac par numéro d'ensemble d'entrées. C'est-à-dire qu'il existe une collection d'ensembles d'entrée. Si cela convient, alors comme un tableau de fonctions. Les plus simples - achat ou vente inconditionnels par le marché. Ou conditionnel)). Ensuite, nous allons exécuter l'optimiseur et examiner les différents ensembles d'entrées.
Oui, il semble que jusqu'à présent, nous avons défini le nombre de stratégie dans les paramètres et optimisé par nombre dans l'optimiseur. Mais ce n'est que le début, cela fait longtemps que je rêve de faire de l'auto-optimisation à la volée.
 
Alexey Volchanskiy:
Oui, il semble que jusqu'à présent, nous avons défini un numéro de stratégie dans les paramètres et optimisé par numéro dans l'optimiseur. Mais c'est la première fois, cela fait longtemps que je rêve de faire de l'auto-optimisation à la volée.
Quel est le but de cette auto-optimisation (fonction cible) ?
 
Avals:
Quel est le but de cette auto-optimisation (fonction cible) ?

L'objectif est évident. Tout d'abord, l'optimiseur du testeur ne tient pas compte de la journée en cours, du moins dans MT4. Et je le fais pour MT4.

Deuxièmement, le marché peut changer brusquement au cours de la journée, sans aucune raison (nouvelles). Vous l'avez probablement remarqué, un plat lent... Puis soudain, comme si de la moutarde avait été répandue sous la queue, les citations commencent à tomber. Soit c'est un échec total, soit c'est le chaos total.

Je pense que nous pouvons classer ces conditions et inclure la modification requise de la stratégie lors de leur définition. Comment faire ? Je n'ai pas assez de cran pour créer une IA. Mais la méthode d'optimisation peut indirectement déterminer l'état.

Pour l'instant, ce ne sont que des pensées non testées.

 
Alexey Volchanskiy:
Oui, il semble que jusqu'à présent, dans les paramètres, nous définissons le nombre de stratégies et optimisons par numéros dans l'optimiseur. Mais c'est la première fois, cela fait longtemps que je rêve de faire de l'auto-optimisation à la volée.

Votre client veut regrouper toutes les stratégies qu'il connaît en un seul expert, si je comprends bien. Vous ne pourrez pas terminer cette tâche tant que vous n'aurez pas une liste de stratégies. Je suggère de rédiger ensemble les TdR.

Si, en plus de cette liste de stratégies, vous abordez la question de l'auto-optimisation, alors écrivez-lui un réseau neuronal, ne réinventez pas la roue et n'embrouillez pas l'esprit de votre client avec des connaissances de base en programmation. C'est exactement ce qu'il vous demande.

 
George Merts:

Et puis-je vous donner un exemple de "bashing" ?

Voilà. Hiérarchie des classes commerciales dans la bibliothèque standard :

Cela implique que le module de gestion de l'argent est un conseiller expert. Le Trailing Stop est également un Expert Advisor. Expert Advisor comprend d'autres Expert Advisors. Cet héritage incohérent résulte du fait que le trailing stop et le money management ont tous deux besoin d'accéder à certaines données et méthodes privées d'un Expert Advisor de base.

Au fait, il y a de longues guirlandes d'héritage. Les indicateurs utilisent CIndicatorBuffer qui, à son tour, appelle ses méthodes supérieures. Par conséquent, un simple traçage de la valeur de l'indicateur devient une tâche très confuse. Après trois appels récursifs, nous perdons complètement le sens de l'origine de quelque chose.

Et ce n'est qu'un exemple de mauvais héritage. En fait, toute hiérarchie plus ou moins grande de classes basée sur l'héritage devient presque toujours incohérente, confuse et récursive. Ce qui rend le débogage et le développement ultérieur extrêmement difficiles.

Nous pensons que la profondeur de l'héritage devrait être limitée à 1 ou 2 niveaux. En outre, le premier niveau doit hériter de la définition globale et universelle du CObject de niveau zéro (tous sont des objets) et mettre en œuvre l'entité spécifique "Expert", "Indicateur", "Trailing Stop". Le deuxième niveau doit mettre en œuvre l'implémentation spécifique de "Expert Advisor basé sur MACD", "indicateur SMA", "Trailing Stop", etc. Mais l'utilisation du troisième niveau doit être sévèrement punie et poursuivie.

En d'autres termes, il s'avère que la classification n'est un outil vraiment précieux que lorsqu'elle l'est :

  1. Limitée et ne crée pas de longues hiérarchies d'héritage ;
  2. Utilisé conjointement avec une conception horizontale basée sur les interfaces et les inclusions.

 
Gulnaz Akhtyamova:

Votre client veut regrouper toutes les stratégies qu'il connaît en un seul expert, si je comprends bien. Vous ne pourrez pas terminer cette tâche tant que vous n'aurez pas une liste de stratégies. Je suggère de rédiger ensemble les TdR.

Si, en plus de cette liste de stratégies, vous abordez la question de l'auto-optimisation, alors écrivez-lui un réseau neuronal, ne réinventez pas la roue et n'embrouillez pas l'esprit de votre client avec des connaissances de base en programmation. C'est exactement ce qu'il vous demande.

Il n'a pas vu une telle possibilité, c'était mon idée. Vous avez les termes de référence. L'auto-optimisation, c'est ce que je pense au fur et à mesure. J'ai toujours raison.)
 
Vasiliy Sokolov:

Voilà. Hiérarchie des classes commerciales dans la bibliothèque standard :

Cela implique que le module de gestion de l'argent est un conseiller expert. L'arrêt suiveur est également un conseiller expert. Expert Advisor comprend d'autres Expert Advisors. Cet héritage incohérent résulte du fait que le trailing stop et le money management ont tous deux besoin d'accéder à certaines données et méthodes privées d'un Expert Advisor de base.

Au fait, il y a de longues guirlandes d'héritage. Les indicateurs utilisent CIndicatorBuffer qui, à son tour, appelle ses méthodes supérieures. Par conséquent, un simple traçage de la valeur de l'indicateur devient une tâche très confuse. Après trois appels récursifs, nous perdons complètement le sens de l'origine de quelque chose.

Et ce n'est qu'un exemple de mauvais héritage. En fait, toute hiérarchie plus ou moins grande de classes basée sur l'héritage devient presque toujours incohérente, confuse et récursive. Ce qui rend le débogage et le développement ultérieur extrêmement difficiles.

Nous pensons que la profondeur de l'héritage devrait être limitée à 1 ou 2 niveaux. En outre, le premier niveau doit hériter de la définition globale et universelle du CObject de niveau zéro (tous sont des objets) et mettre en œuvre l'entité spécifique "Expert", "Indicateur", "Trailing Stop". Le deuxième niveau doit mettre en œuvre l'implémentation spécifique de "Expert Advisor basé sur MACD", "indicateur SMA", "Trailing Stop", etc. Mais l'utilisation du troisième niveau doit être sévèrement punie et poursuivie.

Maintenant je comprends l'idée. D'ailleurs, j'ai mis en œuvre cette méthode simple dans mes robots de trading, comme je l'ai indiqué. Seuls les noms sont différents.

ZS : Dans quel domaine avez-vous réalisé un tel graphique ? Quelque chose à la Doxygen ?

 
Vasiliy Sokolov:

Voilà. Hiérarchie des classes commerciales dans la bibliothèque standard :

Cela implique que le module de gestion de l'argent est un conseiller expert. L'arrêt suiveur est également un conseiller expert. Expert Advisor comprend d'autres Expert Advisors. Cet héritage incohérent résulte du fait que le trailing stop et le money management ont tous deux besoin d'accéder à certaines données et méthodes privées d'un Expert Advisor de base.

Au fait, il y a de longues guirlandes d'héritage. Les indicateurs utilisent CIndicatorBuffer qui, à son tour, appelle ses méthodes supérieures. Par conséquent, un simple suivi de la valeur de l'indicateur devient une tâche très confuse. Après trois appels récursifs, nous perdons complètement le sens de l'origine de quelque chose.

Et ce n'est qu'un exemple de mauvais héritage. En fait, toute hiérarchie plus ou moins grande de classes basée sur l'héritage devient presque toujours incohérente, confuse et récursive. Ce qui rend le débogage et le développement ultérieur extrêmement difficiles.

Nous pensons que la profondeur de l'héritage devrait être limitée à 1 ou 2 niveaux. En outre, le premier niveau doit hériter de la définition globale et universelle du CObject de niveau zéro (tous sont des objets) et mettre en œuvre l'entité spécifique "Expert", "Indicateur", "Trailing Stop". Le deuxième niveau doit mettre en œuvre l'implémentation spécifique de "Expert Advisor basé sur MACD", "indicateur SMA", "Trailing Stop", etc. Mais l'utilisation du troisième niveau doit être sévèrement punie et poursuivie.

En d'autres termes, il s'avère que la classification n'est un outil vraiment précieux que lorsqu'elle l'est :

  1. Limitée et ne crée pas de longues hiérarchies d'héritage ;
  2. Utilisé en conjonction avec la conception horizontale basée sur les interfaces et les inclusions.

+ des pensées très vraies.

 
Alexey Volchanskiy:

ZS : Dans quoi un tel graphique a-t-il été établi ? Quelque chose à la Doxygen ?

Oui, si seulement ;) J'ai travaillé dessus dans SnagIt pendant environ une heure. Je l'ai fait spécialement pour mon article.
 
Vasiliy Sokolov:
Oui, si seulement ;) J'ai travaillé sur ça dans SnagIt pendant environ une heure. Je l'ai fait spécialement pour mon article.
Ooh, fait à la main )))) Respect !