Alternative Implementierungen von Standardfunktionen/-ansätzen - Seite 9

[Georgiy Merts]

fxsaber:

Ich bin an einem Punkt angelangt, an dem das Problem nicht mehr auftritt und habe es sicher vergessen. Es ist toll, wenn man nicht auf einmal geschriebenen Code zurückgreifen muss. Es funktioniert - das ist die Hauptsache.

Das ist richtig. Ich mache das immer selbst (und auch dieses Mal, wie Sie sehen können).

Das Problem entsteht, wenn sich plötzlich etwas ändert. Wenn der Code klar ist und nicht offensichtliche Stellen gut kommentiert sind, sind die Ursachen für Fehler bei einigen Änderungen leicht zu finden. Aber in solchen Fällen von "und vergessen" - ist es viel schwieriger, Korrekturen vorzunehmen.

Ja, natürlich, das ist ein seltener Fall... Aber diese sehr seltenen Fälle - da bin ich persönlich sehr nervös. Deshalb versuche ich in solchen Situationen, so viel wie möglich klaren Code zu schreiben und nicht offensichtliche Stellen ausführlich zu kommentieren.

[Реter Konow]

fxsaber:

Ein Beispiel für meinen Code, den ich im Moment überhaupt nicht verstehe. Und es gibt eine Reihe von Faktoren, die sehr gut verstanden werden müssen.

Wie Sie sehen können, ist der Code/Stil sehr einfach. Aber ich kann einen Fehler darin oder sein Fehlen erst feststellen, wenn ich denselben Code noch einmal schreiben kann. Es wird mich wirklich viel Zeit kosten, denn ich muss mich mit dem Problem eingehend beschäftigen.

Deshalb ist das Prinzip, dass komplexe Dinge in der Erstellungsphase bereinigt werden (Stresstests werden geschrieben) und in einfacher Form durch Einfügen von mqh verwendet werden. Wie Sie sehen, wird die Komplexität nicht immer durch Stil oder Kürze bestimmt.

Es gibt auch ein Beispiel für rein sprachliche Konstrukte - TypeToBytes. Die Komplexität des Verständnisses ist dort eine ganz andere. Und das ist der Punkt, an dem ich ohne Makros verkümmern würde. Dank der Makros gelangen Sie recht schnell in den Quellcode. Denn Makros werden oft nicht aus Gründen der Kürze, sondern des Verständnisses verwendet.

Und es gibt auch den Fall, dass man viele unkomplizierte, aber vergessliche Fallstricke beachten muss. Dies ist bei MT4Orders der Fall. Deshalb sind manche Zeilen dort mit Kommentaren versehen, die nur an einen selbst gerichtet sind. Es hilft, Ihren Code zu verstehen.

Aber beachten Sie, dass es sich dabei um mqh handelt, die Sie nicht zu kennen brauchen. Und der Code von TC ist mit mqh geschrieben, was sehr einfach ist. Sie haben keinen Einblick in den Quellcode der regulären iHigh-Funktionen. Und sie sind in der Tat Ungeheuer. Man benutzt sie einfach. Sie sollten dasselbe mit Bibliotheken tun. Um dieselbe generische Schreibweise zu verwenden, müssen Sie sie nicht vollständig verstehen.

Sehen Sie sich die QB für MT4 EAs und ihre MT5 Ports an. MT5-Ports sind schwer zu verstehen. Es riecht nicht nur nicht annähernd nach Prägnanz (der Code ist um ein Vielfaches größer als das Original), es hat auch klappernde MT5-Fallen, die in den mqh-Dateien nicht berücksichtigt sind.

Ehrlich gesagt, habe ich hier nichts zu beanstanden. Offensichtlich ist alles richtig, wenn man Ihren Ansatz zur Programmierung zugrunde legt (vielleicht nur mit Ausnahme der Fälle von übermäßiger und ungerechtfertigter Codekomprimierung), aber wenn Sie meinen Ansatz verfolgen, ist vieles falsch.

1. Natürlich können sich auch in sehr einfach geschriebenem Code schwer zu findende Fehler verbergen. Aber in schwer zu schreibendem Code sind sie noch schwieriger zu finden. Bedenken Sie die geistige Anstrengung, die mit dem Entpacken der Bedeutung verbunden ist. Wenn Sie viel Arbeit zu erledigen haben (viele Funktionen schreiben, neue Mechanismen entwickeln, sie erfolgreich in bestehende integrieren), ist es am wichtigsten, Zeit und Mühe zu sparen. Es geht nicht um die "Schönheit" des Codes. Nicht über Stile. Sie müssen Ihren Code so verfassen, dass Sie ihn mitten in der Nacht lesen und so schnell wie möglich verstehen können. Sie beginnen mit der Suche nach der idealen Codierungsmethode, um das bestmögliche Ergebnis für sich selbst zu erzielen. Und wie es aussieht:

return((int)((Value > 0) ? Value / Points[digits] + HALF_PLUS : Value / Points[digits] - HALF_PLUS) * Points[digits]);

verstehen Sie sofort alle Nachteile, die mit dieser Schreibweise verbunden sind:

1. Eine Menge Charaktere.

2. Übermäßiges "Verpacken".

3. unkommentierte mathematische Operationen.

Sie werden nicht in der Lage sein, diesen Code zu bearbeiten, wenn Sie wach sind. Es ist auch schwierig, mit Überlastung und Müdigkeit fertig zu werden. Stellen Sie sich vor, Sie arbeiten jeden Tag auf diese Weise. Sie wenden sich sofort von einem solchen Code ab.

2. Schauen Sie sich nicht den Code anderer Leute an und fügen Sie ihn einfach ein?

Ich glaube, dass große, seriöse und vor allem qualitativ hochwertige Programme nicht einfach dadurch entstehen, dass man die Blöcke anderer Leute zusammensetzt. Man kann kein effizientes Programm schaffen, indem man nur einen kleinen Teil davon erstellt und den Rest anfügt. Es wird eine "Sauerei" sein.

Es kann und wird funktionieren. Aber das sind "Behelfsprogramme".

Ich glaube nicht an die Wirksamkeit von Programmen, die aus Blöcken zusammengesetzt sind (in die der Entwickler nicht einmal hineinschaut). Dies ist eine Fiktion. Das Programm wird lahm sein, und die Lösungen werden unwirksam sein. Es wird eine Menge Probleme geben. Wenn Programmierer als Team zusammenarbeiten und eine gemeinsame Aufgabe lösen, ist das gut, aber wenn Lösungen verwendet werden, die zwischen verschiedenen Programmen verschiedener Leute "schweben" (die sich nicht einmal darum kümmern), ist das unter dem Gesichtspunkt der Effizienz nichts.

[fxsaber]

Реter Konow:

Es kann und wird funktionieren. Aber das ist, - Programme "auf den Knien".

Sie können sich meine Veröffentlichungen in KB ansehen. Jemand muss sie benutzen.

Ich schreibe nur für mich und "auf meinen Knien". Veröffentlichungen sind ein Nebenprodukt.

[pavlick_]

Georgiy Merts:

Die Prüfung auf LONG_MAX - sollte also vor der Umwandlung von double in long erfolgen. Die Rundungsfunktion ist offensichtlich nicht für Werte gedacht, die nicht in eine Ganzzahl passen. Und das ändert nichts an dem Problem.

Wenn die Funktion double zurückgibt, das wir dann in long umwandeln, besteht die gleiche Gefahr eines Überlaufs.

Ich persönlich habe immer eine Assert-Prüfung für Grenzwerte kurz vor dem Runden; außerdem ist die Logik des Programms so, dass ich immer sicherstelle, dass ein Wert, der größer als die Maxima für eine ganze Zahl ist, nie bei der Transformation ankommen kann.

Werfen Sie oft lange in den Saibling? Genauso verhält es sich mit double - es ist die letzte Stufe der Hierarchie, man muss nicht von ihm aus casten und in den meisten Fällen muss man das auch nicht - std hat alles, um damit zu arbeiten. Lassen Sie sich nicht von der Hierarchie herab und machen Sie sich keine Sorgen.

Fügen Sie Prüfungen für LONG_MAX/MIN hinzu - und etwas sagt mir, dass die Leistungstests nicht so rosig ausfallen werden. Und die Person strebt eine Standard-Substitution an, also sollte sie für den gesamten Wertebereich funktionieren.

[Georgiy Merts]

pavlick_:

Werfen Sie oft lange Saiblinge? Es ist dasselbe mit dabl - es ist die letzte Stufe in der Hierarchie, es gibt keine Notwendigkeit, von ihm zu casten, in den meisten Fällen gibt es nichts damit zu tun, std hat alles, um mit ihm zu arbeiten. Werfen Sie die Hierarchie nicht hinunter und machen Sie sich nicht die Mühe.

Fügen Sie Prüfungen für LONG_MAX/MIN hinzu, und ich bin sicher, dass die Leistungstests nicht so viel Glück haben werden. Und der Mann zielt auf die Standard-Substitution ab, also sollte es für den gesamten Wertebereich funktionieren.

long zu ulong (und umgekehrt) - nur allzu oft.

lang zu verkohlen - selten.

Die Umrechnung ist notwendig, weil Ganzzahl- und Fließkommaoperationen sehr unterschiedliche Ergebnisse liefern. Auch die Ausführungsgeschwindigkeit von Integer-Daten ist angeblich höher.

Zur Bereichsprüfung - ich habe bereits betont, dass es sich um ASSERT handelt - d.h. eine solche Prüfung funktioniert nur in der DEBUG-Version. In meinem Fall werden alle Eingabeparameter immer zu Beginn jeder öffentlichen Funktion mit Asserts auf einen gültigen Bereich geprüft, was mir mehr als einmal geholfen hat. RELEASE-Versionen funktionieren natürlich bereits ohne jegliche Prüfung.

[Реter Konow]

fxsaber:

Sie können einen Blick auf meine Veröffentlichungen in KB werfen. Jemand muss sie benutzen.

Ich schreibe nur für mich und "auf meinen Knien". Veröffentlichungen sind ein Nebenprodukt.

Ich stelle Ihre Erfahrung und Professionalität nicht in Frage.

Es ist nur so, dass man im Prozess der anstrengenden und täglichen Programmierung und Entwicklung über mehrere Jahre hinweg beginnt, die Vorteile eines bestimmten Codes, einer bestimmten Lösung oder eines bestimmten Ansatzes zu schätzen. Und man kommt oft zu sehr seltsamen Schlussfolgerungen... Seltsam, aber durch viel Praxis gerechtfertigt.

Ich teile nur meine Sichtweise.

[pavlick_]

Georgiy Merts:

Die Notwendigkeit einer Umrechnung ergibt sich daraus, dass das Ergebnis von Ganzzahl- und Fließkommaoperationen sehr unterschiedlich ist.

Ich kann mir nicht vorstellen, in welchen Situationen etwas nicht richtig mit Dubles gemacht werden kann. In Lua (das an quik angehängt ist) gibt es überhaupt keine Integer-Typen, nur Dubles und nichts.

[fxsaber]

pavlick_:

Ich habe eine schlechte Vorstellung davon, in welchen Situationen etwas auf Dubles nicht richtig gemacht werden kann.

Zähler.

void OnStart()
{
  const long Num1 = 9007199254967295;
  const long Num2 = Num1 + 1;

  Print(Num1 == Num2); // false
  Print((double)Num1 == (double)Num2); // true
}

double verliert nicht alle Informationen im Nahbereich, bei long nicht mehr so sehr.

[pavlick_]

fxsaber:

Zähler.

Nun, man muss immer noch bis zu dieser Zahl zählen )). Und wenn Sie das wirklich wollen, ist das keine Option:

double cnt;
double high_cnt;
if (++ cnt == 1 000 000) {
   ++ high_cnt;
   cnt = 0;
}

[Georgiy Merts]

pavlick_:

Nun, man muss immer noch bis zu dieser Zahl zählen )). Aber wenn Sie das wirklich wollen, ist das keine Option:

Es ist verständlich, dass man sich dabei verheddern kann. Aber ist es das wert?

Wenn die Variable nur ganzzahlige Werte haben darf, sollte sie meiner Meinung nach ganzzahlig sein, um zu verhindern, dass ein Fließkommawert hineingeschrieben wird. Der Typ der Variablen oder des Rückgabewerts selbst enthält bereits wichtige Informationen über die Variable und teilweise über den Algorithmus. Wenn wir überall Fließkommazahlen verwenden, geht diese Information verloren.

Und selbst die Ganzzahl muss - je nach Algorithmus - meiner Meinung nach entweder als vorzeichenbehaftet oder vorzeichenlos deklariert werden, und zwar nicht unbedingt als lang, sondern vielleicht als "kürzer", damit wir beim Betrachten des Codes sofort erkennen können, welchen Wertebereich die betreffende Variable haben darf.

Die Tatsache, dass es in Lua keine Integer-Werte gibt, ist meiner Meinung nach ein großer Nachteil.