Firebird v63G - page 15

 

Réglage

Bonjour Hendrick, bonjour Wackena.

Merci pour tous vos efforts pour améliorer notre nombre de pipcount. J'ai écouté vos discussions et j'ai aussi essayé quelque chose. Pas de réelle amélioration pour moi. Mais avez-vous essayé de contrôler le compte d'ordre ouvert par le facteur de type d'augmentation. J'utilise 0.5. J'ai fait le tableau selon le formulaire de l'auteur de firebird. Hendrik, je travaille aussi avec Neuimex. Peut-être pouvons-nous nous arranger avec des valeurs différentes pour le contrôle. Merci. karl Je n'ai pas réussi à ajouter la table, mais j'ai réussi maintenant. Mais il s'agit d'un fichier Excel. karl

Dossiers :
incrtype.txt  14 kb
 

Peut-être la raison !

Si je comprends bien le code de Firebird v63g, la première transaction originale sur un graphique est déclenchée par l'"indice de Vigueur Relative" par le Code,

doubleRVI=iRVI(NULL,0,10,MODE_MAIN,0)-iRVI(NULL,0,10,MODE_MAIN,1) ;

Dans la première transaction originale, la variable TimeFrame est 0, ce qui signifie qu'elle utilise la sélection de TimeFrame du graphique actuel.

Les transactions PipStep sont déclenchées par "l'indice de la moyenne mobile" par le code,

doublemyMA=iMA(NULL,MA_timeframe,MA_length,0,MODE_SMA,PRICE_OPEN,0) ;

Dans les transactions PipStep, MA_timeframe est utilisé et dans mes paramètres, j'utilise MA_timeframe=15.

C'est la raison pour laquelle j'obtiens des résultats différents pour différentes périodes graphiques, comme indiqué précédemment.

La conclusion est la suivante : "Le choix de la période graphique appropriée aura un effet sur l'activité commerciale".

J'espère que cela est compréhensible. Si je me trompe, veuillez me conseiller.

Wackena

Wackena:
La plupart des opinions que j'ai entendues disent que la période du graphique que vous sélectionnez n'a pas d'importance, parce que le cadre temporel est codé en dur dans l'EA. J'ai commencé 3 tests côte à côte pour comparer en utilisant les mêmes paramètres, mais différentes périodes graphiques. Il est à noter que j'ai utilisé 2 démos de test et un compte réel pour ce test. Voici les résultats du 14 juin (début à 1800 GMT) au 16 juin (fin à 2400 GMT).

M1 (en direct)

eur/usd - 10 trades (10 victoires, 0 perte)

gbp/usd - 19 transactions (18 victoires, 1 perte)

usd/chf - 15 transactions (14 victoires, 1 perte)

usd/jpy - 6 transactions (5 victoires, 1 perte)

M15 (Démo)

eur/usd - 14 transactions (14 victoires, 0 perte)

gbp/usd - 4 transactions (4 victoires, 0 perte)

usd/chf - 5 transactions (5 victoires, 0 perte)

usd/jpy - 5 transactions (5 victoires, 0 perte)

M30 (Démo)

eur/usd - 1 transaction (1 victoire, 0 perte)

gbp/usd - 10 transactions (10 victoires, 0 perte)

usd/chf - 3 trades (3 victoires, 0l oss)

usd/jpy - 2 transactions (2 victoires, 0 perte)

S'il n'y a soi-disant aucune différence entre les résultats Live et Demo, il semble y avoir une différence significative dans l'activité de trading. De plus, il semble que les périodes M15 et M30 soient moins souvent négociées et qu'elles gèrent "peut-être" mieux les pics de tendance. Je dis "peut-être", car il s'agit d'une période de test très courte. De plus, il y a quelques indications ici que différentes paires de devises peuvent être plus performantes sur différentes périodes graphiques.

Wackena
 
karl:
Bonjour Hendrick, bonjour Wackena, merci pour tous vos efforts pour améliorer notre pipcount. J'ai écouté vos discussions et j'ai aussi essayé quelque chose. Pas de réelle amélioration pour moi. Mais avez-vous essayé de contrôler le compte d'ordre ouvert par le facteur de type d'augmentation. J'utilise 0.5. J'ai fait le tableau selon le formulaire de l'auteur de firebird. Hendrik, je travaille aussi avec Neuimex. Peut-être pouvons-nous nous arranger avec des valeurs différentes pour le contrôle. Merci. karl Je n'ai pas réussi à ajouter la table, mais j'ai réussi maintenant. Mais il s'agit d'un fichier Excel. karl

Karl, vous avez peut-être déjà ce fichier joint. Il explique la stratégie de Firebird dans les versions antérieures et discute de l'augmentation de PipStep.

Wackena

Dossiers :
 
 
Wackena:
Oui, si j'ai calculé les pips correctement, les voici.

M1

940 pips gagnés

-360 pips de perte

580 pips net

M15

560 pips gagnants

-0 pips perte

560 pips net

M30

320 pips gagnants

-0 pips perdu

320 pips net

Wackena

Bonjour Wackena,

Vous exécutez donc les mêmes paramètres que ceux mentionnés ci-dessus sur différentes périodes de temps... n'est-ce pas ?

Merci

Babar

 
babarmughal:
Salut Wackena,

Vous exécutez donc les mêmes paramètres susmentionnés sur différentes périodes de temps... n'est-ce pas ?

Merci

Babar

Babar,

Oui. M1, M15 ET M30.

Wackena

 

Je ne sais pas si c'est pertinent, mais au cours de la semaine dernière, j'ai utilisé Firebird sur 4 majeurs sur un compte de démonstration et j'ai laissé l'intervalle de temps du graphique sur M1 par hasard. Je n'avais pas changé les paramètres et voilà le résultat.

Encore une fois, je ne sais pas si cela a quelque chose à voir, mais tous les trades ont gagné.

Comment cela est-il possible ? J'ai joint les rapports à ce message et mes paramètres.

roger

 

test avant du 15 juin au 16 juin

Je fais le test de l'avant avec cet oiseau de feu en suivant ce paramètre (initialement défini par wackena) :

Sur le graphique M1

Paramètres

MA_longueur=10

MA_timeframe=15

MAtype=0

Pourcentage=0.05000000

TradeOnFriday=1

glissement=100

Lots=0.1000000

TakeProfit=23

Stoploss=120

Fast_Period=23

Prix rapide = 1

Période lente = 84

Prix lent = 1

DivergenceLimit=0.00200000

Use_V63D_Divergence=0

PipStep=40

IncreasementType=0.00000000

DVLimit=10

PipsGoal=500

PipsLoss=500

GMT=0

DST=0

Heure d'ouverture=0

Heure de clôture = 24

writelog=0

Pas si bien sur la paire gbpjpy...je ferme cette position gbpjpy manuellement.

Maintenant j'exécute ce firebird seulement dans 4 majors (eurusd.gbpusd.usdchf,usdjpy) Je montrerai les détails du relevé pour le trading de cette semaine la semaine prochaine (lundi).

Merci

Dossiers :
 

Les contributeurs à ce fil de discussion ont fait un excellent travail avec cette ea...... Les résultats sont assez impressionnants.

 
Hendrick:
Certains d'entre vous utilisent un TP=20 et un SL=120. Donc, pour chaque perdant, vous devez avoir 6 gagnants pour atteindre l'équilibre. Je ne sais pas si cela fonctionnera en fin de compte. Après un TP=18 et un SL=42, j'utilise maintenant un TP=26 et un SL=52 (2 gagnants pour 1 perdant pour être à l'équilibre). Cela semble très prometteur ! De plus, je pense que MAtype=0 est indispensable. Avec MAtype=1, j'ai vu Firebird placer des trades pendant un pic. Un autre pic dans la même direction et votre compte est à zéro (cela m'est arrivé deux fois). J'ai étudié tous les trades effectués par Firebird et j'ai remarqué que vous feriez mieux de ne pas faire de trades entre 12:00-13:00, 15:00-16:00 et 23:00-8:00. Un grand nombre de transactions rentables (et aucune perdante) ont été effectuées entre 16h00 et 18h00 (je suis à GMT+2). Pour utiliser un tel horaire, je me suis fabriqué un outil : EDEA. Voir la pièce jointe pour les fichiers. Je viens de créer un nouveau compte de démonstration avec les nouveaux paramètres et le nouveau calendrier. Voyons voir !

Salut Hendrick,

Quels sont les autres paramètres de Firebird que vous utilisez ?

Merci

Babar

Raison: