알고리즘, 결정 방법, 성능 비교 - 페이지 23

새 코멘트
 
Andrey Khatimlianskii :

어쩌면 더 긴 간격일 수도 있습니다. 적어도 초 30 테스트가 갔다.

정규화와 함께. 

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


정규화 없이. 

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


모두 동일한 20%입니다.

 
fxsaber :

이것은 하나의 에이전트가 동일한 것을 순차적으로 계산하는 방식입니다. 모든 종류의 사고를 제거하면 순 성능이 가장 짧습니다.

순수는 현실에서 달성할 수 없기 때문에 흥미롭지 않습니다.

테스트해주셔서 감사합니다.

 
fxsaber :

정규화와 함께.

정규화 없음.

모두 동일한 20%입니다.


아무것도 하지 않는 더미 EA의 경우 20%...별로 중요하지 않습니다. 실제 코드에서는 그 수치가 몇 배나 적습니다. 그런 사소한 일에 시간을 낭비할 가치가 있습니까?

그리고 계산 최적화에 대해 이야기한다면 모든 보류 중인 주문의 수준을 지속적으로 모니터링할 필요가 없다는 사실부터 시작해야 합니다. 가장 가까운 것만 확인하면 됩니다. 도달하면 다음 레벨 등이 됩니다.

 
Alexey Navoykov :

아무것도 하지 않는 더미 EA의 경우 20%...별로 중요하지 않습니다. 실제 코드에서는 이 수치가 몇 배나 적습니다. 그런 사소한 일에 시간을 낭비할 가치가 있습니까?

지적이 맞습니다. 내 일반 로봇에서 테스터의 백로그가 너무 많이 보입니다. 많은 이유가 있습니다. 그리고 이것은 그들 중 하나입니다. 하나의 패스는 1억 틱입니다. 10K 패스에 대한 표준 유전학을 살펴보겠습니다. 최소한 1조 틱입니다. 각 틱에서 테스터는 하나 이상의 정규화를 수행합니다. 내가 전혀 하지 않을 수도 있을 때. 이러한 최적화를 통해 어떤 절감 효과를 얻을 수 있습니까? 더욱이, 귀찮게 하는 것은 현재 일어나고 있는 것처럼 각 비교에 대해 정규화를 수행하는 것입니다. 실제로 들어오는 가격만 정규화하는 것이 더 쉽고 효율적입니다.

그리고 계산 최적화에 대해 이야기한다면 모든 보류 중인 주문의 수준을 지속적으로 모니터링할 필요가 없다는 사실부터 시작해야 합니다. 가장 가까운 것만 확인해야 합니다. 도달하면 다음 레벨 등이 됩니다.

일반 테스터 는 주문이 많아지면 많이 처집니다 . 동일한 그리드 차량이 그의 "킬러"입니다. 이러한 알고리즘 최적화를 제안 했습니다. 나는 그들이 할 것이라고 생각하지 않습니다.

여기서 우리는 각 틱에 수반되는 테스터의 많은 내부 계산을 논의에서 제외합니다.

1...1617181920212223
새 코멘트