W dniu niedziela, 14 października 2012 18:12:59 UTC+2 użytkownik bartekltg napisał:
> W dniu 2012-10-14 17:58, M.M. pisze:
>
> > W dniu niedziela, 14 października 2012 11:58:58 UTC+2 użytkownik bartekltg
napisał:
>
> >
>
> >> 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ł;)
>
> > A jakby po jednym bicie brać a nie po osmiu?
>
>
>
> I po firowemu ładować do pomocniczych tablic,
>
> zamiast użyć wersji stabilnej?
>
> Będzie o 2^7 raza gorzej, musisz przecież zapamiętać
>
> wszytko, poza jednym bitem, zamiast wszytko poza 8 bitami.
>
>
>
> Zresztą, te całe rozważania są mało sensowne:)
>
>

Imo np przy sortowaniu miliona intow najpierw
nalezy mahnac histogram po wiekszj ilosci
bitow (niz polowa) np 20 czy 22 (histogram o
milionie czy 4 milionach wpisow ) bedzie
on srednio mial 1 lub 1/4 elementu na rekord
a jakby trafilo sie wiecej to beda to
juz liczby z mniejszego zakresu (4tys lub
1 tys)
Zaleta nierownego podzalu jest to ze
posortowane listy sa krotki i maja maly
zakres

Mozesz powiedziec jak to widzisz inaczej,
troche nie che mi sie pisac tego przykladu
i testu ale jak odpoczne to moze trzasne