W dniu niedziela, 14 października 2012 12:06:34 UTC+2 użytkownik kenobi napisał:
> W dniu niedziela, 14 października 2012 11:58:58 UTC+2 użytkownik bartekltg napisał:
>
> > W dniu 2012-10-14 05:38, M.M. pisze:
>
> >
>
> > > W dniu niedziela, 14 października 2012 01:08:13 UTC+2 użytkownik bartekltg
napisał:
>
> >
>
> > >> Pamiętaj, że aby zadziałało należy
>
> >
>
> > >> zadbać, aby nasza podprocedura robiąca
>
> >
>
> > >> sortowanie przez zliczanie na wybranych bitach
>
> >
>
> > >> sortowaniem stabilnym. A zaczynać od najmniej
>
> >
>
> > >> znaczących bitów.
>
> >
>
> > >
>
> >
>
> > > Tez by sie dalo od najbardziej znaczacych i
>
> >
>
> > > potem rekurencyjne dla dwoch pod-tablic.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Dwóch? liczymy porcjami powiedzmy po 8 bitów.
>
> >
>
> > 256 tablic w drugim kroku. 65536 w trzecim,
>
> >
>
> > 16777216 w czwartym (jeśli to inty, ostatnim).
>
> >
>
> >
>
> >
>
> > Nie, to nie jest dobry pomysł;)
>
> >
>
> >
>
>
>
> w pierwszym przejsciu liczysz histogram, czyli
> 256 offsetow, w drugim wstawiasz wzgledem tych
> ofsetow i masz zgrubnie posortowane, reszte
> podobnie lub ew merge sortem bedzie potezny
> speedup ;)

no moze mergem to nie (choc bylby speedup
wzgledem czystego merge'a bo zaoszczedza mergowi
scalania tych 256 kawalkow) tylko lepiej dalej
kasperskim w petli - nie jest to juz to samo co
czysty TLA (by tak to nazwac) ale i tak masa
speedu