Wer will eine Strategie? Lose und kostenlos) - Seite 57

Neuer Kommentar
 
Miroslav_Popov >> :

Außerdem können Sie den Drawdown als Prozentsatz hinzufügen, damit er leichter zu erkennen ist. >> Danke.

 

Dies kann der Anfang eines FSB zu MQL4 Konverters sein.

Jede Hilfe oder Rückmeldung ist sehr willkommen.


//+------------------------------------------------------------------+
//|                   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);
}
 

Es wäre schön, wenn FSB eine DLL mit der Strategie generieren könnte und die Funktion so aussehen könnte:

#define inp   100
//---

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


d.h. eine Anzahl von Takten an die DLL senden und eine Antwort von der Strategie erhalten


Die DLL selbst sieht folgendermaßen aus 

#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);
  }
Sie haben ohnehin alle Ihre eigenen Indikatoren und benötigen nur Zeitreihendaten
 

Ich werde später eine vollständige FSB <-> MT4-Brücke bereitstellen.

FSB nimmt also Kurs- und Kontoinformationen von MT entgegen und sendet Handelsaufträge zurück. Auf diese Weise wird er in der Lage sein, die FSB-Strategien in MT zu handeln.


Jetzt versuche ich, einige grundlegende EA-Frameworks zu machen, um die FSB-Strategien in MT als EA ohne Interop einzubauen.


Ich brauche mehrere einfache Muster wie:


* Eingabe (hinzufügen, reduzieren, schließen) bei Bar Opening (oder Indikatorwert), wenn:

- condition1 == true; und

- condition2 == true; und

- condition3 == true; und

- condition4 == true

* Beenden bei Barschluss, wenn:

- condition1 == true; oder

- condition2 == true;

oder

* Beenden bei Indikatorwert.

oder

* Ausstieg bei permanentem Stop-Loss

oder

* Umkehren, indem Sie die Teilnahmebedingungen befolgen.


Die meisten Indikatoren sind Standardindikatoren und die anderen sind ziemlich einfach und können leicht in MQL4 umgeschrieben werden. Sobald wir das Basis-EA-Muster haben, ist es kein Problem mehr, die Indikatoren zu übersetzen.


Die Dinge, die ich jetzt teste, sind:

Öffnen Sie die Position bei "Bar Opening" und schließen Sie sie bei "Bar Closing".


Ich hoffe, dass ich zwei neue Produkte entwickeln kann:

1) FSB - MT-Dateneinspeisung und Ausführungsbrücke

2. Strategie-Exportprogramm für MQL4


Wahrscheinlich werden beide Programme quelloffen sein.

 

(Oh, ich dachte, das Thema sei jetzt ruhig... beleben wir es wieder :)? (Ich werde viel schreiben ... ich werde versuchen, logisch zu sein ;), und das Thema nicht zu überladen - ich werde es in mehrere Nachrichten aufteilen)


Meine Herren, willkommen!


Miroslav - zunächst ein paar Worte "über das Wetter" (der lyrische Teil)... (Ich hoffe aufrichtig, dass Ihre Russischkenntnisse auf dem neuesten Stand sind :))).


Das Produkt ist natürlich großartig! Ich spreche aus meiner Erfahrung, sowohl als ehemaliger Programmierer als auch als abstrakter Nutzer (abstrakte Software). Man spürt die Liebe dazu (weil alles sehr sorgfältig gemacht wird) und es besteht die Hoffnung, dass die Entwicklung des Programms nicht "plötzlich" aufhört (nicht stirbt). Ja, höchstwahrscheinlich gibt es einige logische Fehler (ein anschauliches Beispiel war Data Horizon), es gibt kleine Bugs in der Schnittstelle ... Aber im Großen und Ganzen - THIS IS THE SONG! Es ist nur ein Lied!!!


Ich bitte die Öffentlichkeit um Aufmerksamkeit für eine weitere aufschlussreiche Tatsache. Die Haltung gegenüber Kritik und die Art der Diskussion von Problemen/Mängeln/Neuerungen/etc. Ich stehe im Zusammenhang mit dem Beginn des Threads, in dem die Entwicklung des Alternativprodukts begann, und mit der Reaktion des Autors der SSB auf die an ihn gerichteten Kommentare. Ich glaube nicht, dass Miroslav auch nur einen "Wagen" Zeit hat, um ein KOSTENLOSES Programm zu entwickeln (und dass er ein solcher Programmierer ist). Aber er findet Zeit für uns (zu kommunizieren), nach unseren Kommentaren und Anfragen, um das Produkt zu finalisieren, behebt Fehler und bietet etwas Neues (siehe seine jüngsten Beiträge). Und alles ist ruhig, maßvoll, ohne Hysterie, wie im oben erwähnten Fall der SSB. Das verdient (zusätzlichen) Respekt. Mit freundlichen Grüßen, Miroslav...


Um den lyrischen Teil abzuschließen (um jetzt abzulenken) - dass ich persönlich ein Anhänger der Theorie der "zufälligen Preisbewegung" bin. D.h. in dieser Frage teile ich voll und ganz die Meinung eines bestimmten Kreises von Menschen (einschließlich der Schöpfer von Seiten wie http://www.bigmany.ru), die davon überzeugt sind, dass die Arbeit auf dem Markt (ich meine Forex und "alles, was damit zu tun hat"), wo es keine Möglichkeit gibt, den zweiten von (nur) zwei Hauptmarktindikatoren (ich meine Volumen) zu erkennen. - Es ist einfach nutzlos und sinnlos (ohne jeden vernünftigen Sinn), sich auf Informationen aus der technischen und, in geringerem Maße, der fundamentalen Analyse zu verlassen...


Wir könnten hier im Allgemeinen beendet haben :), aber wie Sie wissen - Russland ist berüchtigt für Narren und Straßen, und mit dem ersten Punkt dieser Aussage - ich immer noch nicht verlassen die Idee "um Millionen zu machen" :D, in der Tat - ich bin nur neugierig. Es ist interessant, "Analystenmeinungen" zu hören (wie Astrologen mit ihren Horoskopen - "viele Spezialisten", nicht viel wert), es ist interessant, sich einfach nur Horoskope anzuschauen (Sie stimmen zu - es ist erstaunlich), es ist interessant, mit Codes herumzuspielen (Sie fangen an, wirklich zu verstehen, was Menschen mit bestimmten Indikatoren auszudrücken versuchen), ... Es ist einfach interessant... Es ist interessant, eines Tages das "System" zu betrügen (oder besser gesagt NICHT zu betrügen)... Deshalb bin ich hier (auf dem Markt, bedingt), und ich hoffe, dass ich nicht nur für mich selbst, sondern auch für die Öffentlichkeit von Nutzen bin. Denn wie Miroslav - ein Altruist im Leben.


Meine derzeitige Meinung ist, dass die technischen Analysesysteme, die derzeit auf der ganzen Welt verwendet werden (und das ist die klare Mehrheit), in der Tat am Markt beteiligt sind. Das heißt, die Menschenmenge, die auf ihre Monitore schaut und sich von den Werten ihrer Indikatoren leiten lässt, erwartet einvernehmlich eine Bewegung in eine bestimmte Richtung, macht Geschäfte ... und bewegt genau diesen Preis. Wenn auch nur in geringem Umfang, wenn auch nicht immer (es gibt immer noch Besitzer von "Fabriken, Zeitungen, Dampfschiffen", die sich einen Dreck um TA scheren, sie müssen nur eine bestimmte Menge zu einer bestimmten Zeit kaufen oder verkaufen). Aber es passiert! Mit anderen Worten: Wenn Sie "in the loop" (d.h. in der gleichen TA) sind, können Sie versuchen, die Wahrscheinlichkeit positiver Zufallsbewegungen auf dem Markt auf (etwas?) mehr als 50% zu erhöhen. Es ist nicht einfach... ABER möglich! Sobald ich von diesem Postulat enttäuscht bin, werde ich den Markt verlassen... (und es wird nicht um die Höhe der Gewinne/Verluste gehen, es ist einfach, nun ja, wirklich frustrierend und sinnlos, in einem völlig zufälligen System zu arbeiten... na ja, siehe oben)

 

Also, jetzt zum Geschäftlichen.

1. Während hier eine Flaute herrschte, habe ich nachgedacht. Ja, wir können auf Miroslav warten (wenn er entweder eine Brücke zwischen MT und FSB oder hier einen Strategie-Compiler erstellt). Aber am Ende - wer wenigstens selbst etwas tut, bekommt das Ergebnis :). Ich bin von der Annahme ausgegangen, dass ich (garantiert) ein bestimmtes Werkzeug habe (FSB), ich habe MT, gehen wir davon aus, dass es außer diesen beiden Einheiten nichts anderes geben wird - also operieren wir in ihrem Rahmen, nämlich: FSB (im Moment) ist ein geschlossenes System; wir werden MT sowieso brauchen; der Code des Advisors (Handelsroboter) wird auf jeden Fall benötigt - ja, es sollte eine universelle Vorlage geben, die (grob) Werte von Indikatoren und allem gibt, dann nach "genehmigtem Schema"; so werden wir Indikatoren selbst brauchen.


2. Ich werde gleich bei dem Code des Expert Advisors aufhören. Ich teile nicht den Optimismus der Schöpfer von einfachen Expert Advisors - nun, es ist unmöglich, die Anzahl der anormalen Situationen im Terminal und Markt vorstellen. Und es geht um Geld, da sind keine Witze angebracht (sie haben den Fehlercode nicht überprüft - sie haben irgendeine Standardaktion berechnet... und das war's, -$1000 sind (bedingt) weg). Das heißt, ich bin davon überzeugt, dass jeder Experte, der sich wirklich mit Geld (oder besser mit echtem Geld) beschäftigt, "eisenfest" sein muss, was die Reaktionen auf externe Ereignisse angeht. Der Code muss eine maximale Anzahl von Variationen des Terminals, des Servers oder des Marktes selbst vorsehen. Kurz gesagt - es ist ziemlich ernst, und kann nicht mit einem Sprung gelöst (geschrieben) werden. Ich würde mich gerne an der Erstellung solcher Muster beteiligen. Aber...


3. Ich habe beschlossen, ganz von unten anzufangen. Ich hatte einen Gedanken - wenn es für einen Expert Advisor nichts gibt, womit man arbeiten kann (Indikatoren) - wozu brauchen wir dann überhaupt einen Expert Advisor :)! Also habe ich die Indikatoren genommen.

Die Prämisse lautete wie folgt. Erstens kann niemand garantieren, dass die Werte der FSB-Indikatoren den Werten der Standard- oder Zusatzindikatoren in MT entsprechen. Und um "vergleichbare" Ergebnisse in beiden Programmen zu erhalten, sollten die Werte gleich sein. Zweitens: Die Anzahl der Indikatoren selbst (Standard) ist IMMER unterschiedlich. Und zur Verwendung (und Suche) von externen... Irgendwie mag ich entweder den Standard oder meinen eigenen (im Leben)... (Drittens - ich habe den Eindruck, dass die "Konvertierung" des Indikatorcodes von FSB keine so große Aufgabe ist, wie Miroslav erwähnte - die Algorithmen selbst sind recht einfach, die Indikatoren selbst sind in Bezug auf den Code sehr "organisiert" (der Code ist einheitlich), d.h. grob gesagt - sie erzeugen eine Reihe von Fehlern.Grob gesagt, erstellen wir einmal eine Vorlage und "füllen" sie nach und nach mit einigen Indizes (das ist das ideale Bild der Welt :))). Im vierten Teil gibt es noch mehr - ich habe mich schon gewundert :).

Jedenfalls war das Wochenende genau das. Bevor ich etwas anfange, nehme ich mir normalerweise viel Zeit, um es zu nutzen" (in diesem Fall: zu denken). Ich habe keine Zeit, die Vorlage selbst zu ändern (ich verstehe das). Vor allem, wenn die Anzahl der Indikatoren eine bestimmte Zahl überschreitet. Daher sollten die wichtigsten Punkte sofort entworfen werden. Daher habe ich die folgenden Annahmen getroffen:


- Diese sollten Indikatoren sein (und nicht nur Funktionen für den zukünftigen Code des Expert Advisors). Schließlich spielt die visuelle Wahrnehmung von Informationen für den Menschen (und insbesondere für mich) nicht die geringste Rolle, und der Aufruf eines Indikators aus dem Expert Advisor Code ist kein so großes Problem (der iCustom hat im Forum schon für viel Ärger gesorgt - wenn es so viele Meinungen gibt, ziehe ich es in der Regel vor, alles selbst zu überprüfen, die Ergebnisse meiner "Feldtests" reichen aus, es gibt wahrscheinlich einen kleinen Overhead, aber ist KEINE große (das erkläre ich mit voller Verantwortung) und ich denke, dass es im Hinblick auf die Universalität vernachlässigt werden kann). Aber für die "besonderen Genießer" :) (nur für den Fall), dass die Berechnungen in Indikatoren in einer separaten Funktion desselben Typs durchgeführt werden (siehe unten).


- Die Indikatoren müssen die gleichen Werte wie in der ursprünglichen FSB ausgeben (separat ausgehandelter Punkt unten). D.h. der Code von FSB wird als Grundlage genommen und möglichst wenig verändert.


- Der Code sollte so optimiert werden, dass er mit IndicatorCounted korrekt funktioniert (d.h. durch Geschwindigkeit)


- Die Indikatorparameter sowie ihre Werte müssen einheitlich und homogen sein. Ich spreche nicht von Datentypen als solchen. Wenn Sie sich den Code der Indikatoren von Miroslav ansehen, können Sie eine gute Homogenität der Eingangsparameter und Ausgangspuffer erkennen. Die Aufgabe besteht darin, das ursprüngliche Bild beizubehalten, damit die Benutzer bei der Angabe von Parametern oder der Übernahme von Indikatorwerten leicht geführt werden können.

- Die Schlussfolgerung aus dem vorhergehenden Punkt ist ... mm (Achtung - dies ist wichtig). Das Wichtigste bei der Verwendung aller Indikatoren ist nicht, dass sie eigene Werte erzeugen. Es geht darum, dass sie SIGNALE produzieren! Wirklich, für mich als Person - welchen Unterschied macht es, welchen Wert ein Index jetzt oder später(?!) hat, es sind immer noch "unverständliche Zahlen". Verständlich ist, wenn es entweder 'Kaufen' oder 'Verkaufen' heißt :). Alles andere ist "unklar"! Miroslav hat diese Idee sehr elegant umgesetzt, indem er zwei Puffer in jedem Indikator (für Long- und Short-Positionen) erstellt hat, die, je nachdem, wie der Indikator verwendet wird (als Punkt der Positions- oder Logikbedingung), entweder Werte für das Öffnen/Schließen einer Position oder des Ja/Nein-Filters erhalten (wenn alle "Ja" in der Eröffnungslogik - öffnen, wenn mindestens ein "Nein" in der Schließungslogik - schließen (im Allgemeinen RTFM). Genial! ;) Ich bin diesen Weg gegangen und habe dieses Verhalten simuliert. Im Moment sind die ersten beiden Puffer des Indikators (deren Werte im Datenfenster zu sehen sind) die entsprechenden Puffer mit Filtern (1/0) oder Preiswerten, um Positionen auf der Long- bzw. Short-Seite zu eröffnen, d.h. Später, wenn die Indikatoren im Code des Expert Advisors verwendet werden, ist es egal, was, wo oder welche Werte ein bestimmter Indikator generiert - es werden nur die Werte der ersten beiden Puffer für ein sehr einfaches Thema analysiert (Ja/Nein (bedingt) oder direkte Übernahme des Preises von dort) ... Und das war's! Es gibt eine Nuance - fast 100% "wird stolpern" auf Ishimoku (dort, die Menge der Indikator eigenen Puffer ist in der Nähe der Grenze von MT selbst (8)) - Ich möchte eine schöne Idee (mit den ersten beiden Puffern) nicht ablehnen, aber ich kann sie nicht in einem kombinieren (ich dachte... es könnte nicht nur 1/0 (das in eine Bitmaske umgewandelt werden könnte), sondern auch Preisschilder geben). Wahrscheinlich werde ich etwas mit den Indikatorwerten selbst machen müssen... Wir werden sehen... Und weiter geht's...

 

Generell kurz (Auszüge): Qualität (FSB-Kompatibilität, Fehlerfreiheit etc.), einfache Weiterverwendbarkeit, Schnelligkeit, Lesbarkeit des Codes. In dieser Reihenfolge.

Nun, und (eigentlich) - was ist passiert ... (kurze Geschichte)

- Alle Indikatoren haben den Wert "fsb" im Dateinamenpräfix (Beispiel: "fsbBlaBlaBla.mq4").


- Ich habe die Indikatoren selbst in einer pseudozufälligen Reihenfolge genommen, also beschuldigen Sie mich nicht. Bisher gibt es, das ist. Für weitere Diskussionen/Analysen etc. - Ich denke das ist genug.


- Miroslav verwendet drei externe Funktionen (die in den Quellen (ganz unten auf der Seite) platziert sind), um den gleitenden Durchschnitt und die Werte logischer Puffer zu berechnen. Ich musste mit ihnen anfangen. Alle Funktionen sind in einer Datei verpackt (" fsbCommon.mq4 "), angeordnet als Bibliotheksfunktionen (" fsbCommon.mqh "). Es gibt eine weitere Datei aus dieser Oper (" fsbConstants.mq4 "), die jeweils Konstanten zur Vereinfachung im Code enthält. Es gab keine besonderen Probleme mit den Funktionen selbst (ich habe die anfängliche Logik der "Logik-Oszillatoren" etwas komplizierter gemacht, für zusätzliche Überprüfungen (out-of-bounds-Arrays, garantiert korrekte Anfangswerte (die ersten in der Geschichte) (Miroslav, es gibt eine logischer Fehler im Code zu diesem Thema).. .und habe lange versucht, das Verhalten von iShift in MovingAverage zu "emulieren", damit die Funktion die Werte des resultierenden Puffers für jeden vernünftigen Wert dieses Parameters korrekt ausfüllt (und nicht nur für die Einschränkungen, die im ursprünglichen Originalcode angegeben sind) ... daher habe ich diese Angelegenheit vorerst aufgegeben und einen "Stub" am Anfang gesetzt (mit iShift anders als "0" funktioniert die Funktion nicht Arbeit, die aber noch nicht nötig war)). MovingAverage hat sich als umständlich erwiesen, aber es schlägt mehrere Fliegen mit einer Klappe. Da es nicht möglich ist, den Puffer aus der Funktion als Wert in MT zurückzugeben (evtl notwendig) - am Ende erschien ein zusätzlicher Parameter ( afTarget ) Auch unter Berücksichtigung von IndicatorCounted () ein weiterer Schritt Der Parameter ist für den Wert des ersten Balkens für die Verarbeitung verantwortlich. Nun, der letzte zusätzliche Parameter legt die "Preiskonstante" in Bezug auf MT fest, anhand deren Wert die Werte des MovingAverage selbst basierend auf den vorhandenen Arrays von Serien berechnet werden, oder (falls der Wert iAppliedPrice außerhalb der Werte von "Preiskonstanten" MT) - basierend auf afQuelle . (daher die Überladung des Codes) Ich werde sofort die Nuance der Programmierung spezifizieren - wo es Zyklen gibt, die mit Auswahlen nach Fall durchsetzt sind - die Zyklen werden in die Auswahlen eingefügt und nicht (was normalerweise logischer ist) umgekehrt. Nicht weil ich nicht weiß wie es richtig geht - sondern weil ich weiß wie schnell :)! (Nun, ich werde in Zukunft nicht weiter darauf eingehen, wer auch immer den Code analysieren möchte - gerne geschehen, aber bevor Sie die Frage "zur Dummheit des Codes" stellen, denken Sie ein wenig darüber nach, was (möglicherweise) so etwas verursachen könnte Programmierung).


Eine weitere Nuance hängt mit MovingAverage zusammen (es kann für jemanden informativ sein) - weil. Gleitende Durchschnittswerte in exponentiellen Glättungsmodi (einschließlich Smoothed) hängen direkt von ihren eigenen vorherigen Werten ab - die Wahl des "Startpunkts" wird sehr wichtig (welcher Wert als Grundlage für weitere Berechnungen genommen werden soll). Dazu gibt es in der Regel mehrere Ansätze. Jemand nimmt den Schlusskurs der Vorperiode. Jemand hat den Preis für die vorangegangene Periode N gemittelt... Miroslav ging den zweiten Weg. MT steht eindeutig an erster Stelle. Daher die erheblichen Abweichungen in diesen beiden Glättungsmodi am Anfang des Diagramms (ich habe ein Leerzeichen zum Testen von MovingAverage und allem anderen hinzugefügt (" fsbTest.mq4 "))! Und die von mir innerhalb der Funktion auferlegten Einschränkungen für die Verfügbarkeit von Daten des MovingAverage selbst VOR iFirstBar oder eine ähnliche Menge berechneter Werte GEMÄSS iFirst-Leiste. weil Die Indikatoren selbst verwenden eine Konstante für den Mindestwert der Balken im Diagramm (jetzt 2000) - dies sollte für jede Situation ausreichen (weil ich noch keine Parameter mit Perioden größer als 200 gesehen habe). Es sei denn natürlich, es wird mehr als ein MA gleichzeitig verwendet ;).


- Analog zum vorherigen Absatz wurden Dateien für externe Unterfunktionen erstellt, die ich bereits in meiner Arbeit mit diesem Projekt verwende (Präfix "st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")


- Nun, eigentlich - die Indikatoren selbst. Ganz kurz (Nehmen wir als Beispiel „ Bar Range “):

 //extern int slotType = SLOT_TYPE_LC;

extern int indLogic = INDICATOR_RISES ;    // (INDICATOR_RISES <= indLogic <= INDICATOR_LOWER_LL)

extern int nBalken = 1 ;                  // 1 <= nBalken <= 200

extern int fLevel = 0 ;                  // 0 <= fLevel <= 500

extern bool iPrvs = True ;                // Wahr falsch

slotType setzt Typ Schlüssel in FSB- Begriffe (Punkt der Position oder logische Bedingung) . Diese Indikatoren, die nicht nur Ein-/Ausstiegsfilter sein können, sondern auch den Eröffnungs-/Schlusskurs festlegen – dieser Parameter bestimmt genau, was der Indikator in seinen Logikpuffern generiert. Siehe alle Konstanten in fsbConstants.mq4 (da ist alles ganz klar)

indLogic - tatsächlich eine logische Bedingung für den Indikator (trägt eine unterschiedliche semantische Last, je nach Wert Steckplatztyp )

Nun, die Parameter gehen noch weiter, in der Reihenfolge, in der sie in den Indikatorquellen auf forexsb.com erscheinen, und wie sie im FSB selbst angezeigt werden. Parametergrenzen werden in den Kommentaren angegeben und beim Aufruf von init() durch Aufruf der Unterfunktion PCheck() gesteuert.

 double LPIndBuffer [];            // Long-Positionen #1

double SPIndBuffer [];            // Short-Positionen #2



doubleIndBuffer [ ];              // Werte des Indikators #3



doubleIndBufferDD [ ];            // Zusätzlicher Puffer für Zeichnung Nr. 4

doubleIndBufferDU [ ];            // Zusätzlicher Puffer für Zeichnung Nr. 5

Bei Puffern wird alles auf globaler Ebene als Indikatorpuffer verwendet (an den Indikator selbst angehängt). Nur die gewünschten logischen Einsen (LPIndBuffer[], SPIndBuffer[]) (immer und immer in dieser Reihenfolge (#0 - Long-Positionen, #1 - Short-Positionen)), IndBuffer[] - Daten des Indikators selbst. Da in diesem Fall jedoch ein Farbhistogramm verwendet wird, trägt dieser Puffer nur die Werte selbst, und zwei zusätzliche Puffer werden für die Farbwiedergabe verwendet (um ehrlich zu sein, MT hat mit der Programmierung nur durch das Übertragen von Indikatoren begonnen :), und wie können Sie ansonsten das Verhalten von Farbhistogrammen innerhalb von MT simulieren - ich bin nie darauf gekommen (wer kann das sagen? Wenn das überhaupt möglich ist)). Sie werden in keiner Weise in DataWindow angezeigt.

BEIM drin() alles ist wie gewohnt (Parameterwerte werden überprüft, die Namen des Indikators selbst und Indizes werden gesetzt, Puffer werden angehängt usw.)


In deinit() denke ich darüber nach, Logik einzufügen, falls der Indikator NICHT geschlossen wird (zusätzlicher Komfort, damit die Parameter dort nicht zurückgesetzt werden usw.), in meiner Freizeit (noch keine Priorität).


Anfang() sehr primitiv. Seine Aufgabe besteht darin, zu überprüfen, ob genügend Balken auf dem Diagramm vorhanden sind (um einen beliebigen MA und im Allgemeinen zu berechnen) und die Funktion zur Berechnung des Indikators selbst aufzurufen, bei deren erfolgreichem Aufruf das benutzerdefinierte Zeichnen des Indikators aufgerufen wird (falls erforderlich). irgendwie auf besondere Weise gezeichnet werden, wie in diesem Fall als -einmal)


Berechnung() - tatsächliche Berechnungen. Der Code ist im Allgemeinen dem Code von Miroslav ähnlich, Ausnahmen werden für Optimierungen im Zusammenhang mit IndicatorCounted() gemacht. Wenn zusätzliche Indikatorpuffer benötigt werden, um den Indikator zu berechnen, werden sie innerhalb der Funktion selbst gesetzt (statisch) (um die Indizes des Indikators selbst nicht zu verschwenden) und werden von der Funktion BufferSync() bedient. Hier ist ein separater Witz - ursprünglich wurde versucht, die Berechnungen durch einen weiteren konstanten Parameter (iMaxBars) einzuschränken. "Feldversuche" (Teil 2) zum Verhalten von Arrays von Reihen bei Anwesenheit von Geschichte, Abwesenheit, Bewegung in die Zukunft (Ankunft von Zitaten, Erhöhung von Arrays nach RECHTS (ich bin jetzt visuell, über die grafische Darstellung )), ... Bewegung in die Vergangenheit (wenn die Historie fehlt (wir bewegen uns auf der Karte nach links) und das Terminal sie vom Server lädt ... und die Arrays nach LINKS erweitert werden) ... Also. .. Abgebrochen. Ich habe es schön gemacht (versucht es zu tun) - je nach Richtung der Erweiterung BufferSync() und erweitert das Array resp. nach links oder rechts und füllen Sie die leeren EMPTY_VALUE-Werte aus. Hier nur selbst erweitert MT normalerweise keine Index-Arrays nach LINKS. Er erweitert sie IMMER nach rechts (von der Seite von [0] Bar). Ich hoffe, es ist klar, wovon ich spreche – dass beim nächsten Sprung zurück in die Geschichte, wenn der Wert der Balken auf dem Chart iMaxBars überschreitet (durch erneutes Springen) – Situationen durchaus möglich sind, in denen der Indikator seine Werte nicht zeichnet Links von iMaxBars, aber hier sind "seltsame Daten" drin, die links von iMaxBars leicht sein können. Vielleicht wird sie niemand sehen ... Aber "nicht schön" (nicht unsere Methode). Und alles, was benötigt wird, ist, dass MT selbst die Puffer mit leeren Werten in die richtige Richtung ergänzt ... Es ist möglicherweise möglich, eine solche Situation abzufangen, aber ... Im Allgemeinen zeichnen wir von Anfang an die Diagramm ... _immer_. (Nun, soweit es für diesen bestimmten Indikator möglich ist)


Eine weitere Nuance ist mit IndicatorCounted() verbunden - so scheint es - eine göttliche Funktion. Geben Sie die Werte der berechneten Balken zurück und es entstehen keine Ansprüche gegen Sie ... WERDEN! Ich denke, es ist nicht der IndicatorCounted() selbst schuld (wie auch die Programmierer von MQ), sondern ein Haufen benutzerdefinierter Indikatorprogrammierer, die den göttlichen Zweck dieser Funktion nicht erreicht haben. Daher ist es gezwungen, immer eine kleine Anzahl potenzieller Werte zurückzugeben. Entweder berechnen wir den gesamten Chart neu (IndicatorCounted() == 0) oder den ersten ((IndicatorCounted() == Bars - 1) oder zwei (IndicatorCounted() == Bars - 2) Bars. zum Beispiel, wenn die Verbindung unterbrochen ist und der Chart mehr als einen Balken voraus "lief" - das ist alles ... "Bäume starben stehend" (IndicatorCounted() == 0) - wir zählen den ganzen Chart auf ein neues Warum? war es unmöglich, die Anzahl der übersprungenen Takte (3, 4, ... 5 ... 10 ...) zurückzugeben? (wofür diese Funktion, wie ich es verstehe, ursprünglich gedacht war) Im Allgemeinen so. ..

... bin ich über den RSI "gestolpert". Und das in jeder Hinsicht. Erstens habe ich Miroslavs Code nicht verstanden (Fragen an ihn werden weiter unten behandelt). Zweitens habe ich beim Testen des Indikators Diskrepanzen in den in MT und FSB erhaltenen Werten festgestellt! Nein, es ist überhaupt nicht das, was Sie dachten ("krumm ertragen" - naja, geben Sie es zu, Sie dachten ;)). Der Punkt scheint leider in diesen Erklärungen zu liegen:

 Float [] afPos = Neu Schwimmer [ Balken ];

...

Schwimmsumme ; _

...

Kurz gesagt - schweben ! Nach kurzem Nachdenken bremste ich vorerst ab. die allererste These (Genauigkeit und Qualität) ist fraglich geworden (und es ist eine Priorität).


Folgende Überlegung ist hier möglich: Einerseits ist Float nicht schlecht, es ist sozusagen eine „Aufrauhung“ der Indikatorwerte, was die Handelsstrategie noch unanfälliger für zufällige Marktspitzen machen soll. Auf der anderen Seite, zum Beispiel, wenn Sie fLevel (zum Beispiel 1,0) überschreiten, werden Sie zustimmen: 0,99998 und 1,00001 sind zwei große Unterschiede :). Und solche Abweichungen gibt es. Und wenn sich die Pose in diesem und jenem Moment öffnet, aber der FSB-Pegel tatsächlich immer noch nicht 1,0 erreicht und abfällt, wer ist dann schuld? (derjenige, der die Indikatoren übertragen hat :D?!)


Es gibt tatsächlich zwei Lösungen (da Float MT nicht unterstützt wird!):


- emulieren Sie einen Float im MT selbst (mit einigen herzzerreißenden Konstruktionen wie NormalizeDouble(X, Digits + 2) ) - naja, nicht überall, aber bedenken Sie, dass jede Multiplikation / Division mit jeder möglich ist


- Float im FSB auf Double ändern. Hier müssen Sie den Umfang der Änderungen verstehen, der offensichtlich endlich ist, aber Sie müssen überall vorsichtig vorgehen. Und dass das potenzielle Ergebnis der generierten Strategien im Menschen „schweben“ kann. Und im Allgemeinen braucht Miroslav es? (Meine bescheidene Meinung ist, dass der FSB das selbst braucht, weil extra Präzision noch niemandem geschadet hat, aber bei der Rechengeschwindigkeit (wenn dieses Ziel verfolgt wurde (?), denn ich sehe keine Gründe mehr) in diesem Zeitabschnitt der Realität Es sollte keine signifikanten Auswirkungen haben.) Ich stimme in dieser Frage mit den Jungs von MQ überein - weil. Wenn wir nicht mit ganzzahliger Mathematik (etwas Dezimalzahl) arbeiten, werden wir es zumindest mit der maximal möglichen Genauigkeit versuchen. Im Allgemeinen ist hier so eine ... keine leichte Frage ...

 

Entschuldigen Sie, dass ich so ausführlich bin (ich werde nicht mehr sagen, nur noch das Wesentliche).


Ich würde gerne eine Meinung hören - sollte dieses Thema fortgesetzt werden (und dann weiter "gehen", den Rest der Indikatoren zu durchforsten)? Ich kann sogar in irgendeiner Reihenfolge (da alle gleich das ursprüngliche Chaos :)), die, vielleicht, was braucht, um vorwärts zu gehen. Die Zeit ist leider in der Regel knapp bemessen (stellvertretender Generaldirektor in seinem Büro - "der Tag vergeht unbemerkt" :D). Ich finde die Zeit meist abends, aber ein oder zwei Indikatoren pro Tag kann ich wohl liefern...



Also, Fragen an Miroslav zu diesem Thema...

1. Wie hoch ist der Wert von fMicron? (Ich habe ihn (nach reiflicher Überlegung) auf 0,000001 gesetzt, oder ist er noch kleiner?


2. Wie lautet der Parameter bIsDescreteValues (in der Oszillatorlogik). Ich verstehe, was das bedeutet - aber was ist der Standardwert? Und von welchen Bedingungen hängt die Veränderung ab? (oder sagen wir - worauf bezieht es sich (in der FSB-Schnittstelle oder wo auch immer))


3. Was ist eigentlich RSI, was ist das für ein Design?

for (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

}

:)? Der Grund für diese Frage ist folgender: Wenn ich das richtig sehe, handelt es sich um einen geglätteten MA. Im Kontext des gesamten Codes wird er auf bereits berechnete MA angewendet und erzeugt geglättete MA, bei denen nur der erste Wert "lebendig" bleibt :). Eine Art logische Frage - was ist hier überflüssig? Diese Konstruktion, die unter anderem REALIZED(!) Wahl der RSI Glättung Modi in den Indikator selbst (es stellt sich heraus, immer geglättet), und in seiner abhängigen macht. Oder frühere MA-Berechnungen (mit korrektem Modus aus Parametern) für afPos, afNeg?


Der klassische RSI basiert natürlich auf dem geglätteten Durchschnitt. Aber es gibt zumindest eine Variante mit Simple MA und es wäre logisch, den obigen Code zu entfernen, um das Verhalten der maMethod-Parameter funktionsfähig zu machen. Oder wir entfernen die MA-Berechnung vor diesem Zyklus und entfernen die MA-RSI-Parameter in allen Indikatoren (da sie ohnehin keine Auswirkungen haben!).


Ich würde diesen Code (oben) entfernen :). (Im konvertierten Indikator ist dieser Teil kommentiert, wer die ursprüngliche Funktionalität benötigt - entfernen Sie die Kommentar-Tags! Der RSI-Code dient nur als Referenz... Bis wir hier eine Entscheidung getroffen haben, würde ich es "auf eigene Gefahr" verwenden :))


4. Wie bereits gesagt, gibt es einen unkritischen Logikfehler in der Oszillatorlogik im Verhalten bei den ersten Balken. Ich kann es jetzt nicht erkennen, ich werde es morgen aufschreiben (wo und wie man es korrigiert).


5. Was sollen wir mit Float in FSBmachen ? (oder mit dem Fehlen davon in MT) :)?


Das Archiv enthält die erforderlichen Dateien, die in das MT-Stammverzeichnis entpackt werden (das Archiv wird im nächsten Beitrag vorgestellt)


Viel Glück an alle... schreiben :)
 

Archiv der aktuellen Indikatoren (2009-04-15)

Dateien:
experts.rar  101 kb
 

Ich stimme zu, dass Schweben nicht funktioniert - wir müssen nach einem Ausweg suchen. Wir müssen die Korrespondenz schreiben. Erstellen Sie dann eine Bibliothek von Indikatoren. Wenn ich helfen kann, werde ich mich freuen.

1...505152535455565758596061626364...66
Neuer Kommentar
Grund der Beschwerde: