Poradnik młodego Problem Settera

W niniejszym poradniku przedstawione zostały wskazówki oraz wymagania dla osób chcących zostać autorami zadań kolejnej rundy AlgoLigi.

  1. Pierwszym krokiem jaki należy wykonać jest poinformowanie koordynatorów AlgoLigi o chęci zorganizowania kolejnej jej rundy. W tym celu należy wysłać wiadomość na adres kontakt na algoliga.pl, słowo na należy oczywiście zastąpić znakiem małpy. W treści maila prosimy zawrzeć dane osób, które będą organizowały daną rundę oraz przewidywaną ilość zadań. Prosimy również opisać czy macie już jakieś doświadczenie w przygotowywaniu zadań programistycznych czy też będą to pierwsze organizowane przez Was zawody. Dane każdej z osób powinny zawierać:
    • Imię i nazwisko
    • Adres e-mail (regularnie sprawdzany!)
    • Login SPOJ
    • Numer GG (o ile dana osoba go posiada)
    Dane te są wymagane do zapewnienia ciągłości kontaktu podczas organizacji rundy. Nie chcemy, aby ewentualna niedyspozycja jednej osoby, np. poprzez chorobę, spowodowała brak kontaktu z resztą organizatorów.
  2. Nie wymagamy, aby na etapie zgłoszenia chęci organizacji rundy zadania były już przygotowane.
  3. Pomimo tego, że dopuszczamy możliwość zorganizowania rundy przez jedną osobę to zalecamy organizację grupową. W przypadku gdy działamy w grupie autor zadania może poprosić resztę organizatorów o ocenę przygotowanej treści oraz sprawdzenie poprawności rozwiązania. Zalecane jest, aby każdy z organizatorów spróbował rozwiązać zadania pozostałych. W ten sposób najłatwiej wykryć błędy i nieścisłości w przygotowanym zadaniu oraz ocenić jego trudność. Poza tym co dwie głowy to nie jedna! ;-)
  4. Zaleca się, aby każda runda AlgoLigi zawierała od 8 do 12 zadań.
  5. Treści zadań powinny być sformułowane w języku polskim i przygotowane z najwyższą starannością. Należy pamiętać, że treść zadania to jedyna porcja informacji jaką otrzymuje zawodnik. Treść powinna zawierać:
    • Jasny opis problemu jaki jest do rozwiązania
    • Opis specyfikacji wejścia czyli jakie dane powinien wczytywać program zawodnika
    • Zakres wczytywanych danych czyli wartości maksymalne i minimalne jakie mogą wystąpić na wejściu. Autorzy czasami pomijają niektóre zakresy danych, w celu utrudnienia rozwiązania. Jest to sytuacja dopuszczalna jeżeli owy zakres danych można wywnioskować z innej części treści zadania, należy jednak pamiętać, że zawodnicy nie są jasnowidzami!
    • Opis specyfikacji wyjścia czyli co powinno być wypisywane jako wynik działania programu oraz w jakim formacie
    • Przykłady czyli dane jakie wczytał program z wejścia oraz dane jakie wypisał na wyjściu. Dane podane w teście przykładowym powinny być również zawarte w testach do zadania.
    Podsumowując, po przeczytaniu treści zadania użytkownikowi nie powinny nasuwać się żadne dodatkowe pytania oprócz jednego: Jak to wydajnie zaimplementować? Oczywiście autor zadania powinien również zadbać o przestrzeganie zasad pisowni języka polskiego.
  6. Do każdego zadania autor powinien przygotować co najmniej 3 pliki testowe:
    1. Plik z testami przykładowymi z treści zadania
    2. Plik z testami poprawnościowymi. W tym pliku powinny zostać zawarte podchwytliwe dane testowe, które sprawdzają czy zawodnik w swoim rozwiązaniu przewidział wszystkie trudne przypadki jakie mogą wystąpić w zadaniu.
    3. Plik z testami wydajnościowymi. Plik ten jak sama nazwa wskazuje powinien badać szybkość rozwiązania przygotowanego przez użytkownika. Ma on na celu odrzucenie rozwiązań poprawnych, ale o słabszej złożoności obliczeniowej niż rozwiązanie wzorcowe. Ze względu na duże rozmiary pliki wydajnościowe przeważnie są generowane przez specjalnie do tego celu napisane programy.
  7. Dane zawarte w testach powinny być starannie sprawdzone pod kątem poprawności ich zakresów. Problem ten można rozwiązać dodając do kodu rozwiązania wzorcowego warunki sprawdzające czy dana wartość mieści się w zakresie. Jeżeli warunek nie jest spełniony nasz program powinien zakończyć działanie sygnalizując błąd wykonania. W języku C++ do tego celu możemy użyć makra assert:

    #include <cassert> #include <cstdio> ... int Z; scanf("%d", &Z); assert(0 < Z && Z <= 1000); ...

    Powyższy kod sprawdza czy zmienna Z mieści się w przedziale <1, 1000>.
  8. Pliki wyjściowe MUSZĄ być wygenerowane przez skompilowany program z rozwiązaniem wzorcowym. Przykładowo w systemie Windows pliki wyjściowe mogą zostać wygenerowane poprzez wydanie w Wierszu polecenia (cmd.exe) komendy:
    C:\Rozwiazania\Zadanie1.exe < C:\Testy\1.in > C:\Testy\1.out

    a w systemie Linux:
    ./zadanie1 < testy/1.in > testy/1.out

    Takie podejście umożliwia nam sprawdzenie czy nasz program wypisuje dane zgodnie z określoną przez nas specyfikację wyjścia. Dodatkowo dla małych testów poprawnościowych powinniśmy mieć przygotowane poprawne odpowiedzi na kartce albo w innym pliku testowym, aby móc porównać je z tymi wygenerowanymi przez nasze rozwiązanie wzorcowe.
  9. Najważniejsza porada odnośnie tworzenia zadania brzmi: TESTUJ, TESTUJ, TESTUJ I JESZCZE RAZ TESTUJ! Nie ma nic gorszego niż gdy podczas zawodów okazuje się, że ktoś znalazł błąd w twoim rozwiązaniu wzorcowym i całe zadanie nadaje się do wywalenia do kosza. Z tego powodu tak jak to było napisane już wcześniej zalecamy, aby każdy z organizatorów spróbował rozwiązać zadania pozostałych!
  10. Kiedy treści zadań, rozwiązania wzorcowe oraz testy są już gotowe należy poinformować o tym fakcie koordynatorów AlgoLigi. Nie należy jednak wrzucać zadań na SPOJa zanim was o to nie poprosimy. Przyczyna tego stanu rzeczy jest bardzo prosta nazewnictwo kodów zadań AlgoLigi jest ściśle określone i chcemy dbać o jego przestrzeganie.
  11. Jeżeli żaden z organizatorów nie ma uprawnień na SPOJu do wrzucania zadań prosimy o poinformowanie nas o tym fakcie drogą mailową.
  12. W tym chwalebnym dniu kiedy wasza runda AlgoLigi zostanie w końcu rozegrana dobrze by było, gdyby jeden z Problem Setterów organizujących rundę był obecny przez większość czasu (możliwe są oczywiście zmiany wart) by odpowiadać na ewentualne pytania w komentarzach.
  13. That's all folks!
© Spoj.com. All Rights Reserved. Spoj uses Sphere Engine™ © by Sphere Research Labs.