Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?

Zadanie "Skrzaty" z VI OIG

Ostatnio zmodyfikowano 2013-10-09 18:44
Autor Wiadomość
Chumanista
Temat założony przez niniejszego użytkownika
» 2013-09-27 14:44:25
Dlaczego /64?
1 pole w wektorze<bool> przechowuje 1 skrzata a nie 64.
I nie, wydajność nie będzie taka sama.
Będzie wielokrotnie mniejsza.
Tak, sprawdzałem w tym konkretnym zastosowaniu.
P-92719
DejaVu
» 2013-09-28 12:59:40
I nie, wydajność nie będzie taka sama.
Będzie wielokrotnie mniejsza.
Jeżeli uważasz, że wiesz lepiej co jest lub będzie szybsze to myślę, że kontynuowanie tego tematu nie ma już najmniejszego sensu. Dodam jeszcze, że Twoje stwierdzenie jest nieprawdziwe, ponieważ wygenerowany kod binarny aplikacji będzie taki sam dla tablicy jak i dla vectora w trybie Release, więc te same instrukcje procesora w tej samej kolejności nie nie mogą być 'wielokrotnie' wolniejsze. Takie tematy były na forum i nawet wygenerowany kod asemblera był przedstawiany dla obu przypadków przez osoby, które mają nieporównywalnie większą wiedzę i doświadczenie niż Ty. Niemniej jednak jeżeli uważasz, że Ty wiesz 'lepiej' to nie mam nic przeciwko abyś miał własne poglądy, dopóki nie zaczynasz wygłaszać fałszywych twierdzeń na forum, bo potem n-kolejnych początkujących programistów takie przeczytane stwierdzenie przyjmuje za prawdę i chwali się swoją nierzetelną wiedzą wśród znajomych, propagując tym samym informacje niezgodne z prawdą.
P-92781
Chumanista
Temat założony przez niniejszego użytkownika
» 2013-09-28 13:50:08
Witam.
Byłoby miło poczekać z zamykaniem na moją odpowiedź.
anyways oto ona:
Będzie ponieważ w 1 uint64_t przechowywane są wartości 64 skrzatów a w bool 1, więc podczas kopiowania z safeT do safe wykonywane jest iloscSkrzatow/64 a nie iloscSkrzatow operacji bitowych.
Jak pisałem sprawdziłem to w praktyce.
Ale nie, bo "wygenerowany kod binarny aplikacji będzie taki sam dla tablicy jak i dla vectora".
Cy pan nie czyta to co piszę, czy my się nie rozumiemy?
Jedyne co otrzymuje to sugestię, że nie potrafię korzystać z najoczywistszych funkcji (vector.reserve/resize).
Wszystko co piszę odnosi się do TEJ KONKRETNEJ SYTUACJI i pochodzi w większości z praktyki, więc co mają do rzeczy początkujący programiści?
Tego, że złożoność nie jest kwadratowa np. nie skomentowaliście.
Może początkujący programiści będą myśleli, że n = n^2?
Chyba ma pan rację, moja dalsza obecność tutaj nie ma sensu.
P-92783
ison
» 2013-09-28 15:55:46
Złożoność masz n*m

C/C++
for( int i = 0; i < czasDoSnu; i++ ) // n
{
    ...
   
    for( int m = 0; m < iloscSkrzatow / 64 + 1; m++ )
    {
        // jeśli warunek if się nie spełni, to sprawdzeń będzie m
        // jeśli warunek się spełni w jakimś momencie to i tak jest w nim pętla do m
       
        if( safe[ m ] & safeT[ m ] )
        {
            for( int p = 0; p < iloscSkrzatow / 64 + 1; p++ )
                 safe[ p ] |= safeT[ p ];
           
            break;
        }
    }
}
// tak więc złożoność to n*m

Stałą masz faktycznie bardzo małą, zaledwie 1 if albo jakaś operacja bitowa. Kompilator być może Ci to jakoś optymalizuje, ale fakt faktem, że powinieneś założyć że nie masz tu złożoności liniowej i tego się trzymać. W innych zadaniach już tak łatwo żyłować się nie będzie dało gdy stałe będziesz miał bardzo duże. Dla tego typu programów może tego aż tak nie będziesz widział, jak w przypadku bardziej skomplikowanych.

To tak jakby mówić, że f(x) = x+0.001*x^2 to nie funkcja kwadratowa, gdyż 0.001 jest wystarczająco małe.
Jeśli dostajesz 100 pkt. za to zadanie to gratulacje.

//edit
n*m*m odpada, nie zauważyłem, że tam jest break. Tak więc zostaje n*m.
P-92801
Chumanista
Temat założony przez niniejszego użytkownika
» 2013-09-28 17:21:07
A jednak ktoś czyta to, co piszę, miło.
Nie mówiłbym, że jest liniowa, gdyby z logów wynikało inaczej.
Jest to spowodowane konstrukcją tych konkretnych test casów (mnóstwo sytuacji 1 iloscSkrzatow).

P-92813
ison
» 2013-09-28 17:30:20
Ale na jakich testach sprawdzałeś? To normalne, że niekiedy brute force'y działają 'prawie liniowo' dla zupełnie losowych testów, tu właśnie chodzi o to aby takiego rozwiązania nie udało się uwalić jakimś sprytnym testem.

Rozpatrywanie złożoności nie ma sensu jeśli mamy tylko 1 przypadek bez zmiennych. Jeśli testujesz rozwiązanie na stałych danych to złożoność też masz stałą.

Tutaj akurat różnicę zobaczyłbyś dla większych danych, lub na 'sprytniejszych' testach. Dla n i m < 10^999 rozwiązanie liniowe działałoby przykładowo 10 dni a Twoje 10000 dni, na mniejszych testach po prostu nie widać różnicy gdyż masz za małą stałą.
Jeśli miałbyś mniejszą złożoność to nie musiałbyś się bawić w tego typu optymalizacje, mógłbyś nawet mieć ogromne stałe, a i tak byś się zmieścił w czasie.
P-92814
Chumanista
Temat założony przez niniejszego użytkownika
» 2013-09-28 18:23:59
A jakie jest to lepsze rozwiązanie?
Sprawdzałem na ostatnim teście od nich, na wszystkich pozostałych mam w dolnej połowie limitu.
/edit: Nie, inne dane by nic nie zmieniły.
Już teraz scanf to ~10%mocy, żeby nie było == za pierwszym razem smok musiałby obserwować pierwsze 64 skrzaty -> ~40 razy więcej miejsc niż teraz -> więcej czasu w scanf niż w algorytmie -> wszystko udupione lub wielokrotnie krotnie dłuższe maksymalne czasy. Te przykłady które są są złośliwe.
P-92817
DejaVu
» 2013-10-03 09:47:37
Nie używaj dzielenia bo jest wolne i niepotrzebne.
P-93044
1 2 3 « 4 » 5
Poprzednia strona Strona 4 z 5 Następna strona