Fehler, Irrtümer, Fragen - Seite 3131

Neuer Kommentar
 
x572intraday #:

Ich kann nur für &= sofort antworten:

MQL5 Referenzhandbuch / Grundlagen der Sprache / Operationen und Ausdrücke / Zuweisungsoperationen:

In Analogie zur kumulativen Variable y:


Aber das ist meine erste Erfahrung mit &=, ich könnte also falsch liegen.

Zunächst werden alle logischen Bedingungen im akkumulativen h_plus innerhalb von for summiert und die resultierende boolsche Summe wird in if eingefügt, das nichts mit dem internen for zu tun hat.
Dennoch wäre es korrekter, nicht 
h_plus&=high[i]>high[i+increment];
sondern 
h_plus = h_plus && high[i]>high[i+increment];
 
Alexey Viktorov #:

In Ihrem Fall ist dies nicht der Fall, da beide Bedingungen erfüllt sein müssen. Aber wenn Sie das

dann, ja. Wenn die Bedingung "a" erfüllt ist, wird die zweite Bedingung nicht geprüft. Dafür wird seit Jahren gekämpft, und jetzt schlagen Sie vor, dass wir ins letzte Jahrhundert zurückgehen...

Obwohl... ich mit dieser Aussage falsch liege. Offensichtlich verstehe ich nicht ganz, was hier geschrieben wird.

x572intraday #:

Ich wage es nicht, es einen Fehler zu nennen. Deshalb will ich nur sagen, dass mir eine Besonderheit des if-Operators aufgefallen ist. Ich vermute, dass dies auch für andere Schriftsprachen relevant sein könnte.

Wenn sich a als wahr herausstellt, springt check zu Array[over_index] und hier beginnt das Terminal durch den"array out of range"-Teil abzustürzen, der durchaus wahr ist. Aber wenn sich a als falsch herausstellt, prüft das Terminal nicht auf die Array[over_index]-Bedingung und damit auf Index-Redundanz, und if überspringt weiter und der Programmierer weiß nicht, dass es ein Array mit einem nicht existierenden Index in seinem Programm gibt... oder vielmehr eine bestehende, aber überflüssige.

Vielleicht sollte es einen Fix dafür geben, so dass die Prüfung auf "array out of range" bis zum Ende der if-Schleife durchgeführt wird und die gleiche Meldung ausgegeben wird? Oder wird es die Geschwindigkeit des Bedieners erheblich verringern?

Selbst wenn die &&-Bedingung und die erste Bedingung nicht erfüllt sind, wird die zweite Bedingung nicht geprüft. Also, entschuldigen Sie, wenn ich jemanden in die Irre geführt habe...

 
x572intraday #:

Ich habe bereits versucht, beide zu unterbrechen und eilig zurückzukehren, aber das hat die Sache nur noch schlimmer gemacht. Ich werde versuchen, den Code weiter zu vereinfachen und ihn mit Pause zu überdenken...

for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus =  high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Zum Beispiel so.

 

Bei der Skalierung des Diagramms durch Bewegen der Maus entlang der Zeitachse läuft das Diagramm je nach Mausrichtung nach links oder rechts, so dass alles, was sich im Blickfeld des Benutzers befindet, oft einfach hinter den Grenzen des Diagramms verschwindet. Das ist furchtbar lästig, weil man dann die richtige Stelle suchen muss, und das ist der Fall, seit ich MT kenne.

Es war logisch anzunehmen, dass ein Klick auf das Lupensymbol das Diagramm in die Mitte skaliert, aber nein, das Verhalten ist dasselbe wie bei der Skalierung mit der Maus - das Diagramm verschiebt sich nach links (Kompression) oder nach rechts (Expansion).

Liebe Entwickler! Wir bitten Sie ernsthaft, das Skalierungsverhalten des Diagramms zu ändern, es ist notwendig, die Mitte des Diagramms in der Mitte zu lassen.

Alle, mit denen ich über die Unannehmlichkeiten bei der Arbeit mit dem Diagramm gesprochen habe, stimmen mit mir überein, so dass ich eine gute Chance habe, dieses Problem objektiv zu betrachten.

Ich habe 14 Jahre lang versucht, mich daran zu gewöhnen - und konnte es nicht.

 
JRandomTrader #:
for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus = high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Das ist so.

Eine neue Idee, ich werde sie ausprobieren.

Wie bei der vorherigen Option:

for(int i=start; i<rates_total-3 && !IsStopped(); i++)
{
   bool h_plus=true; //false?
   for(int increment=1; increment<=n; increment++)
     {
      h_plus&=high[i]>high[i+increment];
      if(!h_plus)break;
     }
   if(h_plus) {...}
   ...
}

ohne es überhaupt auszuprobieren, ist es bereits klar, dass

if(!h_plus)break;

ist nach der Summierung, was bedeutet, dass das Terminal die vorherige Zeile zuerst sieht und versteht, dass es ein Array mit einem übermäßigen Index gibt und dieselbe Meldung"Array out of range" ausgibt. Das ist die zweite Sache. Und die erste ist, dass wir nicht auf !h_plus, sondern auf ArraySize(high)<=i+increment prüfen und die Schleife verlassen sollten, falls der Index überschritten wird. Ich habe das alles gestern versucht, bin aber bei einigen Feinheiten gescheitert. Ja, es gab keine Nachricht, aber der Indikator fing auch an, ein Durcheinander zu machen.

 
x572intraday #:

Wie bei der vorherigen Option:

ohne es überhaupt auszuprobieren, ist es bereits klar, dass

ist nach der Summierung, was bedeutet, dass das Terminal die vorherige Zeile zuerst sieht und versteht, dass es ein Array mit einem übermäßigen Index gibt und dieselbe Meldung"Array out of range" ausgibt. Das ist die zweite Sache. Und die erste ist, dass wir nicht auf !h_plus, sondern auf ArraySize(high)<=i+increment prüfen und die Schleife verlassen sollten, falls der Index überschritten wird. Ich habe das alles gestern versucht, bin aber bei einigen Feinheiten gescheitert. Ja, der Bote war verschwunden, aber auch der Indikator begann, ein Chaos zu verursachen.

Das Problem hier ist also

i<rates_total-3
Ich habe 
i<rates_total-n
aus einem bestimmten Grund geschrieben, und das frühe Verlassen der Schleife dient genau dazu, die if()-Berechnung zu simulieren
 
x572intraday #:

Ich wage nicht, es einen Fehler zu nennen. Ich möchte nur sagen, dass mir eine Besonderheit der if-Anweisung aufgefallen ist. Ich vermute, dass dies auch für andere Sprachen gilt.

Wenn sich a als wahr herausstellt, springt check zu Array[over_index] und hier beginnt das Terminal durch den Teil'array out of range' abzustürzen, der durchaus wahr ist. Aber wenn sich a als falsch herausstellt, prüft das Terminal nicht auf die Bedingung Array[over_index] und damit auf die Redundanz des Indexes, und if wird weiter überspringen und der Programmierer wird nicht wissen, dass es ein Array mit einem nicht existierenden Index in seinem Programm gibt... oder vielmehr eine bestehende, aber überflüssige.

Vielleicht sollte es einen Fix dafür geben, so dass die Prüfung auf "array out of range" bis zum Ende der if-Schleife durchgeführt wird und die gleiche Meldung ausgegeben wird? Oder wird sie die Geschwindigkeit des Bedieners erheblich verringern?


Wenn Sie die Variable a auf false setzen, wird die Kontrolle weitergegeben und wirkt sich nicht auf das Array oder den Code in Klammern nach if aus, da in Ihrem Fall

if(a && Array[over_index]>val) {...}

die Kontrolle wird nur dann an den rechten Teil der Bedingung weitergegeben, wenn der linke Teil (a) wahr ist

wenn Sie zum Beispiel Folgendes tun

if(check(over_index) && Array[over_index]>val) {...}

wo die check-Funktion das Array Array prüft,bekommt man nie"array out of range". Man kann also den Array-Index prüfen und ihn in einem if adressieren. Aber die Kontrolle an den zweiten Teil von if mit dem &&-Operator zu übergeben, wenn der erste Teil falsch ist, ist in keiner der existierenden Programmiersprachen möglich...

 

Es gibt nur ein Problem: Es taucht zufällig und gelegentlich auf.

Erscheint, wenn man im Tester mit mehreren Währungen arbeitet.

In jedem Zyklus fordere ich aktuelle Preise für Symbole an. Wenn das Prüfgerät aus irgendeinem Grund keine Kurse für ein bestimmtes Symbol erhält, verwendet es die zuvor für ein anderes Symbol erhaltenen Kurse.

Ich sollte eine Position eröffnen, wenn der Preis höher als der angegebene Preis ist. Ich sollte eine Position eröffnen, wenn ich falsche Daten von einem anderen Symbol erhalten habe.

Das EURCAD-Symbol öffnet sich, wenn der Preis über 1,45117 liegt. 1,74425>1,45117? Ja, er ist höher, aber es ist der Preis eines anderen Symbols.

Wir haben 7 von 500 fehlerhaften Aufträgen entdeckt.

 
Yury Lemeshev #:

Es gibt nur ein Problem: Es taucht zufällig und gelegentlich auf.

Erscheint, wenn man im Tester mit mehreren Währungen arbeitet.

In jedem Zyklus fordere ich aktuelle Preise für Symbole an. Wenn das Prüfgerät aus irgendeinem Grund keine Kurse für ein bestimmtes Symbol erhält, verwendet es die zuvor für ein anderes Symbol erhaltenen Kurse.

Ich sollte eine Position eröffnen, wenn der Preis höher als der angegebene Preis ist. Ich verwende falsche Daten von einem anderen Symbol zum Öffnen.

EURCAD-Symbol, wenn der Preis über 1,45117 ist, dann öffnet es. 1,74425>1,45117? Ja, er ist höher, aber es ist der Preis eines anderen Symbols.

Wir haben 7 von 500 fehlerhaften Aufträgen entdeckt.

Das Problem liegt im Code, aber die Telepathen feiern schon und wenn sie aus dem Schlaf erwachen, werden sie sagen, dass der Fehler in der Zeile 123652 liegt

 
Alexey Viktorov #:

Probleme im Code, aber die Telepathen sind schon am Feiern, und wenn sie aus ihrem Rausch herauskommen, werden sie sagen, dass der Fehler in Zeile 123652 liegt

Es gibt keinen Fehler im Code, der Code wurde umgeschrieben, um den Fehler zu beseitigen, und der Fehler tritt nicht regelmäßig auf, er ist völlig chaotisch

1...312431253126312731283129313031313132313331343135313631373138...3184
Neuer Kommentar