Nützliche Tipps für Teilnehmer an den Meisterschaften - Seite 11

Neuer Kommentar
 
VNIK писал (а):

Entschuldigung für die indiskrete Frage an die Organisatoren der Meisterschaft:

Wie wird die Besteuerung des Preises gehandhabt (da der Betrag jedes Preises sehr hoch ist):

Muss jeder Preisträger seine eigene Steuer zahlen? (und in welchem Rhythmus?) Oder wird sie zentralisiert werden? (d.h. die Steuern sind bereits berücksichtigt?).

Es wäre eine Schande, die Hälfte des Preises für Steuern aufzugeben!

Ich stimme Ihnen zu, auch mir würde es leid tun, die Hälfte Ihres Gewinns abzugeben, um meine Steuern zu bezahlen...
Eigentlich ist es besser, gar nicht zu gewinnen, damit es einem nicht leid tut... .
 
VNIK:

Entschuldigung für die indiskrete Frage an die Organisatoren der Meisterschaft:

Wie wird die Besteuerung des Preises gehandhabt (da der Betrag jedes Preises sehr hoch ist):

Muss jeder Preisträger seine eigene Steuer zahlen? (und in welchem Rhythmus?) Oder wird sie zentralisiert werden? (d.h. die Steuern sind bereits berücksichtigt?).

Es wäre eine Schande, die Hälfte des Preises für Steuern aufzugeben!


Ja, die Preisträger zahlen ihre eigenen Steuern - das ist bei Preisen in der ganzen Welt üblich.
 
Es gibt keine Möglichkeit zu testen, ob dieses Schließen von Aufträgen immer korrekt funktionieren wird:
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      
      err=GetLastError();
      if (err==135 || err==138) RefreshRates();
   }
Die Frage ist: Wenn der Fehlercode nicht 135 oder 138 ist, gibt es dann eine Schleife? Wenn ja, wie kann dies vermieden werden, und wie kann gewährleistet werden, dass die Aufträge geschlossen werden?
 
MAEstro:
Es gibt keine Möglichkeit zu testen, ob dieses Schließen von Aufträgen immer korrekt funktionieren wird:
Hier reiht sich Fehler an Fehler. Ich habe 4 Fehler gezählt und sie sind alle katastrophal.
Lesen Sie bitte noch einmal den Ratgeberartikel.
 
Ich kann diesen Rat auswendig, aber er scheint wenig zu nützen :(

Grobe Vernachlässigung der Fehlerkontrolle bei Schleifenbildung
(Ich habe Fehlerkontrolle, schwebende Aufträge werden nicht verwendet, oder sollte ich eine Schleife Exit-Bedingung als auch machen? Was ist dann mit der Auftragsabschlussgarantie zu tun? Oder habe ich vielleicht nicht alle Fehlercodes verarbeitet?

Fehlende Kontrolle über OrderSelect - asynchrone Prozesse in Aktion
(ja, ich prüfe nicht, was Order_Select zurückgibt! Nun, sagen wir, wenn in diesem speziellen Fall es falsch zurückgibt, was wird innerhalb der Schleife ändern, oder was wird falsch sein? Ich ändere die Bestellung nicht, ich schließe sie!)

Überspringen der Aktualisierungsfunktion der Marktumgebung durch RefreshRates()
(Ich glaube, ich habe es aktualisiert, hier sollte alles in Ordnung sein)

Vielleicht gibt es einen fertigen Code für die Schließung ALLER Aufträge? Ich würde es zu schätzen wissen, wenn Sie ihn veröffentlichen könnten!

P.S. Was Rosh vorschlägt http://www.alpari-idc.ru/ru/experts/articles/9.html , garantiert nicht, dass die Aufträge abgeschlossen werden!
 
Es gibt sogar 5 Fehler:
  1. OrderSelect-Ergebnis wird nicht geprüft
  2. das Ergebnis von OrderClose() wird nicht explizit geprüft
  3. GetLastError() kann ohne jegliche Handelsoperationen aufgerufen werden (z.B. wenn Sie auf einen schwebenden Auftrag gestoßen sind)
  4. RefreshRates() wird nicht immer aufgerufen, sondern nur, wenn ein Fehler auftritt - das ist ein grober Fehler
  5. wenn es in der Liste ausstehende Aufträge gibt, ist dies eine 100%-Schleife
Das Ergebnis: Es gibt 5 Fehler in 9 Zeilen - der Code kann nur verworfen werden.
 
Renat:
Sogar 5 Fehler:
  1. OrderSelect-Ergebnis wird nicht geprüft
  2. das Ergebnis von OrderClose() wird nicht explizit geprüft
  3. GetLastError() kann ohne jegliche Handelsoperationen aufgerufen werden (z.B. wenn Sie auf einen schwebenden Auftrag gestoßen sind)
  4. ...
Das Ergebnis: Es gibt 5 Fehler in 9 Zeilen - der Code kann nur verworfen werden.
Und warum alles in einen Experten für den Wettbewerb packen? Um das Protokoll zu lesen?
Der OrderSelect sollte die erforderlichen Aufträge auswählen und der OrderClose sollte sie schließen.
Und es sollten keine Fehler auftreten :-)
Oder auf Kosten des Auftraggebers :-)
 
Renat писал (а):
Es gibt sogar 5 Fehler:
  1. OrderSelect prüft das Ergebnis nicht
  2. explizit OrderClose()
  3. GetLastError() kann ohne Handelsoperationen aufgerufen werden (z.B. wenn eine schwebende Order angetroffen wird)
  4. RefreshRates() wird nicht immer aufgerufen, sondern nur bei Fehlschlägen - ein grober Fehler
  5. , wenn die Liste schwebende Orders enthält, dann 100% Schleifenbildung
Das Ergebnis: Es gibt 5 Fehler in 9 Zeilen - der Code kann nur verworfen werden.

Ziel: Abschluss aller Aufträge mit einer 100%igen Garantie
Beschränkungen: Schwebende Aufträge werden nicht verwendet

1. Warum sollten wir das Ergebnis überprüfen, wenn wir einen Auftrag abschließen müssen? Wenn er false zurückgibt, kehrt er im nächsten Durchgang dorthin zurück, da eine while-Schleife verwendet wird.
2. Siehe Punkt 1.
3. Zu diesem Zweck gibt es eine Prüfung auf Fehlercodes.
4. Wenn die Aktualisierung immer erfolgt, hat es keinen Sinn, nach Fehlern zu suchen :(
5. Keine ausstehenden Aufträge

Alle Beispiele für die Schließung von Aufträgen, die ich bei meiner Suche gefunden habe, sind Single-Pass-Verfahren und funktionieren nur, wenn mit dem Server alles in Ordnung ist, es keine Rückfragen gibt usw. Und sie alle führen dazu, dass eines Tages ein Auftrag nicht geschlossen wird und wir einen guten Gewinn erzielen... Wenn ich falsch liege, korrigieren Sie mich oder geben Sie mir einen Link, der mich vom Gegenteil überzeugt.

Natürlich bin ich mir bewusst, dass mein Code zu einer Schleife führen kann, aber das ist meiner Meinung nach besser als das Risiko, einen Auftrag nicht abzuschließen, was zu schweren finanziellen Verlusten führen könnte.
Obwohl es besser wäre, wenn alle Aufträge mit einer 100%igen Garantie abgeschlossen würden und es keine Chance gäbe, dass ein Auftrag herumliegt, ist dies der Code, den ich gerne von Ihnen hätte =)

Hier ist ein leicht geänderter Code, der sogar schwebende Aufträge berücksichtigen sollte:
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      else OrderDelete(OrderTicket());
      
      RefreshRates();
      err=GetLastError();
      if (err!=135 && err!=138 && err!=0) break;
   }

Sie ist nicht so "rücksichtslos" wie die vorherige?
Ich verstehe immer noch nicht, warum OrderSelect und OrderClose in diesem Fall überprüft werden?
 
Leider kann niemand Garantien für Handelsgeschäfte geben. Der obige Code ist viel besser als der vorherige.

OrderSelect muss immer angekreuzt sein, dies wird in den Nützlichen Tipps ausdrücklich erwähnt:
  • Fehlende Kontrolle über OrderSelect - asynchrone Prozesse in Aktion


    In der Regel nimmt ein Händler sein Programm als einzige Aufgabe wahr, die er zu erledigen hat. In der Realität gibt es jedoch viele asynchrone Änderungen im Handelskonto während des Betriebs des Expert Advisors: Positionen werden geändert, hinzugefügt und gelöscht. Wenn das Ergebnis jedes OrderSelect()-Aufrufs nicht kontrolliert wird, kann es passieren, dass der Experte zu einem bestimmten Zeitpunkt mit falschen (Null-)Daten arbeitet und einen falschen Zug macht.

 
Renat:
Leider gibt es keine Garantien für Handelsgeschäfte. Der obige Code ist viel besser als der vorherige.

OrderSelect muss immer angekreuzt sein, dies wird in den Nützlichen Tipps ausdrücklich erwähnt:
  • Keine Kontrolle über OrderSelect - asynchrone Prozesse in Aktion

    ... Positionen werden geändert, hinzugefügt und entfernt. ...

Angenommen, eine Position wird geändert. Es liegt eine Anfrage vor, einen Auftrag nach einer Bedingung auszuwählen. Es ist ein Fehler aufgetreten. Was könnte sich geändert haben? Die Ausgangsbedingungen sind beim nächsten Tick möglicherweise nicht mehr verfügbar, warum sollte ich also denselben Fehler erneut machen?
Kein Kommentar zu "hinzugefügt und entfernt" :-(
Bitte geben Sie mir ein funktionierendes Beispiel für einen Code, der OrderSelect verwendet, um OrderCloseTime zu erhalten.
1...45678910111213141516
Neuer Kommentar