Si potrebbe semplicemente avere un intervallo più lungo. Almeno 30 secondi per il test.
Con la normalizzazione.
pass 0 returned result 100000.000000in0:00:35.296
pass 1 returned result 100000.000000in0:00:29.361
pass 2 returned result 100000.000000in0:00:24.549
pass 3 returned result 100000.000000in0:00:25.067
pass 4 returned result 100000.000000in0:00:24.578
pass 5 returned result 100000.000000in0:00:24.634
pass 6 returned result 100000.000000in0:00:25.079
optimization finished, total passes 7
optimization done in3 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.000000in0:00:33.035
pass 1 returned result 100000.000000in0:00:26.020
pass 2 returned result 100000.000000in0:00:20.137
pass 3 returned result 100000.000000in0:00:20.859
pass 4 returned result 100000.000000in0:00:21.130
pass 5 returned result 100000.000000in0:00:20.664
pass 6 returned result 100000.000000in0:00:21.001
optimization finished, total passes 7
optimization done in2 minutes 50 seconds
shortest pass 0:00:20.137, longest pass 0:00:33.035, average pass 0:00:23.263
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à.
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.
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.
Si potrebbe semplicemente avere un intervallo più lungo. Almeno 30 secondi per il test.
Con la normalizzazione.
Senza normalizzazione.
Stesso 20%.
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.
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.
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.