eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming › sortowanie
Ilość wypowiedzi w tym wątku: 567

  • 21. Data: 2012-10-13 14:14:40
    Temat: Re: sortowanie
    Od: bartekltg <b...@g...com>

    W dniu 2012-10-13 11:39, Michoo pisze:

    >> Insertionsort jest w oczywisty sposób szybszy w sensie
    >> oczekiwanej liczby porównań (w select wyszukujemy maks
    >> wśród tablic długości n, n-1, n-2...4,3,2, w insert
    >> wkładamy zadany element w tablice długości 1,2..n-1,
    >> a średnio włożymy w połowę długości.
    >
    > Zgadza się.
    >
    >>
    >> Jeśli więc porównanie jest znacznie kosztowniejsze od
    >> przesunięcia, wolimy mieć dwa razy mniej porównań,
    >> nawet kosztem dodatkowych ~n^2 przesunięć.
    >
    > Widziałem nawet takie rozważanie gdzie wyszukiwanie w części
    > posortowanej było robione przeszukiwaniem binarnym, a wstawianie było w
    > czasie stałym - dostajemy złożoność insertion sort n*log(n) ;)

    Hehe.
    Złożoność oczywiście pozostaje, ale jakieś tam korzyści
    w działaniu mogą się pojawić.
    Ale mam coś lepszego. Autor pewnej bardzo popularnej książki
    do "c++ i szablonów" buduje wyszukiwanie binarne latając
    po kontenerze ++owaniem iteratora. Komentuje to "++ jest szybkie".


    >> Jeśli sortowalibyśmy listę, problem w ogóle znika.
    > Lista musi być na tyle duża, że nie możemy jej skopiować do struktury o
    > dostępie swobodnym, ale jest to naciągane, bo przy złożoności n^2
    > prawdopodobnie taniej będzie przenieść listę na pamięć zewnętrzną,
    > zwolnić, wczytać do tablicy, posortować jakimś q/heap sortem, zapisać na
    > pamięć zewnętrzną, zwolnić, wczytać do listy ;)

    Zaalokować pamięć, i to wszytko dla 50 intów:)


    >> A czasem o wyborze może zadecydować stabilność sortowania.
    >
    > Jeżeli dobrze widzę to i insertion i selection może być stabilny.

    Insertion jest od razu. Jak prosto poprawić selection, nie wiem.
    Już w pierwszym ruchu zamieniami maksymalny element (możemy
    go wybrać tak, aby wśród kilku równych był to ten właściwy),
    ale element pierwszy ląduje w losowym miejscy, zupełnie
    zaburzając porządek względem innych elementów o tej samej wartości.

    Ok, wiem jak prosto poprawić... ale to wymaga dodatkowej
    tablicy długości n:(

    >>
    >> Tak więc ja bym nie był tak pewny odpowiedzi:)
    >>
    >> A poważnie, z tą pamięcią to ciekawy problem.
    >> Jeśli już mamy całość w cache (nie rozważamy
    >> przecież na serio sortowania dużych tablic)
    >> ale jednocześnie porównanie jest tanie (inty).
    >
    >> Żeby nie był to problem czysto akademicki,
    >> niech to będzie 'końcówka qsorta'. Wtedy wywoływany
    >> obszar i tak już najpewniej jest pod ręką.
    >
    > Ale w takiej sytuacji jest heapsort działający zawsze w n*log(n) ;)

    Mylisz sytuację.
    Nie chodzi o problem qsorta z niektórymi danymi,
    tylko o to, że gdy, w czasie zrównoważonego działania,
    dochodzimy do rekursywnego wywołania qsorta dla odpowiednio
    małych obszarów, odpala się jakiś mały zwarty n^2.
    Daje to kilka, w optymistycznym przypadku (gdy porównania są
    tanie) kilkanaście procent przyspieszenia.


    >>
    >> Heh, możnaby jakimś studentom zadać;)
    >
    > Wygrzebałem stare sprawozdanie na "algorytmy i struktury danych".
    > Najszybszym algorytmem dla losowych danych był wtedy heapsort napisany w
    > assemblerze (ale miałem na jego optymalizację dobre 3 godziny podczas
    > jazdy pociągiem). Największym zaskoczeniem był Shell:
    > http://grota.be/~michoo/smieci/algo_sort.png

    Ładnie.

    A co do shella. Już ciąg Pratta miał O(N log^2N)
    To asymptotycznie niedużo więcej niż 'normalne'
    algorytmy. A są lepsze ciągi:
    http://en.wikipedia.org/wiki/Shellsort#Computational
    _complexity

    Hmm. Piszą, że się nawet w specjalnych zastosowaniach tego używa.

    q_med to qsort z medianą z ilu wartości? Wszystkich z przedziału?


    Ale wróćmy do selectsort i insertsort.

    Napisałem palce obie wersje(specjalnie dla fira, prawie c):

    void insertsort(int * tabl,int first, int last)
    {
    for (int j = first+1;j<=last;j++) //pierwszy nieposortowany
    {
    int i=j;
    int temp = tabl[j];
    while ((i>first) && temp<tabl[i-1])
    {
    tabl[i]=tabl[i-1];
    i--;
    }
    tabl[i]=temp;
    }//for
    }



    void selectsort(int * tabl,int first, int last)
    {
    for (int j=first; j<last; j++)
    {
    int min = j;
    for (int i=j+1;i<=last;i++)
    {
    if (tabl[i]<tabl[min]) min=i;
    }
    int temp = tabl[min];
    tabl[min]=tabl[j];
    tabl[j]=temp;
    }//for
    }


    I dość brutalną metodę testowania. Długi, losowe identyczne tablice,
    wkładane po kawałkach w obie procedury.
    Robimy ileś powtórzeń dla tablic długości n.
    Za każdym raazem tablica całkowicie losowa.


    Wyniki.. cóż, mnie zaskoczyły. Sprawdziłem nawet zamieniajac
    w procedurze testowej funkcje miejscami.

    W kolejności,
    n-dlugość tablicy, liczba powtórzeń, wynik dla insert, wynik dla select
    Wyniki w ms. Tabelka na końcu.

    Wychodzi, że insert jest jednak szybszy. I jego przewaga rośnie

    Wykres czasu pojedynczego powtórzenia (nasz wynik/liczba powtórzeń)
    na log log
    http://w303.wrzuta.pl/obraz/8asI9fMQioF/loglog_czas

    Proporcja czasu selectsorca do insertsorta dla rożnych n.
    http://w303.wrzuta.pl/obraz/apPnxl5jsfn/zysk
    Proporcja liniiowo, n logarytmicznie.

    Tabelka na końcu.

    Trochę mnie to dziwi. Błędu w implementacji nie widzę.
    czyżby znów cache i liniowy spacer po pamięci?

    Korzyść jest większa niż *2 wynikające z samej
    ilości porównań. Posortowałem też ciag posortowany
    odwrotnie. Insert zwalnia, bo wykorzystuje pesymistyczną
    liczbę porównań, select nieco przyszpiesza
    (if (tabl[i]<tabl[min]) min=i; się nie wykonuje)
    ale nadal insert jest ciut szybsze.


    pzdr
    bartekltg


    Tabelka wyników dla tablicy losowej.
    n, liczba powtórzeń, wynik dla insert, wynik dla select

    2 24999999 185 289
    3 11111110 176 226
    4 6249999 157 193
    5 3999999 142 181
    6 2777777 138 185
    7 2040816 130 192
    8 1562499 119 198
    9 1234567 110 198
    10 999999 102 195
    11 826446 95 190
    12 694444 90 184
    13 591715 84 179
    14 510204 80 174
    15 444444 77 170
    16 390624 75 166
    17 346020 71 162
    18 308641 68 158
    19 277008 66 154
    20 249999 64 152
    22 206611 61 146
    24 173611 58 140
    26 147928 55 137
    28 127550 53 132
    30 111111 51 129
    32 97656 49 126
    34 86505 47 123
    36 77160 46 121
    38 69252 45 118
    40 62499 44 116
    43 54083 42 114
    46 47258 41 111
    49 41649 40 109
    52 36982 39 107
    55 33057 39 104
    58 29726 38 104
    61 26874 37 101
    65 23668 36 99
    69 21003 35 98
    73 18765 34 97
    77 16866 34 95
    81 15241 34 94
    86 13520 33 92
    91 12075 33 91
    96 10850 32 90
    101 9802 31 89
    107 8734 31 88
    113 7831 31 88
    119 7061 30 85
    125 6399 30 85
    132 5739 30 84
    139 5175 30 83
    146 4691 29 83
    154 4216 29 81
    162 3810 29 81
    171 3419 28 79
    180 3086 27 79
    190 2770 28 78
    200 2499 28 77
    211 2246 27 77
    222 2029 27 76
    234 1826 27 76
    246 1652 27 75
    259 1490 26 75
    272 1351 26 75
    286 1222 26 74


  • 22. Data: 2012-10-13 14:16:54
    Temat: Re: sortowanie
    Od: PK <P...@n...pl>

    On 2012-10-13, Edek Pienkowski <e...@g...com> wrote:
    > Nie wiedzieć czemu w edukacji stosuje się sortowanie do nauczania
    > algorytmów. Poza złożonością obliczeniową sortowanie nie nadaje się
    > na przykład czegokolwiek.

    Pomijając już kwestię tego, że sortowanie oczywiście JEST dobrym
    tematem w edukacji (z wielu powodów), to jest także jednym z bardziej
    istotnych problemów praktycznych. Zatem nauczyć go i tak trzeba.

    pozdrawiam,
    PK


  • 23. Data: 2012-10-13 14:27:46
    Temat: Re: sortowanie
    Od: PK <P...@n...pl>

    On 2012-10-13, Michoo <m...@v...pl> wrote:
    > Jeżeli dobrze widzę to i insertion i selection może być stabilny.

    *Każdy* algorytm sortowania można uczynić stabilnym. Rzecz w tym, że
    część są stabilna od razu, a w niektórych wymaga to małych nakładów.
    I są też takie, z którymi walczyć nie warto :).

    pozdrawiam,
    PK


  • 24. Data: 2012-10-13 14:46:27
    Temat: Re: sortowanie
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 13 Oct 2012 13:52:31 +0200, Michoo napisal:

    > On 13.10.2012 11:27, Edek Pienkowski wrote:
    >> Dnia Fri, 12 Oct 2012 21:08:36 +0200, Michoo napisal:
    >>
    >>> Nie wiedzieć czemu w edukacji stosuje się bąble do nauczania na samym
    >>> poczatku, mimo, że zasada działania jest świetnym przykładem "jak nie
    >>> projektować algorytmów". A potem licealiści/studenci na pytanie o
    >>> najprostszy algorytm sortowania odpowiadają "bąbelki"...
    >>
    >> Nie wiedzieć czemu w edukacji stosuje się sortowanie do nauczania
    >> algorytmów. Poza złożonością obliczeniową sortowanie nie nadaje się
    >> na przykład czegokolwiek.
    >>
    > Dlaczego? Mamy dane wejściowe, mamy predykat do spełnienia na wyjściu,
    > mamy opis operacji, czyli algorytm. Łatwe do zrozumienia, łatwe do
    > prezentacji, łatwe do sprawdzenia poprawności.
    >
    > Co Ty byś proponował do nauki algorytmów?

    Coś co ma "contraints" do spełnienia [1], najlepiej nietrywialne [2]; może
    być wykres Gannta z zadań, ale niektóre uczelnie preferują np. peephole.
    Budowanie wykresu Gannta czy raczej samego przypisania może mieć
    nietrywialne raguły typu "jeden z programistów, taki Edek [3], rzyga na
    widok sortowania, więc niektóre zadania trzeba przypisać innej osobie".
    Peephole natomiast uświadomiłoby niektórym "dzieciom Javy po studiach", że
    JVM opiera się na modelu (trudne słowo przed nami, ech) procesora i że
    tak, Java jest interpretowana.
    Dodatkowym wnioskiem z zastosowania "constraints" jest uświadomienie sobie
    różnicy pomiędzy "zawsze możliwym", "czasami możliwym"
    i "niemożliwym" i odwrotności - spotkałem programistów, którzy tej logiki
    w zaawansowanym umysłowo wieku jeszcze nie rozpracowało, przez co nie
    rozumie zdania "to niemożliwe", albo "w niektórych przypadkach to nie
    zadziała, pomimo tego że w testowanych działa", albo "do tego fragmentu
    nie potrzeba unit testów, bo masz dowód" połączone z "nawet jeżeli
    napisane testy przejdą, po każdej zmianie trzeba od nowa przeprowadzić
    dowód". To ostatnie stosuje się m.in. do algorytmów wielowątkowych, ale
    tak naprawdę takie potoczne programistyczne "rozpatrzenie wszystkich
    możliwości" jak i na przykład refactoring opierają się na logice
    constraints, trzeba umieć je składać, negować itd. .

    Nie zaczynałbym edukacji od "zobacz, na ile możliwości można zrobić coś
    tak banalnego jak sortowanie, jakie piękne metody".

    [1] Gdyby ktoś mi zapodał polskie słowo będę wdzięczny,
    ja mam tylko "ograniczenia". Constraints to moje ulubione podejście do
    pisania programów w ogólności, _w pewnym sensie_ spełnienie wymagań,
    zachowanie integralności sprzętu i inne takie oczywistości jak czas
    implementacji można widzieć jako "constraints" - pisanie oprogramowania ma
    je wszystkie spełniać i to jest pełna definicja jeżeli mamy dane wszystkie
    "constraints".

    [2] Stabilność sortowania - trywialne, w sensie mało złożone, pomijam
    fakt, że algorytm może zmienić nietrywialnie

    [3] Udało mi się do dziś uniknąć znajomości quick-sorta. Jak ktoś
    chce z tego faktu wyciągać daleko idące wnioski na temat mojego
    zrozumienia algorytmów - proszę bardzo. Po pierwsze, mi się
    nie chce, po drugie, ja wciąż potrafię znaleźć szukanie O(n)
    mediany znając tylko wybrane właściwości quick-sorta.

    --
    Edek


  • 25. Data: 2012-10-13 14:49:08
    Temat: Re: sortowanie
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 13 Oct 2012 12:16:54 +0000, PK napisal:

    > On 2012-10-13, Edek Pienkowski <e...@g...com> wrote:
    >> Nie wiedzieć czemu w edukacji stosuje się sortowanie do nauczania
    >> algorytmów. Poza złożonością obliczeniową sortowanie nie nadaje się na
    >> przykład czegokolwiek.
    >
    > Pomijając już kwestię tego, że sortowanie oczywiście JEST dobrym tematem w
    > edukacji (z wielu powodów), to jest także jednym z bardziej istotnych
    > problemów praktycznych. Zatem nauczyć go i tak trzeba.

    Jestem chodzącym przykładem, że nie trzeba. Ja wyłącznie używam sorta,
    od czasu do czasu potrzebuję innego sorta. Jeżeli gadam z autorem
    któregoś z algorytmów sortowania (od zera, nie złożenia), to "szacun".

    --
    Edek


  • 26. Data: 2012-10-13 15:13:24
    Temat: Re: sortowanie
    Od: bartekltg <b...@g...com>

    W dniu 2012-10-13 14:46, Edek Pienkowski pisze:
    > Dnia Sat, 13 Oct 2012 13:52:31 +0200, Michoo napisal:
    >
    >> On 13.10.2012 11:27, Edek Pienkowski wrote:
    >>> Dnia Fri, 12 Oct 2012 21:08:36 +0200, Michoo napisal:
    >>>
    >>>> Nie wiedzieć czemu w edukacji stosuje się bąble do nauczania na samym
    >>>> poczatku, mimo, że zasada działania jest świetnym przykładem "jak nie
    >>>> projektować algorytmów". A potem licealiści/studenci na pytanie o
    >>>> najprostszy algorytm sortowania odpowiadają "bąbelki"...
    >>>
    >>> Nie wiedzieć czemu w edukacji stosuje się sortowanie do nauczania
    >>> algorytmów. Poza złożonością obliczeniową sortowanie nie nadaje się
    >>> na przykład czegokolwiek.
    >>>
    >> Dlaczego? Mamy dane wejściowe, mamy predykat do spełnienia na wyjściu,
    >> mamy opis operacji, czyli algorytm. Łatwe do zrozumienia, łatwe do
    >> prezentacji, łatwe do sprawdzenia poprawności.
    >>
    >> Co Ty byś proponował do nauki algorytmów?
    >
    > Coś co ma "contraints" do spełnienia [1], najlepiej nietrywialne [2]; może
    > być wykres Gannta z zadań, ale niektóre uczelnie preferują np. peephole.
    > Budowanie wykresu Gannta czy raczej samego przypisania może mieć
    > nietrywialne raguły typu

    Weekend jest i pewnie z t ej okazji nic nie rozumiem:)
    Pytanie było, jakie algorytmy dałbyś na początek nauki.

    pzdr
    bartekltg


    > [1] Gdyby ktoś mi zapodał polskie słowo będę wdzięczny,
    > ja mam tylko "ograniczenia".

    'Ograniczenia' jest ok, poza tym 'więzy', albo zwyczajnie
    warunki do spełnienia.




  • 27. Data: 2012-10-13 15:13:26
    Temat: Re: sortowanie
    Od: PK <P...@n...pl>

    On 2012-10-13, Edek Pienkowski <e...@g...com> wrote:
    > Jestem chodzącym przykładem, że nie trzeba. Ja wyłącznie używam sorta,

    Tu chyba nie chodzi o to, kto jest czego przykładem.
    Chodzi o statystykę. Sortowanie jest pewnie drugą (po wyszukiwaniu)
    najczęściej wykorzystywaną rodziną algorytmów.

    > od czasu do czasu potrzebuję innego sorta. Jeżeli gadam z autorem
    > któregoś z algorytmów sortowania (od zera, nie złożenia), to "szacun".

    Nie wiem co to znaczy "któregoś", bo takich rzeczy jeszcze nie
    publikowałem, ale tak: miałem kilka razy w życiu przyjemność (powiedzmy)
    wyklepania sortowania od zera. Podobnie jak miałem kilka razy w życiu
    jeszcze większą przyjemność (znowu: powiedzmy) pisania własnych RNG,
    własnych bardzo złożonych struktur, własnych bibliotek do obliczeń itp
    itd. Ale oczywiście nie będę tego używał jako argumentu "za" nauką
    sortowania, bo to by było przynajmniej niepoważne :).

    Ale studentów nie męczy się agorytmiką po to, żeby pisali własne
    sortowania, generatory, drzewa itp. Po prostu trzeba ich nauczyć
    poprawnego wykorzystywania gotowych algorytmów, bo błędy na tym
    poziomie potrafią uwalić cały projekt (np. publikację naukową -
    pełno jest cudownych "odkryć" wynikających z tego, że poważny
    naukowiec pisał w C++ i użył rand() niczym 14-latek na sprawdzianie).

    pozdrawiam,
    PK


  • 28. Data: 2012-10-13 15:26:16
    Temat: Re: sortowanie
    Od: kenobi <p...@g...com>

    >
    > Ale wróćmy do selectsort i insertsort.
    >
    >
    >
    > Napisałem palce obie wersje(specjalnie dla fira, prawie c):
    >
    >
    >
    > void insertsort(int * tabl,int first, int last)
    >
    > {
    >
    > for (int j = first+1;j<=last;j++) //pierwszy nieposortowany
    >
    > {
    >
    > int i=j;
    >
    > int temp = tabl[j];
    >
    > while ((i>first) && temp<tabl[i-1])
    >
    > {
    >
    > tabl[i]=tabl[i-1];
    >
    > i--;
    >
    > }
    >
    > tabl[i]=temp;
    >
    > }//for
    >
    > }
    >
    >
    >
    >
    >
    >
    >
    > void selectsort(int * tabl,int first, int last)
    >
    > {
    >
    > for (int j=first; j<last; j++)
    >
    > {
    >
    > int min = j;
    >
    > for (int i=j+1;i<=last;i++)
    >
    > {
    >
    > if (tabl[i]<tabl[min]) min=i;
    >
    > }
    >
    > int temp = tabl[min];
    >
    > tabl[min]=tabl[j];
    >
    > tabl[j]=temp;
    >
    > }//for
    >
    > }
    >
    >
    >
    >
    no moge rzucic okiem, ale pozniej - ostatnio pisalem asembler/kompilator b, i jestem
    zdeczko
    zmeczony
    (pominawszy znowu koszmarne sampoczucioe zdrowotne (w zwiazku z paskudnymi bolami rak
    po kleszczu i reszta (tj zatruciem bebechow syfiastymi lekami i zatruciem ukl
    oddechowego -
    czuje sie troche zbyt beznadziejnie by teraz
    rzucic okiem)


  • 29. Data: 2012-10-13 15:32:50
    Temat: Re: sortowanie
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 13 Oct 2012 13:13:26 +0000, PK napisal:

    > Ale studentów nie męczy się agorytmiką po to, żeby pisali własne
    > sortowania, generatory, drzewa itp. Po prostu trzeba ich nauczyć
    > poprawnego wykorzystywania gotowych algorytmów, bo błędy na tym poziomie
    > potrafią uwalić cały projekt (np. publikację naukową -
    > pełno jest cudownych "odkryć" wynikających z tego, że poważny naukowiec
    > pisał w C++ i użył rand() niczym 14-latek na sprawdzianie).

    Ja od zawsze uważam, że jeżeli studentów można mniej męczyć ucząc nawet
    tyle samo, to od tego będą umieli więcej a nie mniej. Nie rozumiem
    usprawiedliwiania "męczenia" czymkolwiek. Jak się da studentowi
    odpowiednio trudny temat, to sam będzie się musiał namęczyć. Czyli:
    "podstępem go!" ;)

    Z resztą się zgadzam, ale sortowanie != algorytmika (odwróć nierówność a
    będzie jasne). No i taki rand() ma właściwości matematyczne,
    z algorytmiką ma to wprost mało wspólnego.

    --
    Edek




  • 30. Data: 2012-10-13 15:36:08
    Temat: Re: sortowanie
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 13 Oct 2012 15:13:24 +0200, bartekltg napisal:

    > W dniu 2012-10-13 14:46, Edek Pienkowski pisze:
    >> Dnia Sat, 13 Oct 2012 13:52:31 +0200, Michoo napisal:

    >>> Co Ty byś proponował do nauki algorytmów?
    >>
    >> Coś co ma "contraints" do spełnienia [1], najlepiej nietrywialne [2]; może
    >> być wykres Gannta z zadań, ale niektóre uczelnie preferują np. peephole.
    >> Budowanie wykresu Gannta czy raczej samego przypisania może mieć
    >> nietrywialne raguły typu
    >
    > Weekend jest i pewnie z t ej okazji nic nie rozumiem:)
    > Pytanie było, jakie algorytmy dałbyś na początek nauki.

    Podkreślić powyżej dwa przykłady ;)?

    > > [1] Gdyby ktoś mi zapodał polskie słowo będę wdzięczny,
    > > ja mam tylko "ograniczenia".
    >
    > 'Ograniczenia' jest ok, poza tym 'więzy', albo zwyczajnie
    > warunki do spełnienia.

    To ostatnie jakoś brzmi, o ile nie mówi się o "constraints",
    które mają być naruszone - warunki do niespełnienia?

    --
    Edek

strony : 1 . 2 . [ 3 ] . 4 ... 10 ... 50 ... 57


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: