Różnica drogi dla wielu pojedynczych kroków i jednego wielokrotnego kroku

[mikolajgolunski]

Ponownie zgłaszam najprawdopodobniej problem z symulatorem. Jeśli mam rację proszę o jakiś bonus (może dodatkowe punkty jeśli się zakwalfikujemy?) za znajdowanie i zgłaszanie problemów...

Wygląda na to, że trasa przejazdu uwzględniająca forward_drift jest liczona różnie dla przypadku gdy wykonuję komendę MOVE x niż gdy podaję x razy MOVE 1. Spodziewałbym się tej samej trasy dla obu przypadków. Według moich obliczeń droga podawana w przypadku MOVE x powinna być poprawna.

Przykład testowy:
Wersja symulatora świeżo ściągnięta z githuba.
Warunki - oba noise równe 1e-10, forward_steering_drift równy -5e-04, seed równy 777, pozycja początkowa (2.5, 2.5).
Gdy daję robotowi komendę MOVE 400 to zgłasza zakończenie przejazdu na współrzędnych (6.4734862004779758, 2.10232491180999).
Gdy daję robotowi 400 razy komendę MOVE 1 to zgłasza zakończenie przejazdu na współrzędnych (6.3945777947612035, 1.7125570972311031).
Plik testowy ten sam co w poprzednim błędzie.

[kudkudak]

Niestety chyba bonus nie wchodzi w rachubę :) Ale bardzo dziękujemy za zgłoszone błędy.

Faktycznie jeśli robimy MOVE 50 to będzie to miało efektywnie 2 razy mniejszy forward_steering_drift niż MOVE 1 odpalone 50 razy. Ze względu na bliski deadline nie będziemy tego zmieniać, ale w czasie sprawdzania postaramy się aby nie miało to znacznego wpływu na wynik bota. Przepraszamy za kłopoty związane ogólnie z kontrolą losowości.

Issue zostawiamy aby pamiętać o poprawce przed następną edycją.

[mikolajgolunski]

To może chociaż po kubku dla członków drużyny. W końcu wykonujemy częściowo waszą robotę. No i mogliśmy nic nie mówić i potencjalnie skorzystać na niewiedzy przeciwników (co prawdopodobnie robią inne drużyny).

Czyli mam rozumieć, że aktualnie jak puszczę MOVE 50 z forward_steering_drift = 1e-5 to wyląduję w tym samym miejscu co gdy puszczę 50 razy MOVE 1 z forward_steering_drift = 2e-5, tak? A jeśli nie to jak aktualnie liczony jest dryf dla wielu pojedynczych kroków (żebym mógł sobie sam policzyć gdzie końcowo wyląduję)?

Poza tym stwierdzenie

postaramy się aby nie miało to znacznego wpływu na wynik bota

implikuje, że dryf przy sprawdzaniu będzie pomijalny. Ewentualnie będzie np. jeden przejazd z dryfem a reszta bez i będziecie odrzucać najgorszy wynik albo brać średnią z wyników, albo coś takiego. Dobrze rozumiem to stwierdzenie?

[ziarrek]

Oczywiście, pomyślimy nad jakąś formą podziękowania, ale to wtedy w ramach osobistego podziękowania od członków naszego zespołu. Nie powinno być takich błędów w kodzie. Symulator testowaliśmy poprzez sprawdzanie, czy nasz własny bot jest w stanie wykonać zadanie. Niestety taka metoda testowania nie nadaje się do znalezienia tak precyzyjnych błędów. Nauczka na przyszłość, żeby robić unit testy.

W obecnej wersji bug polega na tym, że kiedy licznik komendy się wyzeruje (w przypadku MOVE 100 - po wykonaniu 100 kroków, a w przypadku MOVE 1 - po jednym kroku), funkcja robot.move() jest wywoływana błędnie jeszcze raz, tylko że z argumentem 0. W związku z tym argumentem robot nie przesuwa się dodatkowo do przodu, ale i tak aplikowany jest dryf, czyli obrót o wartość wyznaczoną przez forward_steering_drift. To dodatkowe wywołanie następuje jednokrotnie po MOVE 100 i tak samo jednokrotnie po MOVE 1 dlatego jeżeli wywołuje się ciągle MOVE 1 to zagregowany dryf jest większy. To można policzyć, ale czy bardziej nie opłaca się potraktowanie symulatora jako "czarnej skrzynki" i oszacowanie od góry tego błędu? Bo przecież i tak dochodzi szum Gaussa, który jest losowy.

Jeszcze co do komentarza @kudkudak - bo muszę trochę sprostować: nie możemy sprawić, by dryf przy sprawdzaniu był pomijalny, ale tak jak jest napisane w regulaminie testerki - programy zostaną sprawdzone na wielu mapach i zestawach parametrów (szumu i dryfu) i dopiero wyniki (punkty i czasy) znormalizowane i uśrednione ze wszystkich przejazdów będą podstawą do rankingu. Wyniki zostaną opublikowane w raz z opisem sposobu, w jaki były liczone, żeby wszystko było przejrzyste.

[dawid0planeta]

Bug ten powoduje również to, że komenda TURN 0 jest wykonywana dodatkowo co zwiększa ilość razy kiedy szum jest aplikowany oraz długość przejazdu. W komendzie MOVE 0 nie ma to znaczenia ponieważ bot nie poruszy się w ogóle oraz nie zmieni czasu. Czy to też jest problem z którym musimy żyć?

[ziarrek]

Tak, ten bug wpływa na komendy MOVE i TURN. Napisaliśmy dzisiaj o tej sprawie w mailu do wszystkich drużyn. Ponieważ zostało już mało czasu do deadline'u, a ten błąd nie wpływa jakoś drastycznie na rozgrywkę, postawiliśmy po prostu na jasne wytłumaczenie wszystkim na czym polega błąd ale nie zmienianie już niczego w symulatorze.