Automatische magische Zahl - Seite 3

 
BarrowBoy:

Wenn Sie keine Aufträge teilweise schließen würden, könnten Sie den Kommentar verwenden, um die Informationen zum Ursprungspaar/Zeitrahmen zu speichern...?

Wenn es zwei EAs für dasselbe Symbol und denselben Zeitrahmen gibt, woher wissen sie dann, von welchem der historischen Aufträge sie ihre jeweiligen IDs übernehmen sollen?


All dies hängt zum Teil davon ab, welche Informationen bei einem Neustart garantiert zur Verfügung stehen. Es gibt zum Beispiel einige Leute in diesem Forum, die solche Daten in versteckten Objekten im Chartfenster speichern. Das ist nicht schlecht, aber mich persönlich schreckt jeder Mechanismus ab, den der Benutzer aushebeln kann - ohne zu wissen, wie oder warum.

 
jjc wrote >>

Wenn es zwei EAs für dasselbe Symbol und denselben Zeitrahmen gibt, woher wissen sie dann, von welchem der Aufträge sie ihre jeweiligen IDs übernehmen sollen?

Verdammt - war das im Rahmen des Projekts :D

Ich bin wohl davon ausgegangen, dass der EA (wenn es sich um einen anderen Typ oder eine andere Version handelt) auch eine Kennung in den Kommentaren haben würde :)

-BB-

 
jjc wrote >>

Ich kann nicht erkennen, wie dies möglich ist, ohne dass entweder MT4 oder der Benutzer jedem EA eine ID zuweist. Oder, genauer gesagt, ich sehe nichts, was nicht etwas sehr Unangenehmes beinhaltet, wie z.B. das Generieren einer eindeutigen ID und das anschließende Ändern der .chr-Datei des EAs, um die ID als Teil der externen Parameter des EAs zu speichern.

Und, zur allgemeinen Unterhaltung, das Folgende bringt die Diskussion nicht wirklich voran, aber es ersetzt die Eingabe in den djb2-Hash durch einen Wert, der garantiert eindeutig ist (um den Preis, dass DLL-Aufrufe erforderlich sind). Ich weiß nicht, wie gut djb2 bei Dingen wie GUIDs sein soll, aber ich habe gerade versucht, 1.000.000 IDs ohne Kollisionen zu erzeugen. Aber das löst immer noch nicht das Problem des Neustarts.

Ich kann nicht erkennen, wie das möglich ist, ohne dass entweder MT4 oder der Benutzer jedem EA eine ID zuweist. Oder, genauer gesagt, ich sehe nichts, was nicht etwas sehr Unangenehmes beinhaltet, wie z.B. eine eindeutige ID zu generieren und dann die .chr-Datei des EAs zu modifizieren, um die ID als Teil der externen Parameter des EAs zu speichern.

>>Wie würde die n-te Instanz von EA ihre chartyy.chr-Datei p/u?

.

unter der Annahme, dass eine Instanz tatsächlich ihre eigene .chr-Datei zuordnen kann:

Wenn der EA-Quellcode Folgendes enthält: extern int myID = <someCompileTimeVal>;

dann kann jede Instanz, die <someCompileTimeVal> sieht, davon ausgehen, dass sie 'das erste Mal' ist -> ihre ID generieren -> die myID-Zeile modifizieren -> Wiederherstellungsdateien unter Verwendung der Einzigartigkeit von myID erstellen,...

dann beim Neustart Erkennung Zugriff auf seine .chr-Datei zu p/u myID , die Hauptschlüssel sein würde, um die Neuzuordnung von Dateien zu ermöglichen...

.

z.B.:

chart02.chr

<Diagramm>
symbol=EURUSD
Zeitraum=15
..

..

<expert>
name=LMT 1.8
flags=343
window_num=0
<Eingaben>
myID=<someCompileTimeVal>

...

</inputs>
</expert>
EOF


Hilfe !!!

.

Und, zur allgemeinen Unterhaltung, das Folgende bringt die Diskussion nicht wirklich voran, aber es ersetzt die Eingabe in den djb2-Hash durch einen Wert, der garantiert eindeutig ist (auf Kosten der Notwendigkeit von DLL-Aufrufen). Ich weiß nicht, wie gut djb2 bei Dingen wie GUIDs sein soll, aber ich habe gerade versucht, 1.000.000 IDs ohne irgendwelche Kollisionen zu erzeugen.

Ich habe PsPad ed benutzt, um die 1 Million einzusaugen und habe eine Sortierung mit dem Häkchen bei "remove dups " gemacht.

>>Aber ... WIE hast du diese "...ohne Kollisionen." Erkennung gemacht?

 

"Und, zur allgemeinen Unterhaltung, das Folgende bringt die Diskussion nicht wirklich voran, aber es ersetzt die Eingabe in den djb2-Hash durch einen Wert, der garantiert eindeutig ist (auf Kosten der Notwendigkeit von DLL-Aufrufen). Ich weiß nicht, wie gut djb2 bei Dingen wie GUIDs sein soll, aber ich habe gerade versucht, 1.000.000 IDs ohne irgendwelche Kollisionen zu erzeugen.

.

Zu Ihrer Information, ich habe Kollisionen in meinen 1 Million Aufrufen des Codes gefunden

sortiert EOF

.

sortiert + dups entfernt EOF

 
fbj:

>>Wie würde die n-te Instanz von EA ihre Datei chartyy.chr p/u?

.

vorausgesetzt, eine Instanz kann tatsächlich ihre eigene .chr-Datei zuordnen:

wenn der EA-Quelltext lautet: extern int myID = <someCompileTimeVal>;

dann kann jede Instanz, die <someCompileTimeVal> sieht, davon ausgehen, dass sie 'das erste Mal' ist -> ihre ID generieren -> die myID-Zeile modifizieren -> Wiederherstellungsdateien unter Verwendung der Einzigartigkeit von myID erstellen,...

dann beim Neustart Erkennung Zugriff auf seine .chr-Datei zu p/u myID , die Hauptschlüssel sein würde, um Remap von Dateien zu ermöglichen...

Sie haben recht. Ich hatte vergessen, dass es keine offensichtliche Möglichkeit für einen EA gibt, seine .chr-Datei zu identifizieren, wenn es mehrere EAs für dasselbe Symbol und denselben Zeitrahmen gibt. Ich dachte, dass er ein verstecktes Label-Objekt erstellen könnte, das so etwas wie eine GUID enthält, und dann nach der .chr-Datei suchen könnte, die den richtigen Wert enthält. Ich bin mir jedoch ziemlich sicher, dass die .chr-Datei nicht aktualisiert wird, wenn ein neues Objekt zum Diagramm hinzugefügt wird.


Und es gibt ein weiteres Problem. Ich bin mir ziemlich sicher, dass MT4 die Informationen über das Diagramm im Speicher hält und in die .chr-Datei schreibt, wenn MT4 geschlossen wird (oder eine Änderung an den Eigenschaften des EA vorgenommen wird), und dies würde daher alle Änderungen überschreiben, die der EA selbst an der .chr-Datei vorgenommen hat, während er lief. Wenn Sie sehr mutig sind, könnten Sie stattdessen versuchen, die externe Eigenschaft durch simulierte Tastendrücke einzustellen - indem Sie das Eigenschaftsfenster aufrufen, zur gewünschten Einstellung gehen, sie ändern, Enter drücken usw.

 
fbj:

Zu Ihrer Information, ich fand Kollisionen in meinen 1 Million Aufrufen des Codes

EOF sortiert

Bei einem erneuten Durchlauf habe ich das auch getan: 172 Kollisionen in 1.000.000 Versuchen.

 
jjc wrote >>

Sie haben Recht. Ich hatte vergessen, dass es keine offensichtliche Möglichkeit für einen EA gibt, seine .chr-Datei zu identifizieren, wenn es mehrere EAs für dasselbe Symbol und denselben Zeitrahmen gibt. Ich dachte, dass er ein verstecktes Label-Objekt erstellen könnte, das so etwas wie eine GUID enthält, und dann nach der .chr-Datei suchen könnte, die den richtigen Wert enthält. Ich bin mir jedoch ziemlich sicher, dass die .chr-Datei nicht aktualisiert wird, wenn ein neues Objekt zum Diagramm hinzugefügt wird.

Und es gibt ein weiteres Problem. Ich bin mir ziemlich sicher, dass MT4 die Informationen über das Diagramm im Speicher hält und in die .chr-Datei schreibt, wenn MT4 geschlossen wird (oder eine Änderung an den Eigenschaften des EA vorgenommen wird), und dies würde daher alle Änderungen überschreiben, die der EA selbst an der .chr-Datei vorgenommen hat, während er lief. Wenn Sie sehr mutig sind, könnten Sie stattdessen versuchen, die externe Eigenschaft zu setzen, indem Sie Tastendrücke simulieren - das Eigenschaftsfenster aufrufen, zur gewünschten Einstellung gehen, sie ändern, Enter drücken usw.

Ich habe oben gelesen -> ging los, um etwas zu üben -> und während der Dusche schreien die grauen Zellen OBJECT. Sie töten die .chr-Route, aber die zwei Worte "Objekt beschriften" haben diesen Hirnausbruch ausgelöst :)

Also, wie sieht es aus? Vergessen Sie für einen Moment, dass Sie eine 100%ige ID haben wollen. Der andere Teil ist dieser wiederherstellbare Zustandsspeicher, der eine EAs ID enthält.

Also...

1. void vArchiveID (int iID), int iRestoreID () [und int iGetNewID () werden in einem anderen Beitrag behandelt, WENN dieser hier ok ist :]

2. vArchiveID() erstellt ein [verstecktes?] Label-Objekt in EAs State Memory Chart.

Der Name des Objekts MUSS für jeden aufrufenden EA gleich sein... also .ex4 lib oder .mqh lib für (1)

3. CT geht pleite oder EA geht in die Knie usw.

4. beim Neustart ruft der EA als erstes iRestoreID() auf, das -1 zurückgibt, wenn kein Objekt im Chart ist, oder die archivierte ID vom vorherigen Lauf.

5. wenn keine ID, dann ruft iGetNewID() auf, dann vArchiveID() und legt vermutlich [zum ersten Mal] eine Dump-Datei an

6. wenn ID 'wiederhergestellt', dann wird der letzte Zustand über Dumpdateien wiederhergestellt...

..

Was denken Sie?

 
fbj:

[...]

Was denken Sie?

Was Sie vorschlagen, ist - denke ich - genau das, worauf ich in meinem Beitrag mit dem Zeitstempel 14:43 anspielte. Die einzige Gefahr bei diesem Weg - und der einzige Grund, warum man direkt in die .chr-Datei eingreift, um externe Eigenschaften zu setzen - besteht darin, die Möglichkeit auszuschließen, dass Benutzer versehentlich Objekte aus dem Diagramm löschen. Aber auch das lässt sich weitgehend umgehen, indem man sicherstellt, dass das Objekt bei Bedarf in deinit() neu erstellt wird.


BB/CB könnten es jedoch als inakzeptabel ansehen, sich auf die .chr-Datei zu verlassen. Sie wollen vielleicht etwas, das nur aus Daten wiederhergestellt werden kann, die außerhalb des Unternehmens aufbewahrt werden (z. B. die Handelsliste, die der Broker besitzt).

 

Ich war eine Weile von diesem Thema weg.


Es sieht so aus, als ob wir einen gewissen Grad an Komplexität hinzufügen, um eine Wiederherstellung mit automatisierten magischen Zahlen zu ermöglichen, ja? D.h. damit ein dummes Stück reinkarnierter Code herausfinden kann, wer er in einem früheren Leben war, wenn er nur weiß, was er ist und wo er ist. Nicht unbedingt eine schlechte Sache. Aber...


Ich habe mir überlegt, dass es nützlich wäre, (sehr knapp) zu dokumentieren:

- Kriterien für die Entscheidung, magische Zahlen zu verwenden

- Kriterien für die Entscheidung über die automatische Generierung magischer Zahlen

- Kriterien für die Entscheidung über die Implementierung einer Persistenzschicht

- Kriterien für die Entscheidung über Globals vs. Dateizugriff für Persistenz


Der Grund, warum ich dies vorschlage, ist, dass ich vermeiden möchte, dass jeder denkt, er müsse alles in seine EAs einbauen.


Ansichten ?


CB


- Ich habe nur noch 8 Beiträge, bevor ich eine kleine Pause einlege.

 

ja, letztendlich ist die Spüle wahrscheinlich auf dieser Website, alles akademisch. Mir geht es in erster Linie darum, eine garantierte auto[make|acquire] Expert ID zu haben. Ein Wert, der für viele Zwecke verwendet werden kann.

Eine eindeutige Möglichkeit, bei einem Neustart auf Dump-Dateien zuzugreifen, ist bestenfalls willkürlich und erfordert auf jeden Fall, dass sich die Benutzer an ein Regelwerk für die EA-Nutzung halten. Viele ccy+period+EA-Instanzen sind keine Option.

Ich wollte, dass jede Instanz in der Lage ist, vor dem Neustart festzustellen, wer ich war, und das hat sich als nicht praktikabel erwiesen. Ich für meinen Teil würde keinem Benutzer vertrauen, dass er auch nur die grundlegendsten Regeln befolgt. Wenn ich mir bei einer automatischen Methode nicht völlig sicher sein kann, würde ich keinen Kompromiss eingehen, der ein Eingreifen des Benutzers erfordert.

.

Mit jjc's CoCreateGuid() i/f werde ich genügend nicht-wiederkehrende Zahlen erzeugen. Genug ist subjektiv, aber ich bin für viele... Gekoppelt mit einem Bibliothekscode als Serverfunktion für den Ressourcenzugriff auf die Datei mit den Nummern. Die Anzahl der Nummern wird so groß sein, dass mindestens 2 Jahre vergehen können, ohne dass eine Nummer jemals wiederverwendet wird. Sobald EOF erreicht ist, wird einfach zu BOF gewechselt und die Ausgabe der Zahlen fortgesetzt. Bei meinen Berechnungen gehe ich von 10 Antragstellern aus, die 5 Tage pro Woche und 50 Wochen pro Jahr arbeiten, wobei ein Antragsteller jeden Tag 20 neue IDs benötigen könnte. Dieses Ergebnis wird dann verdoppelt. Eine absurde Anzahl von Zahlen - im Grunde 200.000. Ja, eine steinzeitliche Funktionalität, aber wasserdicht, ohne dass man sich in irgendeiner Weise auf das Terminal verlassen muss, abgesehen von der Fähigkeit, meinen Code auszuführen. Natürlich könnte man noch ewig über die Verzweigungen von einer, 10 oder 100 Dateien und ihre physischen Speicherorte und Zugriffsmechanismen diskutieren. Letztendlich ist es viel besser als meine bedauernswerte make expert id Funktion und ist wasserdicht in Bezug auf die Eindeutigkeit der Nummern für [in Wirklichkeit] mehr als 2 Jahre.

.

CB, 666 muss die Glückszahl eines Hubschrauberpiloten sein... :\