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

Nouveau commentaire
 
Miroslav_Popov >> :

Et vous pouvez aussi ajouter le drawdown en pourcentage, pour que ce soit plus facile à voir. >> Merci.

 

Cela peut être le début d'un convertisseur FSB vers MQL4.

Toute aide et tout commentaire sont les bienvenus.


//+------------------------------------------------------------------+
//|                   FSB__Bar_Opening - Bar_Closing.mq4 v0.0.1 Beta |
//|                                 Copyright © 2009, Miroslav Popov |
//|                                              http://forexsb.com/ |
//|                                                                  |
//| An exmple EA pattern:                                            |
//| * Enter the market at Bar Opening                                |
//| * Exit the market at Bar Closing                                 |
//+------------------------------------------------------------------+
#property copyright "Copyright © 2009, Miroslav Popov"
#property link      "http://forexsb.com/"

// The time span before bar closing time in seconds.
// It determines the time interval for position closing.
extern double ClosingTimeSpan = 10;


int start()
{
   // Check if there are open positions from the previous bar
   int iOrders = OrdersTotal();
   if( iOrders > 0)
      ClosePositionsAtBarClosing(true, true, ClosingTimeSpan);
 
 
   
   // Opening Logic Conditions
   bool bLongEntryAllowed  = false;
   bool bShortEntryAllowed = false;

   // Put the entry logic rules here ...
   
   if(iMA(NULL, 0, 13, 0, MODE_SMA, PRICE_CLOSE, 1) >
      iMA(NULL, 0, 13, 0, MODE_SMA, PRICE_CLOSE, 2))
      bLongEntryAllowed = true;
   else
      bShortEntryAllowed = true;


   // Entry at Bar Opening
   iOrders = OrdersTotal();
   if( iOrders == 0)
   {
      if( bLongEntryAllowed || bShortEntryAllowed)
         OpenPositionAtBarOpening( bLongEntryAllowed, bShortEntryAllowed);
         
      iOrders = OrdersTotal();
      if( iOrders > 0)
         return(0);
   }



   // Exit Logic Conditions
   bool bCloseLong  = true;
   bool bCloseShort = true;

   // Put the exit logic rules here ...
   
   // Exit
   if( bCloseLong || bCloseShort)
      ClosePositionsAtBarClosing( bCloseLong, bCloseShort, ClosingTimeSpan);
}

// Entry at a Bar Opening price.
//
// MetaTrader does not provide an onBarOpen event so we check the current tick volume.
// We open a position when the current tick volume is equal to 1.
void OpenPositionAtBarOpening(bool bLongEntryAllowed, bool bShortEntryAllowed)
{
   if(! bLongEntryAllowed && ! bShortEntryAllowed)
   { // An entry is not allowed.
      return(0);
   } 
   
   // Check for Bar Opening
   if(iVolume(NULL, 0, 0) > 1)
   {  // This is not the first tick.
      return(0);
   } 
   
   int iLots = 1;

   // Check the free margin.
   if(AccountFreeMargin() < (1000 * iLots))
   {
      Print("We do not have money enough! Free Margin = ", AccountFreeMargin());
      return(0);  
   }
      
   int ticket = 0;
   if( bLongEntryAllowed)
   {
      ticket = OrderSend(Symbol(), OP_BUY, iLots, Ask, 3, 0, 0, "Bar Opening", 0 ,0 , Green);
   }
   if( bShortEntryAllowed)
   {
      ticket = OrderSend(Symbol(), OP_SELL, iLots, Bid, 3, 0, 0, "Bar Opening", 0 ,0 , Red);
   }
   
   if( ticket > 0)
   {
      if(OrderSelect( ticket, SELECT_BY_TICKET, MODE_TRADES))
         Print("Position opened at: ", OrderOpenPrice());
   }
   else 
   {
      Print("Error opening a position: ", GetLastError());
   }
      
   return(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.
void 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     = iTime(NULL, 0, 0) - TimeSeconds(iTime(NULL, 0, 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 || // The current tick is within the closing time span.
            iVolume(NULL, 0, 0) == 1                                 // or this is the first tick of next bar
            )
         {
            if(OrderType() == OP_BUY && bCloseLong)
            {  // Close a long position
               bIsOpen = OrderClose(OrderTicket(), OrderLots(), Bid, 3, Violet);
               
               if( bIsOpen)
                  Print("Long position closed at: ", OrderClosePrice());
               else
                  Print("Error closing a position: ", GetLastError());
            }
            else if(OrderType() == OP_SELL && bCloseShort)
            {  // Close a short position
               bIsOpen = OrderClose(OrderTicket(), OrderLots(), Ask, 3, Violet);
               
               if( bIsOpen)
                  Print("Short position closed at: ", OrderClosePrice());
               else
                  Print("Error closing a position: ", GetLastError());
            }
         }
      }
   }
   
   return(0);
}
 

Ce serait bien si FSB pouvait générer une dll avec la stratégie et la fonction pourrait ressembler à ceci :

#define inp   100
//---

#import "FSB.dll"
int    bEntryAllowed(double close[ inp], double open[ inp], double high[ inp], double low[ inp], volume[ inp]);
#import


c'est-à-dire envoyer un nombre de barres à la dll et obtenir une réponse de la stratégie.


La dll elle-même est comme ceci 

#define WIN32_LEAN_AND_MEAN  // Exclude rarely-used stuff from Windows headers
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
//----
#define MT4_EXPFUNC __declspec(dllexport)
#define inp 100
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
  {
//----
   switch( ul_reason_for_call)
     {
      case DLL_PROCESS_ATTACH:
      case DLL_THREAD_ATTACH:
      case DLL_THREAD_DETACH:
      case DLL_PROCESS_DETACH:
         break;
     }
//----
   return(TRUE);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
MT4_EXPFUNC double __stdcall int    bEntryAllowed(double close[ inp], double open[ inp], double high[ inp], double low[ inp], volume[ inp])

  {
   int out;

   //--- strategy

   if ( close[1]> close[0]) out = 1;
   if ( close[1]< close[0]) out = -1;

   return( out);
  }
vous avez de toute façon tous vos propres indicateurs et n'avez besoin que de données de séries chronologiques
 

Je fournirai un pont complet FSB <-> MT4 plus tard.

Ainsi, FSB recevra de MT des informations sur la cotation et le compte et renverra des ordres de négociation. De cette façon, il sera en mesure de négocier les stratégies FSB dans MT.


Maintenant, j'essaie de faire quelques cadres EA de base pour adapter les stratégies FSB dans MT comme EA sans aucune interopérabilité.


J'ai besoin de plusieurs modèles simples comme :


* Entrer (ajouter, réduire, fermer) à l'ouverture de la barre (ou à la valeur de l'indicateur) lorsque :

- condition1 == true ; et

- condition2 == vrai ; et

- condition3 == true ; et

- condition4 == true

* Sortir à la fermeture du bar quand :

- condition1 == true ; ou

- condition2 == vrai ;

ou

* Sortir à la valeur de l'indicateur.

ou

* Sortie au Stop Loss permanent

ou

* Inversez en suivant les règles de participation.


La plupart des indicateurs sont standards et les autres sont assez simples et peuvent être facilement réécrits en MQL4. Une fois que nous avons le modèle de base de l'EA, il n'y aura aucun problème pour traduire les indicateurs.


Les choses que je teste actuellement sont :

Ouvrez une position à l'ouverture de la barre et fermez-la à la fermeture de la barre.


J'espère donc développer deux nouveaux produits :

1. FSB - Pont d'alimentation et d'exécution des données MT

2. exportateur de stratégie vers MQL4


Il est probable que les deux programmes seront open source.

 

(oh, je pensais que le sujet était calme maintenant... animons-le :) ?! (Je vais écrire beaucoup ... je vais essayer d'être logique ;), et de ne pas surcharger le sujet - je vais le diviser en plusieurs messages)


Messieurs, bienvenue !


Miroslav - tout d'abord, quelques mots "sur le temps" (la partie lyrique)... (J'espère sincèrement que votre compréhension du russe est à la hauteur :))).


Le produit, bien sûr, est génial ! Je parle de mon expérience, à la fois en tant qu'ancien programmeur et en tant qu'utilisateur abstrait (logiciel abstrait). On peut sentir l'amour qu'on lui porte (parce que tout est fait très soigneusement) et il y a un espoir que le développement du programme ne s'arrête pas "soudainement" (ne pas mourir). Oui, il est fort probable qu'il y ait des erreurs de logique (par exemple avec Data Horizon), de petits bugs dans l'interface... Mais dans l'ensemble - C'EST LA CHANSON ! C'est juste une chanson ! !!


Je demande au public de prêter attention à un autre fait révélateur. L'attitude à l'égard de la critique et le style de discussion sur les problèmes/manques/nouvelles fonctionnalités/etc. Il s'agit de moi dans le contexte du début du fil de discussion, où le développement du produit alternatif a commencé, et comment l'auteur du SSB a réagi aux commentaires faits à son adresse. Je ne pense pas que Miroslav ait également un "wagon" de temps pour développer un programme GRATUIT (et qu'il soit un tel programmeur). Mais il trouve du temps pour nous (pour communiquer), en fonction de nos commentaires et demandes pour finaliser le produit, corriger les bugs et offrir quelque chose de nouveau (voir ses récents posts). Et tout est calme, mesuré, sans hystérie, comme dans l'affaire SSB précitée. Cela mérite un respect (supplémentaire). Mes salutations, Miroslav...


Pour terminer la partie lyrique (distraitement maintenant) - que je suis personnellement un partisan de la théorie du "mouvement aléatoire des prix". C'est-à-dire que dans cette question je partage complètement l'opinion d'un certain cercle de personnes (y compris les créateurs de sites comme http://www.bigmany.ru), qui sont convaincus que travailler sur le marché (je veux dire Forex et "tout ce qui s'en rapproche") où il n'y a aucun moyen de reconnaître le deuxième des (seulement) deux indicateurs principaux du marché (je veux dire le Volume). - il est tout simplement inutile et dénué de sens (dépourvu de tout sens raisonnable) de se fier à toute information provenant de l'analyse technique et, dans une moindre mesure, de l'analyse fondamentale...


Nous aurions pu finir ici en général :), mais comme vous le savez - la Russie est connue pour ses imbéciles et ses routes, et en utilisant le premier point de cette déclaration - je ne laisse toujours pas l'idée "de faire des millions" :D, en fait - je suis juste curieux. Il est intéressant d'écouter les "opinions des analystes" (comme les astrologues avec leurs horoscopes - "beaucoup de spécialistes", pas beaucoup d'utilité), il est intéressant de regarder les graphiques (vous êtes d'accord - c'est incroyable), il est intéressant de creuser dans le code (vous commencez à vraiment comprendre ce que les gens essaient d'exprimer avec cet indicateur), ... C'est juste intéressant... Il est intéressant de tromper (ou mieux encore - de ne PAS tromper) le "système" un jour... C'est la raison pour laquelle je suis ici (sur le marché, sous condition). Et j'espère en tirer profit non seulement pour moi, mais aussi pour le public. Parce que comme Miroslav - un certain altruiste dans la vie.


Mon opinion actuelle est que les systèmes d'analyse technique actuellement utilisés dans le monde (et la nette majorité d'entre eux) participent effectivement au marché. C'est-à-dire que la foule de personnes, regardant leurs moniteurs et guidées par les valeurs de leurs indicateurs, s'attend amicalement à un mouvement dans une certaine direction, fait des transactions... et fait bouger ce même prix. Même si c'est à petite échelle, même si ce n'est pas toujours le cas (il y a encore des propriétaires d'"usines, de journaux, de bateaux à vapeur" qui se fichent complètement de l'AT, ils ont juste besoin d'acheter ou de vendre un certain volume à un certain moment). Mais ça arrive ! En d'autres termes, en étant "dans la boucle" (du même TA), vous pouvez essayer de faire évoluer la probabilité de vos mouvements aléatoires positifs sur le marché vers (légèrement ?) plus de 50%. Ce n'est pas facile... MAIS possible ! Dès que je serai déçu par ce postulat - je quitterai le marché... (et il ne s'agira pas de la taille des profits/pertes, c'est juste, eh bien, vraiment frustrant et inutile de travailler dans un système complètement aléatoire.... bien, voir ci-dessus)

 

Alors, maintenant, parlons affaires.

1. Pendant qu'il y a une accalmie ici, j'ai réfléchi. Oui, nous pouvons attendre Miroslav (quand il fera un pont entre MT et FSB, ou ici, un compilateur de stratégie). Mais, à la fin, c'est celui qui fait au moins quelque chose lui-même qui obtient le résultat :). Je suis parti de l'hypothèse que j'ai (garanti) un outil donné (FSB), j'ai MT, supposons qu'en dehors de ces deux entités il n'y aura rien d'autre - nous opérons donc dans leur cadre, à savoir : FSB (pour le moment) est un système fermé ; nous aurons besoin de MT de toute façon ; le code du conseiller (robot de trading) sera nécessaire dans tous les cas - oui, il devrait y avoir un modèle universel, qui donne (en gros) les valeurs des indicateurs et tout, puis selon le "schéma approuvé" ; nous aurons donc besoin des indicateurs eux-mêmes.


2. Je vais m'arrêter tout de suite au code du conseiller expert. Je ne partage pas l'optimisme des créateurs d'Expert Advisors simples - en effet, il est impossible d'imaginer le nombre de situations anormales dans le terminal et sur le marché. Et nous parlons d'argent, aucune plaisanterie n'est appropriée (ils n'ont pas vérifié le code d'erreur - ils ont calculé une action par défaut...). et c'est tout, - 1000 $ sont supprimés (sous condition)). En d'autres termes, je suis convaincu que tout expert qui s'occupe réellement d'argent (ou, mieux, d'argent réel) doit être " à toute épreuve " en termes de réactions aux événements extérieurs. Le code doit prévoir un nombre maximal de variations dans le fonctionnement du terminal, du serveur ou du marché lui-même. En bref - c'est assez sérieux, et ne peut pas être résolu (écrit) avec un saut. Je serais heureux de participer à la création de tels modèles. Mais...


3. J'ai décidé de faire tout le chemin depuis le bas. J'ai eu une idée - s'il n'y a rien à faire avec un conseiller expert (indicateurs) - pourquoi avons-nous besoin d'un conseiller expert alors :) ! J'ai donc pris les indicateurs.

La prémisse était la suivante. Tout d'abord, personne ne peut garantir que les valeurs des indicateurs du CSF sont équivalentes aux valeurs des indicateurs standard ou supplémentaires de la MT. Et pour obtenir des résultats "comparables" dans les deux programmes, les valeurs doivent être les mêmes. Deuxièmement, le nombre d'indicateurs eux-mêmes (standard) est TOUJOURS différent. Et pour utiliser (et rechercher) les externes... d'une manière ou d'une autre, j'aime la norme ou la mienne (dans la vie)... (Troisièmement - j'ai l'impression que la "conversion" du code des indicateurs de FSB n'est pas une tâche si gigantesque, comme l'a mentionné Miroslav - les algorithmes eux-mêmes sont assez simples, les indicateurs eux-mêmes sont très "organisés" en termes de code (le code est unifié), c'est-à-dire qu'en gros - ils créent un ensemble d'erreurs.En gros, nous créons un modèle une fois et le "remplissons" de certains indices un par un (c'est l'image idéale du monde :))). Il y en a plus dans le quatrième - je me demandais :).

Bref, c'était ça le week-end. Avant de commencer quelque chose, j'ai l'habitude de "prendre le temps d'exploiter" (dans ce cas, de réfléchir). Je n'ai pas le temps de modifier le modèle lui-même (je le comprends). Surtout lorsque le nombre d'indicateurs dépasse un certain chiffre. Il faut donc concevoir les points clés en une seule fois. Par conséquent, j'ai formulé les hypothèses suivantes :


- Il doit s'agir d'indicateurs (et pas seulement de fonctions pour le futur code du conseiller expert). Après tout, la perception visuelle de l'information ne joue pas le moindre rôle pour un humain (et pour moi, en particulier), et l'appel d'un indicateur à partir du code Expert Advisor n'est pas un si gros problème (l'iCustom a déjà causé beaucoup de problèmes sur le forum - quand il y a tant d'opinions, je préfère généralement tout vérifier moi-même, les résultats de mes "tests sur le terrain" feront l'affaire, il y a probablement un petit overhead, mais n'est PAS un gros (je le déclare en toute responsabilité) et je pense qu'il peut être négligé en termes d'universalité). Mais pour les "connaisseurs spéciaux" :) (juste au cas où) au cas où les calculs dans les indicateurs sont effectués dans une fonction séparée du même type (voir ci-dessous).


- Les indicateurs doivent produire les mêmes valeurs que dans le FSB original (point négocié séparément ci-dessous). C'est-à-dire que le code de FSB est pris comme base et, si possible, modifié le moins possible.


- Le code doit être optimisé pour fonctionner correctement avec IndicatorCounted (c'est-à-dire en fonction de la vitesse).


- Les paramètres des indicateurs, ainsi que leurs valeurs, doivent être uniformes et homogènes. Je ne parle pas des types de données, en tant que tels. Si nous regardons le code des indicateurs de Miroslav, nous verrons une bonne homogénéité des paramètres d'entrée et des tampons de sortie. Il s'agit de conserver l'image initiale pour permettre aux utilisateurs d'être facilement guidés lors de l'indication des paramètres ou du relevé des valeurs des indicateurs.

- L'implication du point précédent est ... mm (attention - c'est important). Le point essentiel de l'utilisation de tous les indicateurs n'est pas qu'ils génèrent des valeurs propres. C'est qu'ils produisent SIGNAUX! Vraiment, pour moi en tant que personne - quelle différence cela fait-il de savoir quelle est la valeur d'un indice maintenant ou plus tard ( ?!) Cela reste des "chiffres incompréhensibles". Ce qui est compréhensible, c'est quand c'est soit "Acheter", soit "Vendre" :). Tout le reste n'est pas clair ! Miroslav a utilisé cette idée de façon très élégante en créant deux tampons dans chaque indicateur (pour les positions longues et courtes) qui, selon la façon dont l'indicateur est utilisé (en tant que point de la position ou de la condition logique), acquièrent des valeurs d'ouverture/fermeture d'une position ou du filtre Oui/Non (si tous les "Oui" dans la logique d'ouverture - ouvrir, si au moins un "Non" dans la logique de fermeture - fermer (en général, RTFM). Génial ! ;) J'ai suivi cette voie et simulé ce comportement. Actuellement, les deux premiers tampons de l'indicateur (dont les valeurs peuvent être vues dans la fenêtre de données) sont les tampons correspondants avec des filtres (1/0) ou des valeurs de prix pour ouvrir des positions à l'achat ou à la vente, respectivement. Plus tard, lors de l'utilisation des indicateurs dans le code du conseiller expert, il ne se soucie pas vraiment de ce que, où ou quelles valeurs un indicateur particulier génère - il va juste analyser les valeurs des deux premiers tampons pour un sujet très simple (Oui/Non (conditionnellement) ou prise directe du prix à partir de là) ... Et c'est tout ! Il y a une nuance - presque 100% "trébucheront" sur Ishimoku (là, la quantité de tampons propres à l'indicateur est proche de la limite du MT lui-même (8)). - Je ne veux pas refuser une belle idée (avec les deux premiers tampons), mais je ne peux pas les combiner en un seul (je pensais... il pourrait y avoir non seulement des 1/0 (qui pourraient être transformés en bitmask), mais aussi des étiquettes de prix). Il est probable que je doive faire quelque chose avec les valeurs des indicateurs eux-mêmes... Nous verrons bien... Comme nous allons...

 

En général, en bref (résumés) : qualité (compatibilité FSB, sans bogue, etc.), facilité d'utilisation ultérieure, rapidité, lisibilité du code. Dans cet ordre.

Eh bien, et (en fait) - ce qui s'est passé ... (bref historique)

- Tous les indicateurs ont la valeur "fsb" dans le préfixe du nom de fichier (exemple : "fsbBlaBlaBla.mq4").


- J'ai pris les indicateurs eux-mêmes dans un ordre pseudo-aléatoire, alors ne m'en voulez pas. Jusqu'à présent, il y a, c'est. Pour plus de discussion/analyse, etc. - Je pense que ça suffit.


- Miroslav utilise trois fonctions externes (qui sont placées dans les sources (tout en bas de la page)) pour calculer la Moyenne Mobile et les valeurs des buffers logiques. J'ai dû commencer par eux. Toutes les fonctions sont regroupées dans un seul fichier (" fsbCommon.mq4 "), organisées en fonctions de bibliothèque (" fsbCommon.mqh "). Il existe un autre fichier de cet opéra (" fsbConstants.mq4 "), qui, respectivement, contient des constantes pour plus de commodité dans le code. Il n'y avait pas de problèmes particuliers avec les fonctions elles-mêmes (j'ai un peu compliqué la logique initiale des "oscillateurs logiques", pour des vérifications supplémentaires (tableaux hors limites, valeurs initiales correctes garanties (les premières de l'histoire) (Miroslav, il y a un erreur logique dans le code sur ce sujet).. .et essayé pendant longtemps "d'émuler" le comportement d'iShift dans MovingAverage afin que la fonction remplisse correctement les valeurs du tampon résultant pour toute valeur saine de ce paramètre (et pas seulement pour les restrictions qui sont données dans le code d'origine) ... en conséquence, j'ai abandonné ce sujet pour l'instant, en mettant un "stub" au début (avec iShift autre que "0", la fonction ne fonctionne pas travail encore, qui, cependant, n'a pas encore été nécessaire)). MovingAverage s'est avéré fastidieux, mais il fait d'une pierre plusieurs coups. Depuis le retour du tampon de la fonction en tant que valeur dans MT, il n'est pas possible (peut-être pas nécessaire) - un paramètre supplémentaire est apparu à la fin ( afTarget ) De plus, compte tenu de IndicatorCounted (), une étape de plus Le paramètre est responsable de la valeur de la première barre pour le traitement. Eh bien, le dernier paramètre supplémentaire définit la "constante de prix" en termes de MT, par la valeur de laquelle les valeurs de la MovingAverage elle-même sont calculées sur la base des tableaux de séries existants, ou (si la valeur iAppliedPrice en dehors des valeurs des "constantes de prix" MT) - basé sur afSource . (d'où la surcharge du code) Je préciserai tout de suite la nuance de programmation - où il y a des cycles entrecoupés de sélections par cas - les cycles sont insérés à l'intérieur des sélections, et non (ce qui est généralement plus logique) l'inverse. Fait non pas parce que je ne sais pas comment le faire correctement - mais parce que je sais à quelle vitesse :) ! (enfin, à l'avenir, je ne m'attarderai pas là-dessus, quiconque veut analyser le code - de rien, mais avant de poser la question "sur la bêtise du code" réfléchissez un peu à ce qui (potentiellement) pourrait causer une telle programmation).


Une autre nuance est liée à MovingAverage (cela peut être informatif pour quelqu'un) - parce que. Les valeurs de la moyenne mobile dans les modes de lissage exponentiel (y compris Smoothed) dépendent directement de leurs propres valeurs précédentes - le choix du "point de départ" devient très important (quelle valeur prendre comme base pour les calculs ultérieurs). Il existe généralement plusieurs approches pour cela. Quelqu'un prend le cours de clôture de la période précédente. Quelqu'un a fait la moyenne du prix pour la période précédente N... Miroslav est allé dans le deuxième sens. MT vient clairement en premier. D'où les écarts importants dans ces deux modes de lissage au début du graphique (j'ai ajouté un blanc pour tester MovingAverage et tout le reste (" fsbTest.mq4 ")) ! Et les restrictions imposées par moi à l'intérieur de la fonction sur la disponibilité des données du MovingAverage lui-même AVANT QUE iFirstBar, ou une quantité similaire de valeurs calculées APRÈS iPremière barre. Car les indicateurs eux-mêmes utilisent une constante pour la valeur minimale des barres sur le graphique (maintenant 2000) - cela devrait suffire pour n'importe quelle situation (car je n'ai pas encore vu de paramètres avec des périodes supérieures à 200). À moins, bien sûr, que plus d'un MA soit utilisé à la fois ;).


- Par analogie avec le paragraphe précédent, des fichiers ont été créés pour des sous-fonctions externes que j'utilise déjà dans mon travail avec ce projet (préfixe "st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")


- Eh bien, en fait - les indicateurs eux-mêmes. En termes très courts (prenons " Bar Range " comme exemple):

 //extern int slotType = SLOT_TYPE_LC ;

externe int indLogique = INDICATOR_RISES ;    // (INDICATOR_RISES <= indLogic <= INDICATOR_LOWER_LL)

externe int nBars = 1 ;                  // 1 <= nBars <= 200

externe int fLevel = 0 ;                  // 0 <= fNiveau <= 500

externe bool iPrvs = Vrai ;                // Vrai faux

slotType ensembles taper fentes dans Termes FSB (point de la position ou condition logique) . Ces indicateurs qui peuvent être non seulement des filtres d'entrée/sortie, mais également définir le prix d'ouverture/de clôture - ce paramètre détermine exactement ce que l'indicateur générera dans ses tampons logiques. Voir toutes les constantes dans fsbConstants.mq4 (tout y est assez clair)

indLogique - en fait, une condition logique pour l'indicateur (porte une charge sémantique différente, selon la valeur slotType )

Eh bien, les paramètres vont plus loin, dans l'ordre dans lequel ils apparaissent dans les sources d'indicateurs sur forexsb.com, et comment ils sont affichés dans le FSB lui-même. Les limites des paramètres sont spécifiées dans les commentaires et sont contrôlées lors de l'appel de init() en appelant la sous-fonction PCheck().

 double LPIndBuffer [] ;            // Positions longues #1

double SPIndBuffer [] ;            // Positions courtes #2



doubleIndBuffer [ ] ;              // Valeurs de l'indicateur #3



doubleIndBufferDD [ ];            // Tampon supplémentaire pour le dessin #4

doubleIndBufferDU [ ] ;            // Tampon supplémentaire pour le dessin #5

Avec les tampons, tout ce qui se trouve au niveau global est utilisé comme tampon d'indicateur (attaché à l'indicateur lui-même). Juste les logiques souhaitées (LPIndBuffer[], SPIndBuffer[]) (toujours et toujours dans cet ordre (#0 - positions longues, #1 - positions courtes)), IndBuffer[] - données de l'indicateur lui-même. Mais dans ce cas, puisqu'un histogramme de couleurs est utilisé, ce tampon ne porte que les valeurs elles-mêmes, et deux tampons supplémentaires sont utilisés pour le rendu des couleurs (pour être honnête, MT a commencé à programmer simplement en transférant des indicateurs :), et comment pouvez-vous simuler le comportement des histogrammes de couleurs dans MT sinon - je ne l'ai jamais trouvé (qui peut le dire? Si c'est même possible)). Ils ne sont en aucun cas affichés dans DataWindow.

À init() tout est comme d'habitude (les valeurs des paramètres sont vérifiées, les noms de l'indicateur lui-même et les indices sont définis, les tampons sont attachés, etc.)


Dans deinit(), je pense insérer une logique en cas de non fermeture de l'indicateur (commodité supplémentaire, pour que les paramètres, là, ne soient pas réinitialisés, etc.), à ma guise (pas encore prioritaire).


Démarrer() très primitif. Sa tâche est de vérifier qu'il y a suffisamment de barres sur le graphique (pour calculer n'importe quel MA et en général) et d'appeler la fonction de calcul de l'indicateur lui-même, en cas d'appel réussi, le dessin personnalisé de l'indicateur est appelé (s'il doit être dessiné d'une manière ou d'une autre d'une manière spéciale, comme dans ce cas comme -une fois)


Calculer() - calculs réels. Le code, en général, est similaire au code de Miroslav, des exceptions sont faites pour les optimisations liées à IndicatorCounted(). Si des tampons d'indicateurs supplémentaires sont nécessaires pour calculer l'indicateur, ils sont définis à l'intérieur de la fonction elle-même (statique) (afin de ne pas gaspiller les index de l'indicateur lui-même) et sont gérés par la fonction BufferSync(). Voici une blague distincte - au départ, il y avait une tentative de limiter les calculs par un autre paramètre constant (iMaxBars). "Field tests" (partie 2) du comportement des tableaux de séries en présence d'historique, d'absence, de mouvement dans le futur (l'arrivée des guillemets, l'augmentation des tableaux vers la DROITE (je suis maintenant visuellement, à propos de la représentation graphique )), ... mouvement dans le passé (lorsque l'historique est manquant (on se déplace vers la gauche sur le graphique) et que le terminal le charge depuis le serveur... et que les tableaux s'étendent vers la GAUCHE)... Donc. .. Cassé. Je l'ai fait magnifiquement (essayé de le faire) - en fonction de la direction de l'expansion BufferSync () et élargit le tableau resp. à gauche ou à droite, en remplissant les valeurs vides EMPTY_VALUE. Ici, seul MT ne développe normalement pas les tableaux d'index vers la GAUCHE. Il les développe TOUJOURS vers la droite (du côté de [0] Mesure). J'espère que ce dont je parle est clair - que lors du prochain saut dans l'histoire, lorsque la valeur des barres sur le graphique dépasse iMaxBars (en sautant, encore) - des situations sont tout à fait possibles lorsque l'indicateur ne tirera pas ses valeurs à gauche d'iMaxBars, mais voici des "données étranges", à gauche d'iMaxBars peut être facilement. Peut-être que personne ne les regardera... Mais "pas beau" (pas notre méthode). Et tout ce qu'il faut, c'est que MT lui-même complète les tampons avec des valeurs vides dans le bon sens ... Il est potentiellement possible d'attraper une telle situation, mais ... En général, nous dessinons dès le début du tableau ... _toujours_. (Eh bien, dans la mesure du possible pour cet indicateur particulier)


Une autre nuance est associée à IndicatorCounted() - semble-t-il - une fonction divine. Renvoyez les valeurs des barres calculées et il n'y aura aucune réclamation contre vous... SERA ! Je pense que ce n'est pas l'IndicatorCounted() lui-même qui est à blâmer (ainsi que les programmeurs de MQ), mais un groupe de programmeurs d'indicateurs personnalisés, qui n'ont pas atteint le but divin de cette fonction. Par conséquent, il est obligé de toujours retourner un petit nombre de valeurs potentielles. Soit on recalcule tout le graphique (IndicatorCounted() == 0), soit le premier ((IndicatorCounted() == Bars - 1) ou deux (IndicatorCounted() == Bars - 2) barres. par exemple, si la connexion est interrompue et que le graphique "a parcouru" plus d'une barre d'avance - c'est tout ... "les arbres sont morts debout" (IndicatorCounted() == 0) - nous comptons tout le graphique sur un nouveau Pourquoi ? Il était impossible de retourner le nombre de mesures sautées (3, 4, ... 5... 10...)? (ce à quoi cette fonction était destinée, si je comprends bien, initialement) En général, comme ça. ..

... Je suis "tombé" sur le RSI. Et dans tous les sens. Premièrement, je n'ai pas compris le code de Miroslav (les questions qui lui seront posées iront ci-dessous). Deuxièmement, lors du test de l'indicateur, j'ai constaté des écarts dans les valeurs obtenues au sein de MT et FSB ! Non, ce n'est pas du tout ce que vous pensiez (« supporté de travers » - eh bien, avouez-le, vous pensiez ;)). Le point, malheureusement, semble être dans ces déclarations :

 float [] afPos = Nouveau float [ barres ] ;

...

somme flottante ; _

...

En bref - flotter ! Après un peu de réflexion, j'ai ralenti pour le moment. la toute première thèse (précision et qualité) est devenue discutable (et c'est une priorité).


Le raisonnement suivant est possible ici : d'une part, le flottement n'est pas mauvais, c'est en quelque sorte un "rugueux" des valeurs de l'indicateur, ce qui devrait rendre la stratégie de trading encore moins sensible aux pics aléatoires du marché. Par contre, par exemple, lors du franchissement de certains fLevel (1.0, par exemple) - vous en conviendrez : 0.99998 et 1.00001 sont deux grosses différences :). Et il y a de telles divergences. Et si la pose s'ouvre à tel ou tel moment, mais qu'en fait le niveau FSB n'atteint toujours pas 1.0 et descend, alors à qui la faute ? (celui qui a transféré les indicateurs :D ?!)


Il existe en fait deux solutions (étant donné que float MT n'est pas pris en charge !) :


- émuler un flottant dans le MT lui-même (avec quelques constructions déchirantes comme NormalizeDouble(X, Digits + 2) ) - enfin, pas partout, mais considérez que chaque multiplication/division par n'importe


- changer le flotteur dans le FSB en double. Ici, vous devez comprendre la portée des changements, évidemment limitée, mais vous devez marcher avec précaution partout. Et que le résultat potentiel des stratégies générées chez l'homme peut « flotter ». Et en général, Miroslav en a-t-il besoin? (mon humble avis est que le FSB lui-même en a besoin, car une précision supplémentaire n'a jamais fait de mal à personne, mais à la vitesse des calculs (si cet objectif était poursuivi (?), car je ne vois plus de raisons) dans cette section de temps de la réalité Cela ne devrait pas avoir d'effet significatif.) Je suis d'accord sur cette question avec les gars de MQ - parce que. si nous n'opérons pas avec des mathématiques entières (certaines décimales), alors au moins nous essaierons avec le maximum de précision possible. En général, voici une telle ... pas une question facile ...

 

Désolé d'être verbeux (je n'en dirai pas plus, juste l'essentiel).


J'aimerais avoir un avis - faut-il poursuivre ce sujet (et "aller" plus loin, le reste des indicateurs à creuser) ? Je peux même dans un certain ordre (puisque tout de même le désordre original :)), qui, peut-être, ce qui doit aller de l'avant. Le temps, malheureusement, dans le cas général, en est privé (directeur général adjoint dans son bureau - "la journée passe inaperçue" :D). Je trouve le temps généralement le soir. Mais un ou deux indicateurs par jour, je pense pouvoir fournir...



Donc, des questions pour Miroslav sur le sujet...

1. Quelle est la valeur de fMicron? (Je l'ai réglé (à la réflexion) à 0,000001, il me semble, ou est-ce encore plus petit ?


2. Quel est le paramètre bIsDescreteValues (dans la logique de l'oscillateur). J'en comprends le sens - mais quelle est sa valeur par défaut ? Et de quelles conditions dépend ce changement ? (ou plutôt - à quoi est-il lié (dans l'interface FSB ou ailleurs))


3. En fait de RSI, qu'est-ce que ce dessin ?

pour (int iBar = iFirstBar; iBar < Bars; iBar++)

{
 afPosMA[iBar] = (afPosMA[iBar - 1] * (iPeriod - 1) + afPos[iBar]) / iPeriod;
 afNegMA[iBar] = (afNegMA[iBar - 1] * (iPeriod - 1) + afNeg[iBar]) / iPeriod

}

:) ? La motivation de cette question est la suivante : Si ma vision est correcte - il s'agit d'une MA lissée. Dans le contexte du code entier - il est appliqué à une MA déjà calculée et génère une MA lissée, où seule la première valeur reste "vivante" :). C'est une question logique : qu'est-ce qui est superflu ici ? Cette construction, qui rend entre autres REALIZED( !) le choix des modes de lissage RSI dans l'indicateur lui-même (il s'avère toujours lissé), ainsi que dans ses dépendants. Ou les calculs MA précédents (avec le mode correct des paramètres) pour afPos, afNeg ?


En clair, le RSI classique est basé sur la moyenne lissée. Mais il existe au moins une variante avec Simple MA et il serait logique de supprimer le code ci-dessus rendant opérationnel le comportement du paramètre maMethod. Ou nous supprimons le calcul de la MA avant ce cycle et supprimons les paramètres MA RSI dans tous les indicateurs (puisqu'ils n'affectent rien de toute façon !).


Je supprimerais ce code (ci-dessus) :). (Dans l'indicateur converti cette partie est commentée, qui a besoin de la fonctionnalité originale - enlevez les balises de commentaire ! Le code RSI n'est donné qu'à titre indicatif... Jusqu'à ce que nous décidions ici, je l'utiliserais "à mes risques et périls" :))


4. Comme déjà dit, il y a une erreur logique non critique dans la logique des oscillateurs dans le comportement sur les barres initiales. Je n'arrive pas à le distinguer maintenant, je le noterai demain (où et comment le corriger).


5. Que devons-nous faire avec le flottant dans le FSB? (ou avec son absence dans MT) :) ?


L'archive contient les fichiers nécessaires, décompressés à la racine de MT (l'archive sera dans le prochain post).


Bonne chance à tous... écrire :)
 

Archives des indicateurs actuels (2009-04-15)

Dossiers :
experts.rar  101 kb
 

Je suis d'accord que le flottement n'est pas battu - vous devez chercher une issue. Nous devons rédiger la correspondance. Créez ensuite une bibliothèque d'indicateurs. Si je peux aider, j'en serai heureux.

1...505152535455565758596061626364...66
Nouveau commentaire