Сергей Таболин: Jetzt warte ich darauf, dass der Optimierer längere Zeit läuft. Ich werde sehen, was passiert.
Ihr Fall macht Sinn. Nicht bestandene Prüfungen werden nicht in den Zwischenspeicher geschrieben
FM 215:59:58.313 Core 5 pass 1396 tested with error "incorrect input parameters"in0:00:00.218
KI 216:00:01.301 Core 8 pass 1664 tested with error "incorrect input parameters"in0:00:00.188
MD 216:00:01.301 Core 8 pass 1665 tested with error "incorrect input parameters"in0:00:00.187
EP 216:00:01.301 Core 8 pass 1666 tested with error "incorrect input parameters"in0:00:00.203
RL 216:00:01.301 Core 8 pass 1667 tested with error "incorrect input parameters"in0:00:00.203
LH 216:00:01.371 Core 3 pass 1413 tested with error "incorrect input parameters"in0:00:00.187
EG 216:00:01.371 Core 3 pass 1414 tested with error "incorrect input parameters"in0:00:00.187
KS 216:00:01.371 Core 3 pass 1415 tested with error "incorrect input parameters"in0:00:00.188
PO 216:00:06.154 Core 4 pass 1556 tested with error "incorrect input parameters"in0:00:00.218
LK 216:00:06.154 Core 4 pass 1557 tested with error "incorrect input parameters"in0:00:00.219
DF 216:00:06.154 Core 4 pass 1558 tested with error "incorrect input parameters"in0:00:00.203
RR 216:00:06.154 Core 4 pass 1559 tested with error "incorrect input parameters"in0:00:00.219
MN 216:00:10.151 Core 6 pass 1812 tested with error "incorrect input parameters"in0:00:00.203
GJ 216:00:10.151 Core 6 pass 1813 tested with error "incorrect input parameters"in0:00:00.219
GI 216:00:10.151 Core 6 pass 1814 tested with error "incorrect input parameters"in0:00:00.203
GE 216:00:10.637 Core 5 pass 1397 tested with error "incorrect input parameters"in0:00:00.203
Und nur die Durchläufe, die ohne Fehler durchgelaufen sind, werden zwischengespeichert.
Es befinden sich gleichzeitig Daten im Cache
QK 016:05:34.655 Tester cache file 'tester\cache\KrL_4.93.GBPCHF.M30.20170401.20170701.10.678BEE8FF38C7C7BF8515210F346F03E.opt' contains 441 records
HH 016:05:34.655 Tester Experts\KrL_4.93.ex5 on GBPCHF,M30 from2017.04.0100:00 to 2017.07.0100:00
RI 016:05:34.758 Tester GBPCHF: history data begins from2009.10.2000:00
MP 016:05:34.758 Tester GBPUSD: history data begins from1998.01.0200:00
PK 016:05:34.863 Tester USDCHF: history data begins from1998.01.0200:00
LE 016:05:34.863 Tester complete optimization started
RF 016:05:34.863 Tester size of initial task batch is512
MR 016:05:34.868 Tester reading of 441 result records from cache...
QP 016:05:34.868 Tester 1 blocks of results read from cache in0 ms
Man muss sich überlegen, was man in Fällen wie dem Ihren tun kann. Der EA ist aus eigener Kraft gescheitert, nicht wegen externer Faktoren und einiger Fehler
Aber die Sache ist die, dass frühere Versionen des Optimierers eine solche Rücksetzung nicht hatten.
Hängt es mit dem überarbeiteten Cache zusammen?
Und stellt sich nicht heraus, dass alle "Reset"-Durchgänge nach dem Neustart einen neuen durchlaufen? Solange sie nicht schriftlich festgehalten werden?
Rein rechnerisch:
Wenn es ursprünglich 1000 Pässe gab und bei 300 gestoppt wurde, sind noch 700 übrig.
Angenommen, INIT_PARAMETERS_INCORRECT hatte 100 Durchläufe.
Nach dem Start begann es mit 200. Und es sind noch 800 Pässe übrig. Wir müssen immer noch die gleichen 1000 Pässe ausstellen.
Es hat sich herausgestellt, dass wir 100 unnötige Pässe haben. Zwar nicht sehr teuer, aber trotzdem?
Und was mich betrifft: Von 18760 Pässen waren 1534 "richtig". Das bedeutet, dass 17226 Durchgänge wiederholt werden! Das ist nicht sehr nett.
Ja. Die Rücksetzungsläufe werden auf eine neue Art und Weise durchgeführt. Im Falle von INIT_PARAMETERS_INCORRECT werden diese Durchläufe sehr schnell vergehen.
Überlegen Sie, wie Sie solche Durchgänge im Cache markieren können
IndicatorRelease() im Tester hat vorher nicht funktioniert. Funktioniert es jetzt?
@Slava
Problem: Die Schaltfläche "Einzeltest durchführen" ist inaktiv.
Ich mache eine Optimierung.
Wenn ich nach Abschluss der Optimierung das Datum ändere (Beginn und Ende des Tests), wird die Schaltfläche "Einzeltest durchführen" inaktiv.
Die gleiche Situation wird beobachtet, wenn ich das Modell zur Erzeugung von Ticks ändere.
Baujahr: 1835.
Dieses Problem gab es vor einem Monat definitiv noch nicht!
Ist dies ein Fehler oder eine solche Idee?
@Slava
Problem: Die Schaltfläche "Einzeltest durchführen" ist inaktiv.
Ich mache eine Optimierung.
Wenn ich nach Abschluss der Optimierung das Datum ändere (Beginn und Ende des Tests), wird die Schaltfläche "Einzeltest durchführen" inaktiv.
Die gleiche Situation wird beobachtet, wenn ich das Modell der Tickgenerierung ändere.
Baujahr: 1835.
Dieses Problem gab es vor einem Monat definitiv noch nicht!
Ist dies ein Fehler oder eine solche Idee?
Ich schließe mich der Frage an.
Machen Sie es wieder so, wie es war!
Jetzt warte ich darauf, dass der Optimierer längere Zeit läuft. Ich werde sehen, was passiert.
Ihr Fall macht Sinn. Nicht bestandene Prüfungen werden nicht in den Zwischenspeicher geschrieben
Und nur die Durchläufe, die ohne Fehler durchgelaufen sind, werden zwischengespeichert.
Es befinden sich gleichzeitig Daten im Cache
Man muss sich überlegen, was man in Fällen wie dem Ihren tun kann. Der EA ist aus eigener Kraft gescheitert, nicht wegen externer Faktoren und einiger FehlerWenn Sie nur die Eingabeparameter des EA ändern, wird ein neuer Cache angelegt. Der vorherige Cache wird nicht gelöscht.
Ich schließe mich der Frage an.
Machen Sie es wieder so, wie es war!
Zurück zu
Zurück zu
Ist die 1835er-Version so langsam wie die 1816er-Version oder ist sie wie die 17xxer-Versionen?
Zurück zu
Wären Sie so freundlich, es mir zu sagen?
Warum wurde die Pause im Modus"genetischer Algorithmus" entfernt?
Ich vermute, dass die Pause bei der Verwendung von Drittanbietern Probleme verursacht hat,
aber für die Optimierung bei lokalen Agenten war diese Funktion sehr nützlich.
Ich habe dortEingabeparameter geprüft und mit INIT_PARAMETERS_INCORRECT ausgegeben.
Aber die Sache ist die, dass frühere Versionen des Optimierers eine solche Rücksetzung nicht hatten.
Hängt es mit dem überarbeiteten Cache zusammen?
Und stellt sich nicht heraus, dass alle "Reset"-Durchgänge nach dem Neustart einen neuen durchlaufen? Solange sie nicht schriftlich festgehalten werden?
Rein rechnerisch:
Wenn es ursprünglich 1000 Pässe gab und bei 300 gestoppt wurde, sind noch 700 übrig.
Angenommen, INIT_PARAMETERS_INCORRECT hatte 100 Durchläufe.
Nach dem Start begann es mit 200. Und es sind noch 800 Pässe übrig. Wir müssen immer noch die gleichen 1000 Pässe ausstellen.
Es hat sich herausgestellt, dass wir 100 unnötige Pässe haben. Zwar nicht sehr teuer, aber trotzdem?
Und was mich betrifft: Von 18760 Pässen waren 1534 "richtig". Das bedeutet, dass 17226 Durchgänge wiederholt werden! Das ist nicht sehr nett.
Ja. Die Rücksetzungsläufe werden auf eine neue Art und Weise durchgeführt. Im Falle von INIT_PARAMETERS_INCORRECT werden diese Durchläufe sehr schnell vergehen.
Überlegen Sie, wie Sie solche Durchgänge im Cache markieren können
Ja. Die Rücksetzungsläufe werden auf eine neue Weise ausgeführt. Im Falle von INIT_PARAMETERS_INCORRECT werden diese Durchläufe sehr schnell vergehen.
Überlegen Sie, wie Sie solche Durchgänge im Cache markieren können
Und Sie können dann sofort korrekte Daten über Finanzindikatoren zurückgeben - als Nullen anstelle von verrückten Zahlen?