Erstellen Sie einen Zertifizierungsdienst für Programmierer ... - Seite 6

[Rustamzhan Salidzhanov]

Ja Jungs....

Sie können bereits Bewertungen abgeben :))))

[snowman]

VOLDEMAR:
Wenn Sie nichts Gutes zu sagen haben, sagen Sie nichts oder sprechen Sie wenigstens darüber ..... Wenn du etwas wüsstest, würdest du es mir zeigen... Oder ist es zu schade? Oder sie wissen gar nichts ....

gibt es keinen Grund zum Streiten.

Es wäre besser, wenn Sie Ihre Funktionen zum Senden von Bestellungen auf die Korrektheit der an den Server gesendeten Bestellung überprüfen würden.

Ich möchte nicht, dass der Fehler vor dem Server gemeldet wird, sondern vor...)

[Alexander Bereznyak]

MrGold166:

Das ist der Punkt des Überschießens vom Ende her, es gibt nichts Militärisches daran, eine Order zweimal zu verarbeiten. Im schlimmsten Fall hindert es uns nur daran, wenn wir Orders zählen, z.B. den Durchschnittspreis, wird eine Order zweimal gezählt. Auch wenn es die Berechnungen stark stört, wird beim nächsten Tick alles wieder an seinen Platz zurückkehren und wir werden den Take Profit dort platzieren, wo er sein sollte. In meiner Erinnerung mit mehr als 50 Aufträgen und mit dem schlechtesten so genannten asiatischen "Broker" (ja, Sie wissen, wen ich meine) ist dies nie passiert, nachdem das Konto gehandelt wurde (Sie wissen warum). Aber auch dies kann vermieden werden:

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

Und wie können Sie garantieren, dass Sie beim nächsten Mal nicht wieder in dieselbe Situation geraten, nämlich gar nicht.

Und im schlimmsten Fall berechnen Sie den Durchschnitt falsch und eröffnen eine falsche Order, und der nächste Tick spielt keine Rolle mehr.

Es kommt nicht auf die Anzahl der Aufträge an, sondern auf das Handelsumfeld, das Vorhandensein echter Stopps und das Vorhandensein anderer EAs auf dem Konto.

[A100]

MrGold166:

Aber auch dies kann vermieden werden:

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

Theoretisch könnte mehr als ein Auftrag den Status ändern

[Alexander Bereznyak]

A100:
Theoretisch könnte sich der Zustand von mehr als einem Auftrag ändern

Eine gute Idee, aber ich habe nicht an zwei gedacht, sondern bin bei einem hängengeblieben.

Also zurück zum Anfang: Wie löst man Kollisionen mit dieser Funktion?

[snowman]

sandex:

Gute Idee, ich habe nicht an zwei gedacht, sondern bin bei einem hängen geblieben.

Also zurück zum Anfang: Wie löst man Kollisionen mit dieser Funktion?

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

Berechnen Sie gegebenenfalls erneut. wenn die Anzahl der Ein- und Ausstiegsaufträge nicht gleich ist.

[[Gelöscht]]

A100:
Theoretisch könnte sich mehr als ein Auftrag ändern

Na und? Selbst wenn alle wechseln, werden wir nicht die gleichen Berufe analysieren.

Wenn es sich um ein Geschäft handelt, das sich auf der Liste geändert hat, dann kann es sich ändern, nachdem wir die Suche durchgeführt haben - bevor wir den Gesamtgewinn angeben.

[A100]

snowman:

Berechnen Sie ggf. erneut, wenn die Anzahl der Ein- und Ausstiegsaufträge nicht gleich ist.

Im allgemeinen Fall kann sogar die Anzahl der Aufträge gleich sein, nur können es unterschiedliche Aufträge sein

[[Gelöscht]]

snowman:

Wenn die Anzahl der Aufträge beim Einstieg und beim Ausstieg nicht gleich ist, dann berechnen Sie sie erneut.

Dies hilft uns auch nicht weiter, wenn ein schwebender Auftrag eröffnet wird. Die Anzahl der Aufträge wird gespeichert, die Parameter jedoch nicht. Andererseits würde uns das kaum stören, wenn wir einen neu eröffneten schwebenden Auftrag nicht in den Betrag einbezogen hätten, das ist in Ordnung. (Ich sehe wirklich keine Situation, in der dies einen Fehler verursachen könnte). Diese Situation kann nur unter bestimmten Umständen eintreten, z. B. wenn sehr viele Ticks vorhanden sind, d. h. wenn die nächste Iteration sehr bald stattfindet und der Fehler korrigiert wird. Wenn der Rebound zwischen den Ticks erfolgt, ist das für uns kein Problem.

Wir sehen oft Codes anderer Programmierer, in denen die Aufzählung Dutzende Male pro Iteration separat durchgeführt wird, um einen Haufen von Parametern zu berechnen, und das ist ein Problem.

[A100]

MrGold166:

Na und? Selbst wenn alle wechseln, werden wir nicht die gleichen Berufe analysieren.

Wenn es sich um ein Geschäft handelt, das sich auf der Liste geändert hat, dann kann es sich ändern, nachdem wir die Suche durchgeführt haben - bevor wir den Gesamtgewinn angeben.

Ich habe mich nicht auf die Berechnung in einer bestimmten Situation bezogen, sondern auf den allgemeinen Fall. Ich denke, dass Doppelzählungen und/oder Unterzählungen durchaus eine Rolle spielen, manchmal auch kritisch.