Ist der Berater für das wirkliche Leben geeignet? - Seite 35

 
borilunad:

1) Normalisieren Sie alle Bedingungen und Maßnahmen;


Sie müssen auch die Partie normalisieren, wenn sie sich ändert und/oder berechnet wird. Was ist sonst noch möglich?
 
FOReignEXchange:

1) Sie müssen die Haltestellen normalisieren, wenn sie separat berechnet werden. Dies ist in der Hilfe beschrieben. Warum sollte man etwas normalisieren, das nicht normalisiert werden muss? Sie soll 150 Dezimalstellen betragen. Wenn es keine Auswirkungen hat, muss es nicht normalisiert werden. Hier ist zum Beispiel ein Code.

Warum sollten wir a und b normalisieren? Ich kann es nicht verstehen. Dies ist natürlich nur ein vereinfachtes Beispiel. Aber der Punkt ist, wenn Sie in Ihrem Code mit Mathematik zu tun haben, warum sollten Sie alles normalisieren? Nur die Spitzenwerte müssen normalisiert werden, wenn sie sich aus einer solchen Mathematik ergeben.

2) Ich habe die Bedingungen einige Male überprüft. Ich überprüfe es gerade. Vielleicht habe ich etwas übersehen.

3) In meinem Code treten nur 2 Fehler auf. Fehler 130 - falsche Stops und ungültige Parameter beim Löschen eines schwebenden Auftrags. Bei der ersten ist alles klar, und ich habe das Problem gelöst. Die deaktivierten Parameter für die Löschung ausstehender Aufträge sind ebenfalls eindeutig.

4) Wir haben keine Zeit, Positionen ohne SL und TP zu eröffnen, da wir den Mindestgewinn festlegen und er später nicht mehr festgelegt werden kann, da sich der Preis schnell bewegt. Die vierte Regel ist allem Anschein nach aus der Tatsache erwachsen, dass Positionen mit Stops bisher nicht über BROKO-Terminals eröffnet werden konnten. Jetzt können Sie das. Ich verstehe also den Sinn dieser Regel nicht.


Wie ich es sehe, wissen Sie es am besten...

Machen Sie so weiter, einschließlich des Fehlers bei den Stops und dem Entfernen des Anhängers, bis an die Zähne bewaffnet mit SL und TP, trotz der Wichtigkeit in unmittelbarer Nähe des Preises, und sehen Sie den Sinn in allem anderen nicht!

Die Zeit wird es zeigen und alles an seinen Platz setzen!

 
FOReignEXchange:

Sie müssen auch die Partie normalisieren, wenn sie sich ändert und/oder berechnet wird. Was können Sie sonst noch tun?

Ja, natürlich! Und alles, was mit Berechnungen zu sich schnell ändernden VC-Normen unter Marktbedingungen zu tun hat.
 
borilunad:


Wie ich es sehe, wissen Sie es am besten...

Halten Sie die gute Arbeit, einschließlich der Fehler in Stops und Entfernen des Pendels, bewaffnet bis an die Zähne mit SL und TP, trotz der Bedeutung in unmittelbarer Nähe zu den Preis, und nicht sehen, den Punkt in alles andere!

Die Zeit wird es zeigen und alles an seinen Platz bringen!


Die Hauptsache ist, dass der Code im wirklichen Leben funktioniert und reibungslos abläuft. Alles andere ist nicht wichtig.

Fault STOPPING aufgrund von Preisverfall. Fehler 130. Ein erneuter Versuch bringt alles wieder in Ordnung. Damit gibt es kein Problem. Im Protokoll sind keine Fehler mehr zu finden.

Wir müssen nur herausfinden, warum die Bedingungen für die Löschung von Aufträgen nicht erfüllt sind, und das ist alles. Die im Titel des Themas angekündigte Frage wird gelöst.

 

FOReignEXchange:

Die im Titel des Themas angekündigte Frage wäre damit erledigt.

Es würde auch eine Erhöhung der Kaution bedeuten, die gleiche wie im Tester)

Ich glaube nicht, dass es einen solchen Punkt auf der Karte gibt, an dem man getrost einen Take 11 und einen Stop 15 setzen kann und weiß, dass es zum Take geht.)

Kein Affe, kein Schließfach, Sie öffnen einzelne Positionen, so wie ich es verstehe.

Eine solche Regel gibt es nicht, vor allem nicht, wenn Sie bei der Eröffnung einer Kerze einsteigen. Dies ist Fantasie und Fiktion. Der Preis ist niemandem etwas schuldig. Es geht weder zurück, wo wir es geplant haben, noch vorwärts, weil wir es beschlossen haben. Egal, welcher Super-Duper-Indikator uns das anzeigt.

 
FOReignEXchange:


Die Hauptsache ist, dass der Code in der Praxis funktioniert und reibungslos abläuft. Alles andere ist unbedeutend.

Fehler REAL STOPS aufgrund von Preisveralterung. Fehler 130. Ein erneuter Versuch bringt alles wieder in Ordnung. Damit gibt es kein Problem. Im Protokoll sind keine Fehler mehr zu finden.

Wir müssen nur herausfinden, warum die Bedingungen für die Löschung von Aufträgen nicht erfüllt sind, und das ist alles. Die im Titel des Threads angekündigte Frage ist damit erledigt.


Entschuldigung, eine weitere Klarstellung! Alle sich ändernden Parameter sollten beim Start von MarketInfo() aufgefrischt werden.

Und der Beleg muss mindestens 20 auf 5 Ziffern betragen(Fehler 130).

Im Tester werden weder sie noch andere verändert, also vertraue ich zumindest auf die großartigen Testergebnisse.

 
borilunad:


Entschuldigung, eine weitere Klarstellung! Alle sich ändernden DC-Parameter sollten beim Start von MarketInfo() aufgefrischt werden.

Im Tester werden weder sie noch andere verändert, so dass ich den schönen Testergebnissen am wenigsten traue.


Welche Parameter? Nur Bid und Ask sollten geändert werden, und das ist alles. Auch MODEFREEZELEVEL ist das einzig Nützliche, was ich heute gehört habe. Nochmals vielen Dank.

Welche anderen DC-Parameter können sich ändern? eine minimale schrittweise Änderung des Preises, oder

Minimaler Stop-Loss/Stack-Profit-Level in Pips
oder
Anzahl der Stellen nach dem Dezimalpunkt im Symbol Preis
oder
Pip-Größe in der Kurswährung

Die Spanne kann variieren, obwohl ich sie beim Euro nie bemerkt habe. Wie wird sie sich auswirken? Unter meinen Bedingungen kann es nur die Möglichkeit betreffen, einen schwebenden Auftrag zu platzieren. Wenn

OrderOpenPrice()=Bid+MODE_SPREAD)= kleiner als der akzeptable Abstand, wird der Auftrag nicht eröffnet. Dessen bin ich mir bewusst. Aber wir haben nie solche Fehler gehabt.

 
FOReignEXchange:


Welche Parameter? Nur Bid und Ask sollten geändert werden, das ist alles. Auch MODEFREEZELEVEL ist das einzig Nützliche, was ich heute gehört habe. Ich danke Ihnen nochmals.

Welche anderen Parameter kann das DC ändern? Handelt es sich um einen Mindestschritt der Preisänderung oder

Minimal zulässiges Stop-Loss/Stake-Profit-Niveau in Pips
oder
Anzahl der Stellen nach dem Dezimalpunkt im Preis des Instruments
oder
Größe eines Pips in der Kurswährung

Die Spanne kann variieren, obwohl ich sie beim Euro nie bemerkt habe. Wie wird sie sich auswirken? Unter meinen Bedingungen kann es nur die Möglichkeit betreffen, einen schwebenden Auftrag zu platzieren. Wenn

OrderOpenPrice()=Bid+MODE_SPREAD)= kleiner als der akzeptable Abstand, wird der Auftrag nicht eröffnet. Dessen bin ich mir bewusst. Aber wir haben nie solche Fehler gehabt.


Siehe: https://docs.mql4.com/ru/constants/marketinfo beginnend mit Bid auf Ihr "nützliches" FritzLevel, ansteigend in Zeiten extremer Volatilität. Auch StopLevel usw.

Bid+Spread=Ask Es ist also besser, in diesem Fall gleich Ask zu verwenden, natürlich nur, wenn Ask auch durch MarketInfo() zu Beginn des Starts ausprobiert wird.

 

Tut mir leid, ich muss für eine Weile weg!

Ich habe z.B. am Anfang und nach der Veredelung der Partie, je nach MM:

  RefreshRates();
  ASK = NormalizeDouble(MarketInfo(Symbol(),MODE_ASK),Digits);
  BID = NormalizeDouble(MarketInfo(Symbol(),MODE_BID),Digits);
  double spread = NormalizeDouble(ASK-BID,Digits);
  StopLevel = NormalizeDouble(MarketInfo(Symbol(),MODE_STOPLEVEL),Digits);
  double step = NormalizeDouble(Step*Point,Digits);
  if(step < StopLevel) step = StopLevel;
Und dann alles andere...
 

Zu diesem Code habe ich folgendes geschrieben

if (//Условие//)
   {
   if (OrderSelect(ticket_sell,SELECT_BY_TICKET)==true)
      if (OrderType()==OP_SELLSTOP) 
         {
         Print ("Заморозка: ",MarketInfo (Symbol(), MODE_FREEZELEVEL),", Bid: ",Bid,", Open=",OrderOpenPrice());
         if (Bid<=(OrderOpenPrice()+4*Point)) 
            {
            Comment ("1");                         
            i=0;
            while (i<10)
               {
               if (i>0) Sleep(500);      
               RefreshRates(); OrderDelete(ticket_sell); 
               err=GetLastError();
               if (err==0)
                  {
                  ticket_sell=0; return;
                  }
               i++;
               }
            }
         }
   }

18:34:14 $505,000 EURUSD,M1: Freeze: 0, Bid: 1.3436, Open=1.3436
18:34:14 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:14 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:15 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:15 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:16 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
1834:16 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:17 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:17 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:18 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden
18:34:19 505 000 $ EURUSD,M1: Marktorder #26398219 kann nicht gelöscht werden

Sie ist 10 Mal gescheitert. So viele Male wie der i-Zyklus. In diesem Fall hatte sie einfach keine Zeit zum Löschen, weil der Geldkurs bereits dem Eröffnungskurs der Order entsprach. Dies ist das erste Mal, dass ich einen solchen Fall bemerke. Ich werde versuchen, eine andere zu finden. Das hier war ein Pluspunkt. Die Abweichung vom Signal im System betrug nur den Bruchteil einer Sekunde, keine große Sache. Ich glaube, es gibt noch einen weiteren Fall, ich werde ihn abwarten. Es gibt Zeiten, in denen 10-15 Sekunden lang keine Reaktion erfolgt.

Grund der Beschwerde: