@Grzegorz Gajoch - wydaje mi się, że te testy są złe, bo auta mają inne rozmiary po przestawieniu

@Krzysztof Wędrowicz test jest robiony ręcznie, powinien być poprawny, chyba że walnąłem się gdzieś przy wpisywaniu współrzędnych z rysunku.

Pytanie do @Krzysztof Barański lub innego człowieka dobrej woli ;) Czy drugi przykład w http://speedy.sh/gVehV/par-test.in zawiera jakiś specyficzny wyjątek? Bo potwierdzam wszystkie inne testy oprócz tego jednego :/

EDIT:
Nie ma to jak znaleźć buga na godzinę przed deadlinem. Potwierdzam wszystkie.

@Grzegorz Gajoch nie potwierdzam! Ja cały czas miałem;)

Potwierdzam wszystko, oprócz tych dużych, bo pobrać nie mogę :(

Wrzucam swoje testy - trochę późno, ale urwało prąd w Krakowie :D
https://dl.dropboxusercontent.com/u/11045076/tests.rar
Potwierdzi ktoś?

Sygnał 11 to Segmentation Fault (SIGSEGV). Twój program go dostaje gdy próbuje czytać lub pisać niezaalokowaną pamięć. Jeśli Twój program chce zużyć więcej niż limit pamięci, któraś alokacja się w końcu nie powiedzie i być może zwróci NULL (dostęp do którego spowoduje SIGSEGV). Możliwe też, że dotykasz jakiejś niezaalokowanej pamięci (np. za końcem tablicy). Do wykrywania takich problemów przydają się takie narzędzia jak Valgrind lub Address Sanitizer. W szczególności tego drugiego jest bardzo łatwo użyć z odpowiednio nowym gcc: wystarczy do opcji kompilacji dopisać -fsanitize=memory.

Mhm.

Potwierdzam wszystkie powyższe testy, fakt w ostatnim trzeba zabrać jedno 0 i jest w porządku.

Potwierdzam :)

Potwierdzam też ostatni test, przy czym mam zastrzeżenie: nie zachodzi d(i) <= N :)

Nie mogę pobrać maksów Grzegorze. Trzeba mieć premium :/

zgadza się, powinno być jedno zero mniej. już poprawione

> http://www.speedyshare.com/RHxFH/par-test.in
> http://www.speedyshare.com/NBMEB/par-test.out

Pierwszy przypadek ma za duże liczby.
Po zmniejszeniu potwierdzam cały test.

Wielce szczęśliwy potwierdzam wszystkie testy :).