Qui veut une stratégie ? Lots et gratuitement) - page 63

Nouveau commentaire
 

Oui, le courrier est correct.

Je vous ai envoyé un message privé il y a une minute.

 

Oh, j'avais oublié la ligne privée :))))))

C'est déjà bien entassé là :). Les gars - désolé si je n'ai pas répondu à temps, j'ai juste l'habitude de désactiver les messages personnels sur les forums et je n'ai même pas prêté attention ici par habitude :)....


Miroslav - alors maintenant je vais préparer un message (réponse) et l'envoyer par courrier ...

 

**Rappellez-vous, le problème de l'ouverture et de la fermeture de la barre - Point de la position n'est pas limité, les valeurs des indicateurs communs peuvent y être utilisées. Ainsi, une position peut être ouverte "au milieu" d'une barre (facile !). (pour ainsi dire, sur le calcul des valeurs de l'indicateur UNIQUEMENT à l'intersection des barres.... comme je l'ai dit - cette condition n'est "pas toujours" réalisable ;))**.


Si je comprends bien, vous pensez que nous devons recalculer un indicateur à chaque tick si le point d'entrée est au milieu de la barre (disons à une MA). Je vais me permettre de ne pas être d'accord avec toi.


Pour un back test fiable (en utilisant MT, FSB ou un autre testeur), tous les indicateurs, y compris les points d'entrée/sortie, doivent être fixés. Cela n'empêche pas un EA d'utiliser l'entrée sur le marché pendant la barre.

Exemples :


1. entrée à la moyenne mobile (21, clôture) :

Dans ce cas, nous ne pouvons pas utiliser la MA actuelle car elle se déplace vers le haut ou vers le bas jusqu'à ce que le prix de clôture de la barre soit fixé. Nous devons donc utiliser la MA de la barre précédente. De cette façon, il n'est pas nécessaire de le recalculer à chaque tic.


2 Entrée au niveau de la moyenne mobile (21, ouvert) :

Ici, nous pouvons utiliser la MA actuelle. Il est fixé parce que le prix de base de la MA - ouverture de la barre - est déjà fixé. Nous n'avons pas non plus besoin de le recalculer à chaque tic.


--------

Edit :

Il s'agit bien sûr de mon opinion personnelle.

Je n'ai pas l'intention de vous forcer à faire du backtesting de cette manière.

Salutations !


Edit2 :

Au cas où je manquerais quelque chose, montrez-moi un exemple de stratégie préparée avec FSB où vous devez recalculer un indicateur à chaque tick.

 

Mmm, Miroslav, j'ai compris l'idée (il y a longtemps, d'ailleurs) !

J'étais juste confus par les constructions dans le code de l'indicateur, que j'ai donné ci-dessus :

                    case "The position opens above the MA value":
                        component[0]. PosPriceDependence = PositionPriceDependence. BuyHigherSellLower;
                        component[0]. UsePreviousBar     = iPrvs;
                        component[1]. DataType           = IndComponentType. Other;
                        component[1]. ShowInDynInfo      = false;
                        component[2]. DataType           = IndComponentType. Other;
                        component[2]. ShowInDynInfo      = false;
                        break;

à savoir : composant[0].PosPriceDependence = PositionPriceDependence.AcheterHautVendreBas;

Ce n'est pas le cas, n'est-ce pas ? Il est important de comprendre que je ne parle pas du calcul de l'indicateur, en tant que tel. Dont la valeur, oui, est stationnaire dans une barre. Mais qu'en est-il du fait que dans ce cas (que j'ai cité plus haut) nous devons comparer la dernière valeur du prix avec celle-ci ? Afin de prendre la décision d'ouvrir un poste. Chez FSB, cela se fait par des procédures internes (si je comprends bien). Mais parce qu'ils "ne nous sont pas connus" (et, en fait, pourquoi ?) - j'ai suggéré de recalculer l'indicateur à chaque tick, dans ces cas-là, pour recevoir un OUI/NON sans ambiguïté sur la condition logique. En d'autres termes, laissez l'indicateur lui-même tirer cette conclusion, et non le code qui lui est extérieur. Je le pensais !

Je veux dire, hum, encore une fois - je suis d'accord avec la thèse selon laquelle l'indicateur devrait être calculé une fois sur les barres "croisées". Mais dans les cas où l'indicateur donne des signaux sur l'ouverture de positions, en application du travail de futurs EA(s) dans MT - nous devrions nous fier uniquement à ces valeurs (OUI/NON), et non à la comparaison des prix actuels avec les prix de l'indicateur (qui sont statiques). Laissons l'indicateur lui-même faire cette comparaison pour nous. Et nous ne tiendrons compte que de son OUI/NON. C'est ça... :)


Ou est-ce que je rate quelque chose quelque part ? :D ? ("got a little bit of a mammy...")

 

D'où la conclusion que je dois revoir ces calculs (je viens juste d'y penser) pour comparer correctement Close[iBar] avec la valeur de l'indicateur actuel ou précédent (qui est statique) (les iPrvs devraient être pris en compte). Mais dans l'idée, je pense que je n'ai pas tort... ? !



(de quoi discutons nous encore :)) ? ! Les indicateurs tiendront toujours compte du travail avec IndicatorCounted() N'IMPORTE OÙ ! !! Je ne veux pas le faire autrement :). Ils peuvent être utilisés non seulement par les rédacteurs d'EA, mais aussi par les utilisateurs qui auront besoin d'une partie visuelle (et de valeurs en temps réel). Le code original ne change pas du tout ! En général, il suffit d'ajouter un bit au début, qui initialise les valeurs "originales" des variables autoréférencées. Pas plus que ça... On parle parfois de "petit sang". Parfois pas tant que ça (comme dans l'exemple Hourly High Low). Mais en tout cas, un effort corporel minimal (encore ?) :))


Ou s'agit-il d'un aspect global ? Alors il n'y a pas à discuter - iPrvs est génial !:) Point final ! Mais personne ne le conteste :) !


(J'ai envoyé un courriel... je vais essayer d'y répondre ici en personne)

  
cas "La position s'ouvre au-dessus de la valeur MA" :
 composant[0].PosPriceDependence = PositionPriceDependence.BuyHigherSellLower ;


 Cette logique ne peut pas être gérée à partir de l'indicateur lui-même puisque les signaux dépendent de l'indicateur de point d'entrée.

 Cette logique ne donne pas de signaux d'achat ou de vente (1 , 0) comme les autres. 

 FSB procède comme suit :

 1. il ignore initialement cet indicateur lorsqu'il prend sa décision de trading ;
 2) Si toutes les autres règles logiques sont satisfaites et que le FSB connaît le point d'entrée, il vérifie cet indicateur pour autoriser ou interdire l'entrée juste avant l'exécution effective.

 Ceci est inclus dans le backtester.

 Il y a trois possibilités d'application dans une EE :

 1. calculer d'abord les points d'entrée (dans un tableau). Ensuite, il faut envoyer ce tableau à l'indicateur pour calculer les signaux d'achat et de vente.

 2. avoir une méthode de base EntryPrice(int iBar) qui renvoie le prix d'ouverture de la position. 
 La position s'ouvre au-dessus de la valeur MA :
 for(int iBar ... )
{
 SignalLong[iBar] = EntryPrice(iBar) > MA[iBar] ? 1 : 0 ;
 SignalShort[iBar] = EntryPrice(iBar) < MA[iBar] ? 1 : 0 ;
}

 3. Appeler cet indicateur avant la saisie effective :
 double EntryPrice = .... ;
 Si(EntryPrice > fsb_MA(...))
 OrderSend(...) ;


----

 Il existe plusieurs indicateurs qui n'établissent pas de signaux 1:0 :
- Tous les indicateurs avec la logique "Ouverture de la position au-dessus / au-dessous de ...".
- Indicateurs "Heure" : Heure de saisie, Heure de saisie, Jour de la semaine ;
- Compte Pourcentage d'arrêt
- ATR Stop
- Limite d'arrêt
- Stop Loss
- Prendre des bénéfices
- Stop suiveur
- Limite du Trailing Stop
- Limiteur de lot

 Ces "Indicateurs" donnent l'autorisation d'entrée/sortie au moment de la négociation ;










 

Miroslav - j'ai compris ! Pas dans le sens de comprendre enfin quelque chose :) (l'idée de manipuler le FSB avec une logique d'indicateur,

Je l'ai compris il y a longtemps (je ne tiens pas compte de la limite d'arrêt et d'autres choses, je ne les ai pas encore regardées).

Je me souviens enfin de quelque chose, disons que :)


Nous parlons simplement dans le même contexte d'applications différentes (c'est-à-dire à la fois les applications elles-mêmes (FSB et MT) et "en application de").

Le point essentiel est le calcul des indicateurs du FSB une fois, avant la procédure de back-testing proprement dite.

FSB ne peut tout simplement pas calculer sans ambiguïté 1/0 pour de telles conditions ("La position s'ouvre au-dessus / au-dessous de ...") avant le test lui-même !

Par conséquent, il utilise exactement la bonne logique :

1. il ignore initialement cet indicateur lorsqu'il prend la décision de négocier ;
 2. Si toutes les autres règles logiques sont satisfaites et que le FSB connaît le point d'entrée, il vérifie cet indicateur pour autoriser ou interdire l'entrée juste avant l'exécution effective.
Mais pour notre cas (en temps réel), CE N'EST PAS OBLIGATOIRE. Ou plutôt - en calculant des indicateurs "en permanence et à la volée" - nous aurons à chaque instant
à un moment donné, nous aurons une réponse définitive 1/0 pour cette condition logique.
Nous ne pourrons toujours pas ouvrir une position au dernier prix disponible (Close[0]). Alors, pourquoi ne pas y comparer l'indicateur ?
Et pourquoi ne pas sortir un 1/0 logique comme dans d'autres cas (désolé, le formatage est "off", je ne veux pas regarder dans le HTML (ça ne sert à rien de "flipper") :
 cas MA_POS_OPENS_ABOVE:
for (iBar = iFirstBar; iBar >= 0; iBar--) {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar];
}
break;

// Ce qui est apparemment plus correct à réécrire en tenant compte des iPrvs (je viens de me rendre compte aujourd'hui comment contourner ce problème en général)

case MA_POS_OPENS_ABOVE:
Pour (iBar = iFirstBar; iBar >= 0; iBar--) {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar + iPrvs];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar + iPrvs];
}
break;

// Considérant que les valeurs de toutes les barres sauf [0] (temps réel) seront "pas tout à fait correctes" (ou plutôt, fixées pour Close[iBar]), nous pouvons modifier le code comme suit

cas MA_POS_OPENS_ABOVE:
for (iBar = iFirstBar + 1; iBar >= 0; iBar--) {
if (iBar > 0) {
 LPIndBuffer[iBar] = 0.0;
 SPIndBuffer[iBar] = 0.0;
} else {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar + iPrvs];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar + iPrvs];
}
}
break;

// T.C'est-à-dire que pour toutes les barres, sauf [0], l'indicateur montrera que cette condition n'est pas remplie (n'a pas été remplie) - une question d'esthétique, pour ainsi dire... rien de plus.

 

(off : j'essaie d'insérer le code à nouveau, comme un commentaire séparé - "la fleur de pierre ne sort pas" :), puis un commentaire vide, puis ça va juste à la première page... Il y a peut-être des éléments dans le texte - "pas digeste"... en général - donc lire (comme ci-dessus) :))

 

Messieurs, Miroslav a mis à jour FSB à la version 2.8.3.6 Beta hier :

http://forexsb.com/forum/post/2446/#p2446


La logique du signal a été unifiée. Les changements ont touché la grande majorité des indicateurs. Le code du calcul des indicateurs n'a pas été modifié !

Les signaux logiques sont devenus un peu moins sensibles au "bruit". Dans le fichier de configuration, deux paramètres ont été ajoutés :

  <SIGMA_MODE_MAIN_CHART> 1</SIGMA_MODE_MAIN_CHART>
  <SIGMA_MODE_SEPARATED_CHART> 5</SIGMA_MODE_SEPARATED_CHART>

Les paramètres définissent le "seuil" de déclenchement des signaux à partir du niveau de changement de prix (pour les indicateurs sur la fenêtre avec le graphique et pour les indicateurs avec leurs propres fenêtres).

La correspondance des valeurs de MODE est donnée ici :

http://forexsb.com/library/source/Sigma.html


Nous pensons que les valeurs "par défaut" sont EXACTEMENT adéquates (dans la plupart des cas). Mais... n'hésitez pas à faire des expériences :).


J'ai volontairement attendu cette sortie, pour ne pas faire double emploi. Je mets aussi mes propres œuvres. J'ai 20 indicateurs pour le moment (je ne considère pas 2 d'entre eux comme "utiles" (Bar Closing / Bar Opening) - ils seront utiles dans le futur ;)) :

-FSB- Accelerator Oscillator.ex4
-FSB- Accumulation Distribution.ex4
-FSB- ADX.ex4
-FSB- Bar Closing.ex4
-FSB- Bar Opening.ex4
-FSB- Bar Range.ex4
-FSB- Bollinger Bands.ex4
-FSB- Donchian Channel.ex4
-FSB- Envelopes.ex4
-FSB- Force Index.ex4
-FSB- Heiken Ashi.ex4
-FSB- Hourly High Low.ex4
-FSB- Ichimoku Kinko Hyo.ex4
-FSB- Keltner Channel.ex4
-FSB- Moving Average.ex4
-FSB- Price Oscillator.ex4
-FSB- RSI MA Oscillator.ex4
-FSB- RSI.ex4
-FSB- Starc Bands.ex4
-FSB- Steady Bands.ex4

Les algorithmes de calcul et la logique des signaux sont entièrement conformes à la norme FSB (enfin... devraient :D)...

Y COMPRIS LES VALEURS INDICATIVES ! !! (FSB (application) = -FSB- (conversion) = MT (interne) ) (jusqu'à n'importe quel signe).

L'exception est "-FSB- Accumulation Distribution.ex4" - Miroslav a un code délicat là, je n'ai pas encore eu le temps de le faire (il ne correspond pas exactement à MT, je n'ai pas vérifié avec FSB).


Je continue par ordre alphabétique (enfin presque). Si quelqu'un a besoin de quelque chose de plus prioritaire, écrivez... (la personne avec Hourly High Low a disparu quelque part, je n'ai pas compris - est-ce que ça a aidé ou pas :D ?!)


En même temps, nous commençons à développer l'EA, qui sera capable de fonctionner avec ces versions d'indicateurs. À la fin, il devrait y avoir une sorte de gerbe :

FSB -> Fichier de stratégie exporté -> EA, basé sur des indicateurs convertis et une logique de trading interne, compatible avec FSB...


Bonne chance ! Et bonnes vacances à tous ! !!

Je vais me montrer plus près du début de la semaine de travail... Restez à l'écoute...

Dossiers :
fsb2mql_20090430.rar  270 kb
 
Stellarator >> :

Messieurs, Miroslav a mis à jour FSB à la version 2.8.3.6 Beta hier :

http://forexsb.com/forum/post/2446/#p2446


Je télécharge quelque chose et l'archive est cassée... :
1...5657585960616263646566
Nouveau commentaire