Démonstration de l'approche par grappes du marché... - page 4

 
ssd >> :

Condition pour une position ouverte vers le haut :

si (Ind_0 > 0 && Ind_1 < 0)

Condition pour fermer une position ouverte vers le haut :

si (Ind_0 <= 0)

Condition pour ouvrir une position à la baisse :

si (Ind_0 < 0 && Ind_1 > 0)

Condition de fermeture d'une position ouverte à la baisse :

si (Ind_0 >= 0)

Les termes sont controversés et ne sont pas basés sur des statistiques : il ne suffit pas d'avoir un signe positif pour l'indice de la première devise et un signe négatif pour la deuxième devise pour ouvrir un long. Il y aura trop de fausses entrées.

En outre, il n'est pas clair pourquoi, pour fermer une position ouverte, il suffit de considérer le signe de l'indice d'une seule devise.

Et sab1uk souligne également à juste titre que les croisements synthétiques sur les petites TF seront sérieusement différents des réels.

P.S. Je n'ai pas encore regardé le code, mais j'essaie de faire quelque chose de similaire moi-même. Il semble que l'approche de Semenych soit fondamentalement différente, puisqu'il suggère d'ouvrir sur le rebond et non sur le breakout comme ici ?

 

Je pense que le signal le plus fort sera lorsqu'un indice atteindra son maximum (valeur absolue) et tournera dans la direction opposée, et alors le deuxième indice doit aussi tourner... c'est le signal le plus fort, qui devrait montrer l'inversion de la direction principale du mouvement dans le cadre temporel actuel... S'il n'y a pas un tel signal, alors vous pouvez compter sur un signal moins important - l'intersection du graphique de l'indice, et avant le croisement, les graphiques devraient avoir une dynamique de changement prononcée, et non pas qu'ils rampent "côte à côte dans le flux


Si vous voulez utiliser un autre signal de la même manière que ci-dessus, vous devez créer un autre signal.

 
Mathemat >> :

Les conditions sont controversées et ne sont pas basées sur des statistiques : il ne suffit pas d'avoir un signe positif pour l'indice de la première devise et un signe négatif pour la deuxième devise pour ouvrir un long. Il y aura trop de fausses entrées.

De même, on ne comprend pas pourquoi il suffit de prendre en compte un seul signe de l'indice des devises pour clôturer une position ouverte.

Et sab1uk souligne également à juste titre que les croisements synthétiques sur les petites TF seront très différents des croisements réels.

P.S. Je n'ai pas encore regardé le code, mais j'essaie de faire quelque chose de similaire moi-même. Il semble que l'approche de Semenych soit fondamentalement différente, car il suggère d'ouvrir au rebond et non au breakout comme ici ?

CL1i - cet indicateur montre la différence entre les "prix du cluster" de la devise de base et la cotation de l'instrument sur lequel il fonctionne.

Ainsi,

Ind_0 est la différence entre les "prix groupés" de la devise de base et de la devise de cotation de l'instrument à la barre 0 - barre actuelle.

Ind_1 est la différence entre les "prix groupés" de la devise de base et de la devise de cotation de l'instrument sur la barre 1 - la première barre passée.


Il s'avère donc que nous nous ouvrons, par exemple, au tout premier moment où le "prix de la grappe" de la monnaie de base commence à dépasser le "prix de la grappe" de la monnaie cotée.


Je vous assure que Semen Semenych a le même système d'ouverture/fermeture des postes.

 
sab1uk >> :

sur les échelles de temps minute, les paires synthétiques auront des divergences avec les paires naturelles.

J'ai essayé tous les instruments "naturels" disponibles (avec seulement les croisements manquants de GBPNZD),

Cependant, la charge sur l'ordinateur était telle qu'il était presque impossible de travailler.

 

Получается тогда, мы открываемся, к примеру, вверх, в самый первый момент, когда "кластерная цена" базовой валюты начинает превышать "кластерную цену" котировочной валюты.

Ah, voilà. Merci, ssd.

Cependant, la charge sur l'ordinateur était telle qu'il était presque impossible de travailler.

Bien sûr, c'est faisable. L'astuce réside dans la quantité d'historique téléchargée. Vous n'en avez pas besoin. Et les calculs y sont très simples, même un single-core peut les gérer. Bien sûr, si vous ne calculez pas à chaque tic.

Mais mon critère d'entrée n'est pas aussi obscur. Si vous êtes intéressé, envoyez-moi un message et nous en discuterons.

 
ssd писал(а) >>

J'ai essayé tous les outils "naturels" disponibles (avec modélisation par croisement du seul outil manquant GBPNZD),

Cependant, la charge sur l'ordinateur était telle qu'il était presque impossible de travailler.

L'utilisation de tampons cycliques pour les calculs réduit la charge

 
Mathemat >> :

Ah, voilà. Merci, ssd.

Pourquoi, il est possible de travailler. L'astuce réside dans le volume de l'historique téléchargé. Vous n'en avez pas besoin. De quoi avez-vous besoin en minutes pour quelques années avec ce système ?

C'est vrai, une longue histoire avec cette approche est plutôt inutile.

Cependant, la fréquence de l'"erreur" - ERR_HISTORY_WILL_UPDATED 4066 était telle qu'il y avait une incertitude dans les lectures de l'indicateur.

En d'autres termes, la charge de l'ordinateur était en fait faible, le temps d'attente des outils de pagination ralentissait tout le travail.

Garder les 28 outils ouverts est très peu pratique.

 

Voici un fil de discussion où les développeurs ont donné des conseils sur la façon de gérer ce problème. Et vous n'avez pas besoin de garder tous les outils ouverts. Il suffit de les avoir dans Market Watch.

Une fois encore, il n'est pas nécessaire de tout compter à chaque tic. Il est redondant pour ce système. Il suffit d'aborder les calculs, disons une fois par minute. Mais en outre, il est souhaitable d'accéder simplement à chaque symbole - par exemple, simplement par iClose().

 
Mathemat >> :

Voici un fil de discussion où les développeurs ont donné des conseils sur la façon de gérer ce problème.

>> Oui, c'est ça ! >> Merci, je vais y jeter un coup d'œil.

 
ssd >> :

J'ai essayé tous les outils "naturels" disponibles (avec modélisation par croisement uniquement de l'outil GBPNZD manquant),

Cependant, la charge sur l'ordinateur était telle qu'il était presque impossible de travailler.

J'ai eu le même problème. Il a fallu trois ans pour l'optimiser.

Maintenant, il compte en 5 secondes ce qui prenait 5 minutes auparavant.

Raison: