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
J'ai laissé de côté le paramètre"longueur du motif " pour spécifier la longueur du motif numérique (ce paramètre n'est utilisé que pour le mode optimisation).
Et une défense rapide - si vous sélectionnez un type de modèle de chaîne en mode optimisation, le conseiller expert retournera "INIT_PARAMETERS_INCORRECT".
Il faut penser à tout tout de suite, pour ne pas avoir à tout refaire plus tard.
....
Encore une fois, si nous revenons à la configuration "Evening Star", elle peut être considérée comme une prise de contrôle haussière à petite bougie et une prise de contrôle haussière à baissière. Cela signifie que nous avons un modèle composite composé d'une bougie haussière et d'une absorption baissière. Et si nous additionnons les trois chandeliers de la figure, nous obtenons à nouveau une barre d'épingle.
Laissez-moi insérer mes 5 kopeck.
Cette tâche n'a pas été fixée et il est impossible de tout prévoir en même temps. Dans ce cas, le concept initial qui était prévu comme étant le concept de base sera perdu : un utilisateur construit la séquence de chandeliers haussiers et baissiers et le programme recherche ces séquences et effectue des transactions, alors pourquoi résumer les chandeliers en un seul motif ?
Permettez-moi d'insérer mes cinq cents.
Ce n'était pas la tâche, et il est impossible de tout prévoir en même temps, auquel cas nous perdons le concept original qui a été conçu comme le principal : l'utilisateur fait une séquence de bougies haussières et baissières, et le programme recherche ces séquences et effectue des transactions, alors pourquoi résumer les bougies en un seul motif ?
Pourquoi les résumer ? Eh bien, par exemple, pour simplifier le modèle. En fait, elle a été donnée en exemple.
Pourquoi n'est-ce pas possible ? Toutes les combinaisons de chandeliers japonais qui se produisent fréquemment peuvent être codées d'une manière ou d'une autre. Une autre chose est que le 1e bit (j'en ai parlé plus haut) n'est pas suffisant, vous devez utiliser au moins 2 bits, et ils ne sont pas non plus suffisants si vous ne résumez pas (simplifiez) le modèle du motif.
Jusqu'à présent, la version "1.003" du code Morse : vous pouvez spécifier manuellement une description de la chaîne de caractères du motif et même exécuter des passes uniques dans le testeur.
Le programme sera utilisé par un utilisateur, pas un programmeur (cela a été dit plus haut et pas une seule fois) - et pour lui "101" et "5" sont deux nombres différents, et pour lui "5" ne contient aucune information sur la position relative des bougies, mais "101" dit clairement "haussier, baissier, haussier".
Je ne comprends pas bien - s'agit-il de programmeurs ou de pigeons ?
Pourquoi avons-nous besoin de traduire quelque chose en quelque chose ?
Si nous avons besoin d'un code 101 - c'est la valeur normale de 5. C'est tout. Quel est le problème ? Traduire mentalement le décimal en binaire ?
J'ai fait des expériences similaires, sauf que ma bougie avait quatre tailles supplémentaires - de la petite à la grande. Cela fait huit tailles de bougies différentes. Et, par conséquent, trois bits. Dans le motif, nous écrivons le nombre (ulong) - la grille est plus grande que dans le motif à vingt barres.
Le problème est, à mon avis, tiré par les cheveux.
Faites d'abord le tri, puis critiquez. Voici une tâche à laquelle vous devez réfléchir :
Encodez le nombre int pour les combinaisons de chandeliers suivantes :
Indice : il s'agit de différentes combinaisons.
Je l'ai. Eh bien, alors - chaîne de caractères et analyseur syntaxique. Cela me semble être l'option la plus flexible.
Une fois de plus : l'optimiseur_ne_optimisera_pas_les_paramètres_chaînes. Comment allez-vous rechercher la combinaison de motifs rentables sans l'optimiseur ?
Si un optimiseur est nécessaire, je pense que l'utilisateur doit être suffisamment "avisé" pour traduire le nombre en code binaire (au moins avec une calculatrice Windows ordinaire).
Vous, mes amis, avez une demande contradictoire. Si un utilisateur est tellement idiot qu'il ne peut pas utiliser une calculatrice pour traduire un code binaire en code décimal, il ne peut de toute façon pas gérer l'optimisation. Il peut tout au plus l'exécuter une fois pour trouver la meilleure valeur.
Si l'utilisateur est suffisamment avancé pour utiliser l'optimiseur, il est raisonnable de coder les paramètres d'entrée avec un long non signé ordinaire,
Comprenez d'abord et critiquez ensuite. Voici une tâche qui suscite la réflexion pour vous :
Encodez le nombre int avec les combinaisons de bougies suivantes :
Indice : il s'agit de différentes combinaisons.
De plus - ils sont de longueur différente. La première combinaison - comprend quatre combinaisons à six chiffres.
La deuxième combinaison comprend deux uns de six bits.
Par conséquent, nous ne devrions prendre que 64 combinaisons de six bits pendant l'optimisation.
De plus, la dernière option est un sous-ensemble des deux premières, et l'avant-dernière est un sous-ensemble de la première.
Ainsi, au moment de l'enregistrement de la dernière combinaison, nous devons identifier la deuxième et la première combinaison en même temps. À mon avis, il s'agit clairement d'une demande incorrecte.
Par conséquent, lors de l'optimisation, il suffit de prendre 64 combinaisons à six chiffres.
Question : quelle est la probabilité d'apparition sur le marché d'une combinaison correspondant aux 64 chiffres requis ? Réponse : (1/2^64)*BarsCount. Cela signifie qu'il y a presque 100% de probabilité qu'une telle combinaison ne soit pas trouvée. Il est évident qu'un seul nombre int ou long ne peut pas décrire complètement le motif, nous avons donc besoin d'un paramètre supplémentaire spécifiant la longueur du motif.
Par ces petits pas, vous arriverez bientôt à ce que j'ai dit à la deuxième page.