From: | "Mihai Patrascu" <mihai_p@pcnet.ro> | Block Address | Add to Address Book |
To: | <probleme@ldc.ro> |
Subject: | Re: probleme |
Date: | Tue, 20 Mar 2001 18:42:12 +0200 |
|
|
>
> Interesant, sint curios cum apar problemele astea. Aceasta este o
problema
> clasica de Computational Geometry, se cheama "point location".
>
Stai sa te lamuresc: asta e de la USACO winter 2001.
>
> Problema nasoala cu arborele
>
O idee directa este ca N,M<=50 deci N+M<=100. N+M e suma nivelurilor in
arbore a frunzelor, care pentru X numarul de noduri este minim XlgX.
Deci
arborele are maxim pe la 30 de frunze. Deci poti tine o matrice
A[x][n][m]
in care zici daca e realizabila configuratia cu x noduri, n de zero si
m de
unu. Pentru un X incerci toate impartirile in doi subarbori X=X1+X2.
Daca te
ingrijoreaza complexitatea, te anunt ca merg foarte bine
precalcularile...
:-) S-ar putea sa existe si metode mai bune, dar merge si asta daca nu
gasesti altceva.
>
> Chaos from order
>
Am testat diverse metode de sortare sub Linux cu egcs. Am folosit un
array
de double-uri cu intreaga mantisa generata aleator si exponentul fix
(la
jumatatea mantisei). Distributia de probabilitate era ceva gen curba
lui
Gauss (fiecare numar generat ca medie intre alte 4), ca sa nu fie
uniforma.
Array-ul avea 1046999 de elemente (numar prim, ca sa testez mai bine
algoritmii care impart sirul in doua). Iata rezultatele (liniile de cod
sunt
bineinteles o masura aproximativa; nu am numarat liniile albe):
HEAPS - 2.200 sec - 22 de linii de cod
heap sort clasic... ca in cartea lu Cata, adica :-)... functia
sift()
declarata inline
MERGE - 0.820 sec - 43 de linii de cod
merge sort... cred ca clasic... pentru N mai mic decat o valoare se
face
bubble sau insertie. Prin teste s-a determinat ca valoarea cea mai
recomandata e undeva in jur de 32.
LIBQS - 5.020 sec - 9 linii de cod
folosesc functia qsort() din biblioteca... Chiar am avut dreptate,
merge
de mai mult de 5 ori mai slab daca folosesti functia de biblioteca.
INSRT - >3 ore - 5 linii de cod
sortare prin insertie... trebia sa incerc, nu? :-)
SKIPL - 6.960 sec - 26 de linii de cod
sortez inserand elemente intr-un skiplist si la final parcurg list
in
ordine. Stiu, skiplist nu e facut pentru asa ceva. Ce am vrut sa arat e
ca e
vorba de foarte putine linii de cod si comportarea e logaritmica (desi
evident pentru o sortare nu se merita).
QSORT - 0.850 sec - 35 de linii de cod
qsort relativ clasic, doar ca pentru un N mai mic ca o constanta se
face
bubble. Valoarea cea mai recomandabila pentru constanta pare sa fie 8
(destul de putin, daca aplicam qsort pana la doua elemente se pierde
sub 5%
din performanta).
RADIX - 0.800 sec - 69 de linii de cod
radix sort in baza 256 (intai dupa mantisa, apoi dupa exponent).
Am marit dimensiunea array-ului de 6 ori si am obtinut urmatoarele
rezultate:
MERGE - 6.100 sec
QSORT - 6.740 sec
RADIX - 4.810 sec
Concluziile mele sunt ca heap-ul e bun si usor pentru N relativ mic.
Pentru
array-uri foarte mari, qsort-ul e simplu si bun. Merge-ul e ceva mai
greu,
foloseste de doua ori mai multa memorie si nu merge decat putin mai
bine
(bineinteles, exista si problema ca qsort-ul e nu probabilistic NlgN).
Daca
vrei cu adevarat viteza, RADIX-ul e chiar liniar.
mihai_p
Privacy Policy-
Terms of Service
-
Guidelines
Copyright © 1994-2001
Yahoo! Inc. All rights reserved.