Algoritmi, metodi di soluzione, confronto delle loro prestazioni - pagina 23

 
Andrey Khatimlianskii:

Si potrebbe semplicemente avere un intervallo più lungo. Almeno 30 secondi per il test.

Con la normalizzazione.

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


Senza normalizzazione.

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


Stesso 20%.

 
fxsaber:

Questo è il modo in cui un agente lavora, conta costantemente la stessa cosa. Se si toglie tutta la casualità, la performance netta è vicina a quella più breve.

Net non è interessante, perché non è realizzabile nella realtà.

Grazie per i test.

 
fxsaber:

Con la normalizzazione.

Senza normalizzazione.

Lo stesso 20%.


20% per un EA fittizio che non fa nulla... Non è molto significativo. Nel codice reale la cifra sarebbe molte volte inferiore. Vale la pena perdere tempo su queste banalità.

E parlando di ottimizzazione dei calcoli, dovremmo iniziare con il fatto che non c'è bisogno di monitorare costantemente i livelli di tutti gli ordini in sospeso. Dobbiamo solo controllare il più vicino. Se viene raggiunto, si passa al livello successivo e così via.

 
Alexey Navoykov:

20% per un EA fittizio che non fa nulla... Non è molto significativo. Nel codice reale la cifra sarebbe molte volte inferiore. Vale la pena perdere tempo su queste banalità.

L'osservazione è giusta. Sul mio robot normale vedo troppo ritardo nel Tester. Ci sono molte ragioni per questo. E questo è uno di loro. Un passaggio è di 100 milioni di zecche. Prendiamo la genetica standard per i passaggi 10K. Sono almeno un trilione di zecchini. Ad ogni tick il tester fa almeno una normalizzazione. Quando non poteva fare nulla. Qual è il risparmio di tali ottimizzazioni? Inoltre, preoccuparsi è fare una normalizzazione ad ogni confronto, come sta succedendo ora. In realtà è più facile ed efficiente normalizzare solo i prezzi in entrata.

E parlando dell'ottimizzazione dei calcoli, dobbiamo iniziare con il fatto che non abbiamo bisogno di monitorare costantemente i livelli di tutti gli ordini pendenti. Dobbiamo solo controllare il più vicino. Se viene raggiunto, viene controllato il livello successivo, ecc.

Il tester incorporato ha un ritardo drammatico quando il numero di ordini aumenta. I TS della rete sono i suoi "assassini". Ho suggerito una tale ottimizzazione algoritmica. Non credo che lo intraprenderanno.

Qui non stiamo parlando di una grande quantità di calcoli interni che accompagnano ogni tick del tester.