Diskussion zum Artikel "Automatenbasierte Programmierung als neue Herangehensweise an die Erstellung automatisierter Handelssysteme" - Seite 3

Neuer Kommentar
 
Rorschach:

"3. ich war neugierig und wollte das weiße Rauschen echter Zecken hören und konnte dies mit der Software WaveLab 6.0 tun."

Hee. Es stellt sich heraus, dass ich nicht der einzige Verrückte wie dieser bin))))) Hier ist mein Ergebnis. Ich habe es über Adobe Audience gemacht.

Wie haben Sie den Preis normalisiert?

Wie üblich, durch Abschneiden langer Schwänze, wobei alles, was über 3*sko hinausgeht, auf diesen Wert gebracht wird.
 

Eine Wagenladung voller Emotionen

1) Eine Menge bukaf nichts...

2) Wenn man sich das ansieht, wird einem klar, warum die Amerikaner jetzt auf dem Mars sind und nicht wir.

3) Über den Rest würde ich lieber schweigen (nur wegen der Emotionen).

 

Der Artikel hat mir gut gefallen, insbesondere die moderne Praxis der Programmentwicklung und -dokumentation. So ist das nun einmal.

Natürlich hätte der Artikel zumindest den einfachsten Expert Advisor zeigen sollen, der auf der Methode der Automaten basiert. Oder ist das für den nächsten Artikel geplant?

Und ein großes Problem der Automatenmethode ist meiner Meinung nach. Bei echten Expert Advisors ist es unmöglich, den Zustand eindeutig zu definieren. Der Zustand des Expert Advisors wird durch einige interne Variablen auf dem Computer des Benutzers und den Zustand der Positionen (aktueller Kurs, Eigenkapital, Ausführung der Aufträge) auf dem Server bestimmt. Der interne Zustand ist eindeutig bestimmt, aber der Zustand der Positionen auf dem Server kann unbekannt sein, mit einer Verzögerung bekannt sein, sich in einem unklaren Zustand befinden (einige Aufträge und Anfragen werden ausgeführt, andere nicht, und die Hölle weiß warum).

Und da der aktuelle Zustand des Beraters nicht bekannt ist, Aufträge und Anfragen nicht ausgeführt werden, ist es unmöglich, eine klare Automatenlogik zu erstellen. In Wirklichkeit erhalten wir diesen Algorithmus:

comp: Kauf mir ein paar hundert Euro, Server.

Server: Fick dich, Comp, deine Stopps in der Anfrage sind falsch.

comp: Warum sind sie falsch?

Server: Der Preis ist gesprungen.

Comp: Gut, dann kaufe ohne Stopps.

Server schweigt

Vergleicher: Und was haben Sie gekauft?

Server schweigt

comp: na ja, leck mich doch. Lass uns acht Minuten lang ein Nickerchen machen.

Comp in acht Minuten: Wie läuft's?

Server: Ich habe Eurobucks gekauft, aber während ich kaufte, ging der Preis woanders hin.

Comp: Scheiß drauf. Machen wir noch ein Stundennickerchen.

Und so weiter.

 
Die Evolution dreht sich im Kreis - es ist an der Zeit, zu (un)endlichen Automaten zurückzukehren, dann werden wir Turing-Maschinen bauen.
 
Virty:

...

Und ein großes Problem der Automatenmethode, meiner Meinung nach. Für echte Expert Advisors ist es unmöglich, den Zustand eindeutig zu definieren. Der Zustand des Expert Advisors wird durch einige interne Variablen auf dem Computer des Benutzers und den Zustand der Positionen (aktueller Kurs, Eigenkapital, Ausführung der Aufträge) auf dem Server bestimmt. Der interne Zustand ist eindeutig bestimmt, aber der Zustand der Positionen auf dem Server kann nicht bekannt sein, mit einer Verzögerung bekannt sein, in einem unklaren Zustand sein (einige Aufträge und Anfragen werden ausgeführt, und einige nicht, und die Hölle weiß warum).

Nun, da der aktuelle Zustand des EA nicht bekannt ist, Aufträge und Anfragen nicht ausgeführt werden, ist es unmöglich, eine klare Automatenlogik aufzubauen.

...

Das ist etwas Neues. Gerade JEDER (ausnahmslos) TS ist auf der Analyse und dem klaren Verständnis der TS-Zustände aufgebaut. Die einfachsten Zustände: Verarbeitung von Signalen zur Eröffnung/Schließung/Änderung einer Order, etc. etc.

Wenn "der aktuelle Zustand des EA nicht klar bekannt ist", dann handelt es sich definitiv nicht um einen EA und definitiv nicht um ein Programm, und das Wort "Algorithmus" in Bezug auf einen EA sollte für immer gestrichen und vergessen werden.

 

Eine Menge Emotionen.

Nun gut, ich schlage vor, die Diskussion in eine praktische Richtung zu lenken. Lassen Sie uns einen konkreten Algorithmus analysieren, der auf der Theorie der endlichen Automaten basiert. Lassen Sie uns seine Stärken und Schwächen diskutieren. Da ich selbst nicht nach dieser Methode schreibe, aber mit der Fragestellung und den Algorithmen ein wenig vertraut bin, werde ich nun das allgemeine Prinzip dieser Steuerung skizzieren:

//СХЕМА + ПСВЕДОКОД
enum eTradeState {NoTradeRegim, BuyRegim, SellRegim, WaitRegim};
eTradeState TradeState = eTradeState.NoTradeRegim;
int Trade()
{
   switch (TradeState)
   {
       case eTradeState.NoTradeRegim:
          NoTradeRegim();
          break;
       case eTradeState.WaitRegim:
          WaitRegim();
          break;
       case eTradeState.SellRegim:
          SellRegim();
          break;
       case eTradeState.BuyRegim:
          BuyRegim();
          break;
   }
}
//Hier beschreiben wir die Bedingungen, unter denen der Expert Advisor mit dem Handel beginnen soll. Zum Beispiel
void NoTradeRgim()
{
   //Weiterer Pseudocode folgt. 
   if(CurrentDay == WorksDays && Market.Enable = true)
      TradeState = eTradeState.WaitRegim;
}
//Hier fangen wir Signale ab, um eine Long- oder Short-Position einzugehen.
void WaitRegim()
{
   if(CheckForNoTrade() == true)
   {
      TradeState = eTradeState.NoTradeRegim;
   }
   if(CheckForBuy() == true)
   {
      BuyAtStop(...)
      TradeState = eTradeState.BuyRegim;
   }
   if(CheckForSell() == true)
   {
      SellAtStop(...);
      TradeState = eTradeState.SellRegim;
   }
}
//In dieser Funktion begleiten wir ein langes Geschäft
void BuyRegim()
{
   //Schreiben Sie hier die Bedingungen, unter denen das Geschäft geschlossen wird oder sein Stop-Loss oder andere Parameter geändert werden, usw.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}
//In dieser Funktion begleiten wir einen kurzen Handel
void SellRegim()
{
   //Schreiben Sie hier die Bedingungen, unter denen das Geschäft geschlossen oder sein Stop-Loss verschoben wird, usw.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}

Schematisch beschrieben, aber ich denke, der Grundgedanke ist klar. Zu jedem Zeitpunkt hat der Expert Advisor nur einen Zustand (Nicht-Markt-Modus, Signal-Warte-Modus, Kauf-Modus, Verkaufs-Modus). In jedem Zustand gibt es einen bestimmten Satz von Aktionen und Bedingungen, unter denen der Übergang vom aktuellen Zustand in einen anderen erfolgt. Die Idee ist, dass wir jeden der Zustände klar kontrollieren und daher die interne Logik streng lokalisiert ist und solche logischen Fehler wie das Schließen einer nicht existierenden oder bereits geschlossenen Transaktion einfach nicht auftreten können.

Ich selbst schreibe nicht mit dieser Technik, da ich denke, dass sie nicht für alle Algorithmen geeignet ist. Aber dennoch löst sie einige Aufgaben besser als der klassische Ansatz.

Was denken die Experten darüber?

 
C-4:
...

Ich schreibe selbst nicht mit dieser Technik, ich denke, dass sie nicht für alle Algorithmen geeignet ist. Aber dennoch löst sie einige Probleme besser als der klassische Ansatz.

Was denken die Experten darüber?

Und darf ich fragen, was Sie mit dem Ausdruck "klassischer Ansatz" meinen?

Denn jeder hat sein eigenes Bild von der Realität.

 
Urain:

Darf ich Sie fragen, was Sie mit "klassischem Ansatz" meinen?

Denn jeder hat sein eigenes Bild von der Realität.

Ich habe mich wohl falsch ausgedrückt. Natürlich schreibt jeder auf seine eigene Art und Weise. Ich meinte die meisten Ansätze, bei denen der Zustand des Systems bei jedem Schritt nicht klar definiert ist. Er muss nicht nur während der Ausführung des Expert Advisors bestimmt werden. Das einfachste Beispiel ist der Code, der in einem Block OnTick() geschrieben wird. Es werden keine Modi analysiert. Die Wahl einer Lösung erfolgt auf der Grundlage von Blockverzweigungen if(...).
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
C-4:
Ich habe mich auf die meisten Ansätze bezogen , bei denen der Systemzustand bei jedem Schritt nicht klar definiert ist. Er muss zum Zeitpunkt der EA-Ausführung bestimmt werden.

Wenn der Zustand "nicht klar definiert" ist, wie können Sie dann definieren, was "nicht klar definiert" ist? Ist es im Falle der Arbeit mit Aufträgen/Positionen nicht notwendig, dass der EA bei jedem Tick weiß, in welchem Zustand er sich befindet? Oder befindet sich der EA bei jedem Tick in einem "undefinierten Zustand". Was für ein EA ist das, der nicht weiß, was er bei jedem Tick tun soll?

 

Der Artikel geht überhaupt nicht auf das Thema ein, außer dass es einen Schalter gibt. Es spielt keine Rolle, ob er existiert oder nicht, er kann durch if's geschaltet werden.

Als ich einmal einen EA schrieb, gab es ein sehr komplexes System mit Aufträgen. Ich musste es ernsthaft analysieren und eine Liste von Zuständen erstellen: keine Aufträge, ein schwebender Auftrag, ein Marktauftrag, zwei schwebende Aufträge, ein schwebender und ein Marktauftrag, usw. Nur auf diese Weise konnte ich das Problem lösen. Aber es hat sich herausgestellt, dass es ein so universelles, schnell umprogrammierbares Ding ist. Das wäre ein gutes Thema für einen Artikel.

1234567
Neuer Kommentar