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

Nouveau commentaire
 
Stellarator >> :

y a-t-il déjà eu des divergences entre les valeurs d'origine et les valeurs "déployées ultérieurement" ? toujours double...)

pas encore.... tous les problèmes viennent du laisser-aller :)

Obligé de dissuader ! La nuance clé - "la limite d'une itération de l'EA". Eh bien, dans ces limites, l'indicateur est calculé UNE fois (à son premier appel) ! Je le déclare avec une confiance absolue. Tous les appels ultérieurs ne le lancent pas du tout, mais prennent seulement les valeurs nécessaires dans les tampons nécessaires. La condition est de 100% si les paramètres d'entrée restent inchangés (sauf pour le tampon et le décalage). La règle est valable pour les calculs dans les limites d'un seul outil. Mais je pense que le principe est valable même lorsque iCustom fait référence à d'autres TF et outils.

Il faudrait que l'un d'eux soit "forcé" ..... tout à la fois. Merci pour une autre fonctionnalité non documentée :)


 

FSB__Bar_Opening_Bar_Closing.mql4 v0 .0.2 Beta


Entrée du marché à l'ouverture du bar ;

Sortie à la clôture de la barre (10 sec. jusqu'à la clôture ou à la prochaine ouverture)


** Il s'agit uniquement d'une démo pour tester les points d' entrée et de sortie. **


Fragments de code :


bool bIsFirstTick;// It is used to catch the Bar Opening.
datetime dtCurrentBarOpeningTime;

int init()
{
   bIsFirstTick = false;
   dtCurrentBarOpeningTime = Time[0];
   return(0);
}

int start()
{
   // Is this the first tick for the bar
   bIsFirstTick = ( dtCurrentBarOpeningTime != Time[0]);
   if( bIsFirstTick)
   {
      dtCurrentBarOpeningTime = Time[0];
   }

...
...



///
/// Exit at a Bar Closing price (almost).
///
/// MetaTrader does not provide an onBarClose event so we are not able to close a position
/// exactly at Bar Closing. We workaround the problem by closing the position within a time span
/// near to the bar closing time. In the cases when there is no any ticks within this period,
/// we close the position att he next bar opening price.
///
int ClosePositionsAtBarClosing(bool bCloseLong, bool bCloseShort, datetime dtClosingTimeSpan)
{
   int  iOrders = OrdersTotal();
   bool bIsOpen = false;

   for(int iOrder = 0; iOrder < iOrders; iOrder++)
   {
      OrderSelect( iOrder, SELECT_BY_POS, MODE_TRADES);
      
      if((OrderType() == OP_BUY || OrderType() == OP_SELL) && OrderSymbol() == Symbol())
      {  // There is an open position for this symbol.

         datetime dtOpeningTime     = Time[0] - TimeSeconds(Time[0]); // The opening time of current bar
         datetime dtClosingTime     = dtOpeningTime + Period() * 60;  // The closing time of current bars
         datetime dtCurrentTickTime = TimeCurrent() ;                 // The time of current tick
         
         if( dtCurrentTickTime > dtClosingTime - dtClosingTimeSpan ||  bIsFirstTick)
         {  // The current tick is within the closing time span or this is the first tick of the bar.

            // Code

         }
       }
    }
}
 

1. concernant la performance :

En général, nous n'avons pas besoin de recalculer un indicateur pour chaque tick. (Référence - "Utiliser la valeur de la barre précédente".) Un indicateur doit être calculé soit à "l'ouverture de la barre", soit à "la fermeture de la barre".


2. fMicron :

J'utilise fMicron = Point/2 lorsque je compare des prix pour des décisions de trading. Mais ceci n'est pas applicable pour les indicateurs. Eg. pour USDJPY point = 0.01 ; fMicron = 0.005.

0,000075 est le résultat de nombreux tests effectués au fil des ans. J'ai commencé à travailler sur le FSB en 2001 :) Bien sûr, ça ne veut rien dire. J'ai changé d'avis à plusieurs reprises à ce sujet.

**edit : MT remet cela entre les mains des utilisateurs. Les gourous de l'EA peuvent probablement dire ce qu'ils utilisent dans leurs EA.

**edit2 : Je vais mettre ce paramètre dans le fichier de configuration pour les expériences.


3. je vais commencer à fournir le code source original à télécharger pour chaque version de FSB. Dans ce cas, je n'aurai pas besoin de mettre à jour le site web pour chaque petit changement.


J'ai commencé à changer le flottant en double. Je publierai cette version bientôt, ce soir ou demain. Après cela, nous devons le tester minutieusement. Nous devons passer par chaque indicateur pour corriger certains problèmes / fonctionnalités avant de les écrire dans MQL.

 

1. Oui, dans la plupart des cas (compte tenu de l'approche générale du FSB en matière d'ouverture/fermeture de positions (à l'ouverture/à la fermeture du bar)). - Ce n'est pas nécessaire. Mais, disons que - les règles de bonnes manières - sont obligatoires. Calcul de l'indicateur "à partir de zéro" à chaque fois (même une fois à la barre) - en général (je suis d'accord) pas critique dans les limites de grandes périodes... Mais que faire si la période est de quelques minutes ? Et si l'indicateur a encore besoin (ou veut) être calculé à chaque barre (un point sophistiqué de la position, qui ne peut pas (ou plus, parce que le prix d'ouverture est inférieur au niveau des stops) être attrapé par un ordre) ?

La conversion n'est pas très compliquée, en fait - oui, il y a un peu de code "dans l'enveloppe" et le principe de la marche des barres est inversé. En fait, c'est tout, dans l'ensemble. L'essentiel est de conserver l'algorithme (afin qu'il puisse être facilement lu et identifié dans le code source) et de conserver la compatibilité paramétrique avec FSB. Créer un mécanisme pratique pour l'extraction du signal. Et pour le rendre utilisable par les concepteurs visuels purs (qui ne se soucient pas d'EA). A mon avis.


2. Je n'ai pas suggéré d'utiliser la variante Point/2 pour comparer des valeurs indicatrices (égales) :). - Je suggérais juste une constante. La question est dans sa valeur et sa dimension (0.000075 - pas mal, je n'ai pas dit ça - je ne comprends pas pourquoi exactement 75 et pas "habituellement" 50 :) ? L'expérience "depuis 2001" est assez révélatrice (argument !) et je suis tout à fait disposé à accepter cette valeur. Mais comme dernière remarque - pour les citations avec une dimension de 0.12345 cela ne sera pas suffisant (je veux dire - beaucoup :))). Le nombre doit être décalé d'au moins une image vers la droite (0,0000075). Dans ma société de courtage, par exemple, de tels devis sont déjà une pratique courante... Je vous suggère de l'adapter à l'instrument et d'utiliser "10" et non "75" :) :

fMicron = Point * 0.1f

En bref, oui - je propose de le faire paramétrer (je pense qu'après quelques expérimentations amicales tout se mettra en place (quoique... si le point a changé plusieurs fois ;)...). Et attendre l'avis d'autres personnes...


3. J'ai réussi à télécharger les sources postées :-P. Il y aura donc "quelque chose à comparer" (en termes de code résultant). Et même si je ne veux pas vous déranger davantage, bonne chance pour la conversion de float en double !


(comment s'est passé le test avec RSI ? ;), si vous avez réussi à le faire ?)

 

J'ai découvert que le meilleur est 100 > Micron > 50. C'est pourquoi j'ai pris 75. C'était pour mon courtier : Point = 0.0001.

Mais vous avez raison de dire que les courtiers ont commencé à coter à 0,00001.

Faisons-le : Micron = Math.Min(Point * 0.75, 0.000075)

J'espère avoir terminé la conversion dans 3 heures. Je vais mettre ici le programme pour le tester.

Je vais aussi télécharger les codes sources des indicateurs convertis.

 

Tous les indicateurs et paramètres sont des nombres doubles .

Micron = 0,000075


Mettez l'exe dans le dossier avec le dernier FSB v2.8.3.3 Beta. Les deux programmes partageront les mêmes données et stratégies. C'est pratique pour comparer. Faites attention aux valeurs des indicateurs. Pratiquement tous les indicateurs et la moitié des autres fichiers ont été modifiés.

Pour voir la précision totale, appuyez sur F12 dans le graphique ou utilisez la console de commande (ind ####).


Veuillez signaler tout problème. C'est le moment de demander des changements sur les indicateurs. Nous devons les corriger avant de poursuivre le travail d'intégration de MT.



 

Bonjour !

Miroslav, le temps est très limité maintenant... donc c'est rapide :

1. Merci pour la traduction rapide (float to double) ! Super!

2. Jusqu'à présent, tout semble fonctionner (pour autant que j'aie pu le vérifier), je peux voir les différences (à la volée), tant dans les valeurs des indicateurs que dans les résultats des stratégies :)

3) MAIS - les différences ne sont pas celles auxquelles nous nous attendions ! (J'ai fait une expérience interne hier soir, et mes "craintes" ont été confirmées - la conversion augmentera la précision des calculs - MAIS ne changera pas le résultat de façon catastrophique ! Quelque chose du domaine des différences dans le quatrième-cinquième chiffre... mais nous avons des divergences dès le deuxième chiffre ! (le même RSI, par exemple))


LA RAISON EST AUTRE ! !!


Ce que j'ai réussi à vérifier :

1. Je me suis d'abord demandé s'il existait des liens solides sur le thème des chiffres (j'ai des instruments à 5 chiffres, remarquez)... J'ai été forcé de spécifier 4 chiffres dans les propriétés de l'outil - cela n'a pas aidé (d'ailleurs - mais cela fonctionne !)

2. Le code des indicateurs eux-mêmes ... hmm... ... et bien, il n'y a pas de quoi se plaindre ! C'est double partout maintenant, le code lui-même (comme je le vois) n'a pas changé... Le code est assez simple (il ne fonctionne très souvent que par addition et soustraction) - une telle erreur ne peut PAS s'être accumulée là! !! (Je n'en suis pas si sûr ... mais ... ;))

3. Ma dernière pensée (que je ne pourrai pas vérifier) - THIS IS WHAT :) !:



Valeurs de fermeture/ouverture du bar ( ???) (et autres, éventuellement ?)


D'où viennent ces chiffres ??? :))) (quel genre d'"additifs" sont-ils :D ?)

Je l'ai pris quelque part ici (Bar Closing.cs) :

            // Saving the components
            component = new IndicatorComp[1];

            component[0] = new IndicatorComp();
            component[0]. CompName  = "Closing price of the bar";
            component[0]. DataType  = ( parameters. SlotType == SlotTypes.Open) ? IndComponentType. OpenPrice : IndComponentType. ClosePrice;
            component[0]. ChartType = IndChartType. NoChart;
            component[0]. FirstBar  = 2;
            component[0].Value     = Data.Close;

Par conséquent, ma première hypothèse de travail est que (peut-être) il s'agit de cela ? (" mal " (ou " bien ", mais pourquoi exactement comme ça ?) en donnant des valeurs de citation dans la fonction).

En partie, apparemment, à la question des valeurs obtenues (pour remplir les tampons opérés lors du calcul de l'indicateur) à partir de la fonction recherchée protected static float[] Price(BasePrice price)


En général, Miroslav - "la balle est dans ton camp" :). Pour l'instant j'ai remarqué le nouveau code de VOS indicateurs, qui est parfaitement compatible avec les indicateurs MT (je suis persistant :D, je finirai le sujet RSI) :



Même barre, premier indicateur - conversion, deuxième - natif de MT.


Des idées, des suggestions ? (Je serai là dans 6 heures)

 

Частично, видимо, заодно к вопросу получаемых значений (для заполнения оперируемых буферов при расчете индикатора) из искомой функции protected static float[] Price(BasePrice price)

Toutes les classes, méthodes et propriétés de base renvoient désormais des valeurs doubles, de même que toutes les fonctions commerciales (j'ai modifié ces dernières il y a 6 mois).

Il semble qu'il y ait une différence dans la formule du RSI. Cela ne peut pas être dans le deuxième signe "mais nous avons déjà une différence dans le deuxième signe ! :) Je vais essayer d'adopter la formule RSI MT existante dans FSB.



**Edit :

Déjà corrigé :

Paramètres par défaut : RSI(close, 14, smoothed) == MT RSI

            for (int iBar = 1; iBar < Bars; iBar++)
            {
                if ( adBasePrice[ iBar] > adBasePrice[ iBar - 1]) adPos[ iBar] = adBasePrice[ iBar] - adBasePrice[ iBar - 1];
                if ( adBasePrice[ iBar] < adBasePrice[ iBar - 1]) adNeg[ iBar] = adBasePrice[ iBar - 1] - adBasePrice[ iBar];
            }

            double[] adPosMA = MovingAverage( iPeriod, 0, maMethod, adPos);
            double[] adNegMA = MovingAverage( iPeriod, 0, maMethod, adNeg);

            for (int iBar = iFirstBar; iBar < Bars; iBar++)
            {
                if ( adNegMA[ iBar] == 0)
                    adRSI[ iBar] = 100;
                else
                    adRSI[ iBar] = 100 - (100 / (1 + adPosMA[ iBar] / adNegMA[ iBar]));
            }


Programme à télécharger prochainement.


 

Miroslav - il n'y a pas de différences dans les formules. Comme je l'ai dit au début de la discussion sur le RSI - vous avez simplement une AUTRE boucle de calcul de la moyenne (qui crée de force un Smoothed à partir de n'importe quel résultat des fonctions MovingAverage fonctionnant correctement) :), SAUF la première valeur (qui reste de l'exécution de MovingAverage :).

Quoi qu'il en soit, à en juger par le dernier code cité, tout est rent ré dans l'ordre (et le RSI lira désormais les autres modes de calcul de la moyenne normalement) :) ! Yahoo !


(le code de l'indicateur, que j'ai sauvegardé auparavant, contient déjà ce changement ;) - il suffit d'appeler fsbRSI avec les paramètres suivants pour s'en assurer :

indLogic = pas important

maMethod = 2 ( ! important MODE_SMMA en termes de MT)

basePrice = 0 (PRICE_CLOSE en termes de MT)

iPériode = 14

fLevel = pas important

iPrvs = pas important

Et obtenez une correspondance exacte des résultats avec l'indice de force relative natif (qui est fourni avec MT).

Sauf que fsbRSI et iRSI ne sont PAS les mêmes que FSB :(


Revenons donc au problème principal:


"Toutes les classes de base, les méthodes et les propriétés renvoient désormais des valeurs doubles, de même que toutes les fonctions commerciales (j'ai modifié ces dernières il y a 6 mois)".


Eh bien, c'est génial ! Je ne comprends pas comment cette thèse devrait affecter

Prix d'ouverture de la barre et Prix de clôture de la barre? Dans l'exemple ci-dessus.


Pour répéter la question : pourquoi les prix demandés sont-ils DIFFÉRENTS des devis ??? (Je veux dire 6,7,8, ... chiffres)


Ledouble n'a absolument rien à voir avec cela ! Les valeurs entre guillemets sont normalisées et doivent être préservées (être complètement identiques) lorsqu'elles sont simplement copiées entre les variables.

Si des valeurs similaires commencent à apparaître dans le calcul des indicateurs (lorsque les tampons de calcul sont remplis sur la base des valeurs de cotation, le static float[] Price(BasePrice price)protégé ), alors on est BEAU (aussi étrange que cela puisse paraître), c'est-à-dire que c'est comme une autre source (en plus de l'ancien float), de données "légèrement" dénormalisées :)

 

J'ai légèrement modifié certains des indicateurs pour qu'ils ressemblent à ceux de la norme MT.


Changement des indicateurs FSB :

RSI

Oscillateur du RSI

Oscillateur RSI MA

Bandes de Bollinger

Écart-type

Stochastiques


Il existe des différences dans les indicateurs suivants :

Momentum

Indice de facilitation du marché


Autre :

Oscillateur de moyenne mobile MT == Histogramme MACD FSB

Momentum MT == Taux de variation FSB

Indice de Vigueur Relative - non inclus dans le FSB


Maintenant, les indicateurs FSB et MT devraient être plus ou moins égaux.


TODO :

Stochastiques - révision des signaux ;

Indice de facilitation du marché - révision de la formule ;

Un Momentum comme celui de la MT à inclure dans le FSB - nommé "Momentum MT".

Inclure l'"Indice de Vigueur Relative" dans FSB.

1...525354555657585960616263646566
Nouveau commentaire