Algorithmen, Lösungsmethoden, Vergleich ihrer Leistung - Seite 23

[fxsaber]

Andrey Khatimlianskii:

Sie könnten einfach eine längere Pause einlegen. Mindestens 30 Sekunden für den Test.

Mit Normalisierung.

pass 0 returned result 100000.000000 in 0:00:35.296
pass 1 returned result 100000.000000 in 0:00:29.361
pass 2 returned result 100000.000000 in 0:00:24.549
pass 3 returned result 100000.000000 in 0:00:25.067
pass 4 returned result 100000.000000 in 0:00:24.578
pass 5 returned result 100000.000000 in 0:00:24.634
pass 6 returned result 100000.000000 in 0:00:25.079
optimization finished, total passes 7
optimization done in 3 minutes 09 seconds
shortest pass 0:00:24.549, longest pass 0:00:35.296, average pass 0:00:26.937

Ohne Normalisierung.

pass 0 returned result 100000.000000 in 0:00:33.035
pass 1 returned result 100000.000000 in 0:00:26.020
pass 2 returned result 100000.000000 in 0:00:20.137
pass 3 returned result 100000.000000 in 0:00:20.859
pass 4 returned result 100000.000000 in 0:00:21.130
pass 5 returned result 100000.000000 in 0:00:20.664
pass 6 returned result 100000.000000 in 0:00:21.001
optimization finished, total passes 7
optimization done in 2 minutes 50 seconds
shortest pass 0:00:20.137, longest pass 0:00:33.035, average pass 0:00:23.263

Gleiche 20 %.

[Andrey Khatimlianskii]

fxsaber:

So arbeitet ein Agent, der immer das Gleiche zählt. Wenn man alle Zufälligkeiten wegnimmt, ist die Nettoleistung fast die kürzeste.

Net ist uninteressant, da es in der Realität nicht realisierbar ist.

Vielen Dank für die Tests.

[Alexey Navoykov]

fxsaber:

Mit Normalisierung.

Ohne Normalisierung.

Die gleichen 20 %.

20% für einen Dummy-EA, der nichts tut... Das ist nicht sehr aussagekräftig. In echtem Code wäre die Zahl um ein Vielfaches geringer. Lohnt es sich, Zeit mit solchen Kleinigkeiten zu verschwenden?

Apropos Optimierung der Berechnungen: Es besteht keine Notwendigkeit, die Bestände aller ausstehenden Aufträge ständig zu überwachen. Wir müssen nur den nächstgelegenen überprüfen. Wenn sie erreicht ist, wird die nächste Stufe erreicht und so weiter.

[fxsaber]

Alexey Navoykov:

20% für einen Dummy-EA, der nichts tut... Das ist nicht sehr aussagekräftig. In echtem Code wäre die Zahl um ein Vielfaches geringer. Lohnt es sich, Zeit mit solchen Nebensächlichkeiten zu verschwenden?

Die Feststellung ist richtig. Bei meinem normalen Roboter sehe ich eine zu große Verzögerung im Tester. Hierfür gibt es viele Gründe. Und dies ist einer von ihnen. Ein Durchgang entspricht 100 Millionen Ticks. Nehmen Sie die Standard-Genetik für 10K-Pässe. Das sind mindestens eine Billion Ticks. Bei jedem Tick führt der Prüfer mindestens eine Normalisierung durch. Wenn sie gar nichts tun könnte. Wie hoch sind die Einsparungen bei einer solchen Optimierung? Außerdem würde man sich die Mühe machen, bei jedem Vergleich eine Normalisierung vorzunehmen, wie es jetzt geschieht. Es ist tatsächlich einfacher und effizienter, nur die eingehenden Preise zu normalisieren.

Was die Optimierung der Berechnungen anbelangt, so müssen wir nicht ständig den Stand aller anhängigen Aufträge überwachen. Wir müssen nur den nächstgelegenen überprüfen. Ist sie erreicht, wird die nächste Stufe geprüft usw.

Der eingebaute Tester hinkt dramatisch hinterher, wenn die Zahl der Aufträge steigt. Das Netz TS sind seine "Killer". Ich habe eine solche algorithmische Optimierung vorgeschlagen. Ich glaube nicht, dass sie das tun werden.

Hier geht es nicht um eine große Menge interner Berechnungen, die jeden Tick des Testers begleiten.