Inbox for mugurel_ionut@yahoo.com    Yahoo! - My Yahoo!     Options - Sign Out - Help
Mail    Addresses    Calendar    Notepad   


Download Attachments
    Prev | Next | Inbox
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


     Prev | Next | Inbox
Download Attachments

Yahoo! Messenger - Send instant messages to friends!
Address Book · Alerts · Auctions · Bill Pay · Bookmarks · Briefcase · Broadcast · Calendar · Chat · Classifieds · Clubs · Companion · Domains · Experts ·Games · Greetings · Home Pages · Invites · Mail · Maps · Member Directory · Messenger · My Yahoo! · News · PayDirect · People Search · Personals · Photos · Shopping · Sports · Stock Quotes · TV · Travel · Weather · Yahooligans · Yellow Pages · more...

Privacy Policy- Terms of Service - Guidelines
Copyright © 1994-2001 Yahoo! Inc. All rights reserved.