[Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas votre chemin. Je ne peux aller nulle part sans toi. - page 794

Nouveau commentaire
 

obla4ko: а по поводу тестирования на истории вопрос :

Peut-on utiliser un conseiller expert (un simple !) ? - pas une grille) sur la même période de l'histoire, avec les mêmes paramètres donnent des résultats complètement différents ?

La seule chose que j'ai faite, entre ces deux tests, a été de mettre à jour les archives des citations... et qui aurait pu conduire à un tel résultat ? - puis il s'avère que toute l'histoire est une connerie ! ?

1. L'histoire peut changer. Les écarts intrajournaliers sont filtrés, les pics sont supprimés, etc. Parfois même, les jours disparaissent ! // Quelqu'un s'est plaint ici il n'y a pas longtemps qu'un mois avait été volé. Pas CA, mais un diable de "Soirées à la ferme près de Dikanka" ! )))

2. La différence peut également être due à l'écart flottant. Le testeur utilise celui qui est en cours au moment du démarrage.

3) L'histoire n'est pas une connerie. Ce qui est stupide, c'est que l'EA est si dépendante de petites choses comme ça.

 
obla4ko:

également, à mon avis, une "épingle à cheveux", nettoyée par la suite... :)), mais "gardée en mémoire" de plus petites échéances, qui ne sont plus atteignables...

Et la question des tests sur l'histoire :

peut un Conseiller Expert (un simple !) - ) sur la même période de l'histoire, avec les mêmes paramètres donnent des résultats complètement différents ?

La seule chose que j'ai faite, entre ces deux tests, a été de mettre à jour l'archive des citations... et qui aurait pu conduire à un tel résultat ? - puis il s'avère que toute l'histoire est une connerie ! ?

Exactement... vous venez d'écrire que vous avez essuyé les "clous" vous-même. De plus, lors des tests, l'écart est pris sur l'écart actuel. Et il peut être différent : dans le dernier test, il était de 2 points, et dans le test actuel, il est de 4, par exemple...
 
obla4ko:

Merci pour la clarification - mais pensez-vous qu'au lieu de comparer avec la valeur Time[0], je devrais essayer de donner cette tâche avant la requête OrderSend(...) : vérifier si la barre actuelle est fermée par StopLoss-y ? Ensuite, je dois introduire une double fonction StopLoss() qui fonctionnera avec la variable StopLoss que j'ai annoncée ? Ou bien ce n'est PAS POSSIBLE par principe ? Il est important pour moi qu'une nouvelle position ne soit pas ouverte sur la barre qui a enregistré une perte, même si elle correspond aux paramètres de l'ouverture.

Le fait est que les facteurs temporels doivent être examinés en dernier lieu - très souvent, ils glissent - ou plutôt l'interprétation d'une ordonnance s'avère différente (ambiguë).


Cette condition ne fonctionnera pas dans un marché rapide

if(Volume[0]>1) return;
Quelques tiques sont arrivées à la fois et il y en a déjà plus d'une.
 
Vinin:


Cette condition ne fonctionnera pas dans un marché rapide

Quelques tiques sont arrivées à la fois et c'est déjà plus d'une

.
Exactement ! Ça ne marche pas ! Ça glisse :)) Et beaucoup de postes positifs ne s'ouvrent pas ! Que suggérez-vous à la place, la native ?
 
artmedia70:
Exactement... vous venez d'écrire que vous avez essuyé les "clous" vous-même. De plus, lors des tests, l'écart est pris sur l'écart actuel. Et il peut être différent : dans le dernier test, il était de 2 points, et dans le test actuel, il est de 4, par exemple...
Exactement, on dirait que nous devons écrire des programmes aussi épais qu'un bâton - pour qu'ils aient une réserve de 6000 pips... :)))) - seulement alors le bénéfice est de 30 livres par 10k pendant six mois... :((((((((((
 
obla4ko:
C'est ça ! Ça ne marche pas ! Ça glisse... :)) Et beaucoup de postes positifs ne s'ouvrent pas ! Et que suggérez-vous pour le remplacer, le natif ?

Pour cela, vous devez connaître les exigences. Vous pouvez utiliser la variante consistant à contrôler l'ouverture d'un nouveau bar par le temps - mais cela vous conviendra-t-il ? Les transactions peuvent être ouvertes à tout moment. Il peut être plus facile de contrôler le nombre de postes ouverts. Nous devons d'abord décider de ce qui est nécessaire
 
Svinozavr:

1. L'histoire peut changer. Les écarts intrajournaliers sont filtrés, les pics sont supprimés, etc. Parfois, il manque même des jours ! // Quelqu'un s'est plaint récemment qu'un mois avait été volé. Pas de la société de courtage, mais de "Soirées à la ferme près de Dikanka" ! )))

2. La différence peut également être due à l'écart flottant. Le testeur utilise celui qui est en vigueur au moment du lancement.

3) L'histoire n'est pas une connerie. Ce qui est absurde, c'est qu'un conseiller expert soit si dépendant de si petites choses.

On ne peut pas assimiler un conseiller à une matraque - c'est une chose délicate :))), virtuelle, je dirais ce que vous suggérez, qu'il ne remarque pas comment "les jours disparaissent" ! // L'autre jour, quelqu'un s'est plaint ici du vol d'un mois. " ??? ....n un tel conseiller ?
 

Veuillez me conseiller sur la manière de l'utiliser dans un indicateur :

int CountedBars=IndicatorCounted();
if(CountedBars< 0) CountedBars= 0;
if(CountedBars> 0) CountedBars--;
cnt = Bars - CountedBars;

for(int i = 0; i < cnt ;i++)

Si vous faites de l'automatisation sur cette base, il est clair que rien ne fonctionnera car IndicatorCounted() sera égal à 0. Comment pouvez-vous retravailler correctement le contenu d'un indicateur pour le faire fonctionner ?

 
Vinin:

Pour cela, vous devez connaître les exigences. La possibilité de contrôler l'ouverture d'un nouveau bar en fonction du temps est possible - mais sera-t-elle satisfaisante ? Peut-être que les échanges devraient être ouverts à tout moment. Il peut être plus facile de contrôler le nombre de postes ouverts. Nous devons d'abord décider de ce dont nous avons besoin.
Et si nous écrivons simplement Volume[0]>1 au lieu de Volume[0] >5, disons ? Comment pensez-vous qu'il réagirait ? Je suis juste un partisan, dans la mesure du possible, des solutions simples - ce sont les plus ingénieux ! :))
 

Chaque conseiller a des exigences différentes

1...787788789790791792793794795796797798799800801...1145
Nouveau commentaire
Raison: