To: | Cristian FRANCU <francu@cs.rutgers.edu> |
CC: | probleme@ldc.ro |
Subject: | Re: [Problemuta] |
Date: | Fri, 06 Oct 2000 19:55:15 EDT |
From: | Mihai Badoiu <mihai@mit.edu> | Block address |
|
|
Imi cer scuze pt tonul folosit mai devreme. Oricum, eu tot parerea mea
o tin.
>b si n sint absolut independente. Enuntul problemei arata asta in mod
>clar. Nu exista nici o diferenta intre sortare si problema asta. De
Este clar ca pt majoritatea numerelor b>log n, deci exista o relatie
intre
b si n, mai general intre 'expected of b' si n. La sortare sunt
independente,
b poate sa fie mai mic decat log n. Tocmai din cauza asta peste tot
vezi ca sortarea ia O(n log n) comparatii, unde comparatia ia O(b).
>asemenea comparatiile intre doua numere, pe caz general, dureaza
omega(b).
>Deci daca problema asta este n log n, sortarea este si ea n log n log
n pe
>worst case din exact aceleasi motive.
>
Sortarea nu este O(n log n log n) ci O(bn log n), tocmai ca nu mai ai
dependenta asta intre b si n. De obicei se considera b constant si este
mancat in notatia asimptotica.
>CLR este abc-ul algorithms theory. Nu mentioneaza toate modelele
>computationale, care sint mult mai multe. Pina la urma toata discutia
asta
>nici macar nu este in contradictoriu, caci este evident ca pur
teoretic
>atit sortarea cit si problema permutarilor se multiplica cu b. Multi
>teoreticieni insa realizeaza ca asta e un pic exagerat si "vin cu
>picioarele pe pamint" presupunind modele computationale in care
elimina
>b-ul cind este rezonabil sa o faci.
Da, dar tocmai asta era punctul meu. b>log n, unde log n este in
functie
de input, si din cauza asta nu poti sa zici ca o masina proceseaza log
n
biti odata.
Am dat exemplu din CLR, pt ca este cea mai cunoscuta. Am vazut multe
lucruri in domeniu, dar niciodata un model care asumeaza ca poti sa
faci O(log n) operatii in O(1). Nici modelele paralele nu asumeaza
asta.
Da, poate este putin exagerat, dar este raspunsul corect.
Imi pare rau ca am scris "o mie de cuvinte" in demonstratie, dar era
necesar din cauza ca nu ai specificat cum codezi secventa. Este chiar
mai general, ca merge si pe secvente unde un numar este functie de
numerele precedente din secventa. Nu cred ca poti sa faci demonstratia
mai simpla fara sa mai fie corecta.
inca o data, imi cer scuze pt tonul folosit anterior.
--mihai
>
>Concluzia: pe o masina care proceseaza b biti odata problema este
>omega(n). Pe una care proceseaza k biti odata este omega(nb).
>
>Toate bune,
>
>Cristi
>
>PS
>Nu trebuie sa iei CLR ca pe o biblie. Este un inceput bun, dar exista
si
>chestii nementionate. Daca nu spune cit dureaza o comparatie nu
inseamna
>ca nu avem noi voie sa mergem mai departe si sa incercam sa ne dam
seama.
>
>
>On Fri, 6 Oct 2000, Mihai Badoiu wrote:
>
>> Vezi tu, e o diferenta intre sortare si problema ta. Diferenta este
>> ca un numar poate aparea de mai multe ori si nu exista o limita
pentru
>> numere. De exemplu, sorteaza 1 si 2^10. In problema ta ai si upper
bound
>> si lower bound. Alt exemplu ca sa clarific diferenta: pt sortare
poti
>> sa spui: sorteaza n numere care se reprezinta pe b biti.
>> Tu nu poti sa spui asta la problema ta: este secventa asta de n
numere
>> pe b biti o permutare? Nu poti sa spui din cauza ca b trebuie sa fie
>> cel putin log n pt majoritatea numerelor, si n si b nu mai sunt
>> independente. Got it?
>>
>> In mare sunt 2 tipuri de algoritmi de sortare:
>>
>> 1. Algoritmii care folosesc comparatii: Aici lower boundul este
>> \Omega(n log n) comparatii. Ca sa fiu mai convingator citez:
>>
>> CLR page 172: "In Section 9.1 we shall prove that any comparison
sort
>> must make \Omega(n log n) comparisons in the worst cast to sort a
>> sequence of n elements." Vorbeshte de comparatii, nu de operatii
intr-un
>> model specific de computatie.
>>
>> 2. Algoritmii care nu folosesc: In toate boundurile pe care o sa le
>> vezi in carti (sau cel putin in cele care merita citite) v-a intra
>> inca un parametru b, care este numarul de biti necesar pt a
reprezenta
>> un numar. Aici se spera ca tu sa ai multe numere si b sa fie mic.
>> (In problema ta b depinde de n, aici nu depinde)
>>
>> Ce model standard presupune ca calculatoarele pot procesa log n biti
>> deodata? Nu exista asa ceva din cauza ca n nu este specificat si n
>> depinde de input. Altfel iti specific un n=2^poly(m) ceea ce implica
>> ca calculatorul poate sa faca poly(m) operatii in O(1).
>>
>> --mihai
>> >O mie de cuvinte ca sa exprimi ceva evident: tot ce spui tu este ca
>> >marimea input-ului este de fapt n log n si nu n, pentru ca fiecare
numar
>> >necesita log n biti pentru reprezentare. Deoarece orice algoritm
>> >trebuie sa parcurga tot inputul pentru a lua o decizie, rezulta ca
>> >problema este omega(n log n). Asta presupunind un model
computational in
>> >care calculatorul proceseaza un numar constant de biti per
operatie. Insa
>> >in acelasi model sortarea ar fi omega(n log n log n) nu? Ceva pute.
>> >
>> >Modelul computational standard presupune ca calculatoarele pot
procesa log
>> >n biti odata. Teoretic poate ca nu are prea mult sens, din moment
ce
>> >calculatoarele proceseaza un numar constant de biti odata (32 sau
64 sau
>> >128) dar practic vorbind, desi n este constant in acest caz, el
este
>> >suficient de mare (2^128) ca sa il putem asimila cu infinit pentru
99,99%
>> >din probleme, intre care si cea de fata. Pentru celelalte 0.01% din
>> >probleme poti sa aplici o teorie mai restrictiva.
>> >
>> >In conditiile astea problema devine omega(n), asa cum si bunul simt
striga
>> >la noi :)
>> >
>> >Cristi
>> >
>> >On Fri, 6 Oct 2000, Mihai Badoiu wrote:
>> >
>> >>
>> >> Nu ai dreptate. Eu numar inputurile pe care algoritmul este
practic
>> >> obligat sa le citeasca si apoi determin un lower bound al celui
mai
>> >> lung sir care trebuie sa fie citit. Voi gresiti, si v-am spus
>> >> si unde, nu este corect sa presupui ca orice numar se poate
reprezenta
>> >> printr-un numar constant de biti din cauza ca aceasta asumare
implica
>> >> n ca fiind constant. Orice model de computatie asumeaza ca
marimea
>> >> alfabetului este O(1).
>> >>
>> >> Cum ai spus tu problema este: se da un sir de n numere (nu se
precizeaza)
>> >> codificarea numerelor, hai sa presupunem ca numerele sunt scrise
in codul
>> >> binar. Folosind O(1) space (ie exista o constanta C1 pt care alg
foloseshte
>> >> cel mult C1 biti) si O(n) timp (ie exista o constanta C2 pt care
alg
>> >> foloseshte cel mult C2*n timp) recunoaste limbajul determinat
>> >> de toate permutarile de n numere pt orice n. (putem sa presupunem
>> >> ca n se da o data cu secventa, nu conteaza...)
>> >>
>> >> Poate poti sa-ti exprimi solutia care merge in O(n) timp folosind
C1
>> >> biti ca spatiu si C2*n timp, pt anumite C1, C2. De fapt spatiul
nu e
>> >> important, C2*n timp ma satisface. WLOG putem sa presupunem ca
alfabetul
>> >> este {0,1}. Ma indoiesc ca o sa reuseshti.
>> >>
>> >> In particular alg dat de <nu mai stiu cine> foloseshte 32 de biti
spatiu,
>> >> dar si timpul este tot O(1) ca practic alg nu face mai mult de
2^32=O(1)
>> >> comparatii.
>> >>
>> >> Citeste cu mai multa atentie. Poate nu m-am exprimat bine, asa ca
mai
>> >> incerc inca o data:
>> >>
>> >> 1. orice algoritm corect trebuie sa returneze 1 pt toate
permutarile.
>> >> 2. exista (n!) permutari, ie inputuri diferite.
>> >> 3. orice algoritm deterministic trebuie sa citeasca tot inputul
pt
>> >> permutarile care sunt corecte. (altfel, schimbi bitul care nu a
fost
>> >> citit si nu mai ai permutare, si algoritmul tau va intoarce
acelasi
>> >> rezultat pt un input corect si unul fals -> algoritmul nu e
corect
>> >> - aici am folosit ca fiecare # are o reprezentare unica in biti)
>> >> 4. cum sunt cel putin n! inputuri corecte diferite, cel putin
unul
>> >> (majoritatea actually) va fi \Omega(log (n!))=\Omega(n log n).
>> >> cum v-a trebui sa citeshti fiecare bit (punctul 3) algoritmul
>> >> va rula in \Omega(n log n) timp in cel mai rau caz.
>> >>
>> >> Spune cu ce pas nu eshti de acord.
>> >>
>> >> PS daca alg are access la o sursa de biti random rezultatul
ramane neschimbat
>> >>
>> >> --mihai
>> >>
>> >>
>> >> >Engleza sau romana, algoritmul functioneaza. Si este O(n). De
altfel stim
>> >> >cu totii algoritmul evident care foloseste un bit extra per
numar si care
>> >> >este O(n). Conform ce spui tu ar trebui ca _orice_ algoritm sa
fie
>> >> >omega(n log n), ceea ce nu este adevarat, in mod evident.
Greseala
>> >> >demonstratiei tale de lower bound consta in faptul ca tu numeri
>> >> >inputurile. Ceea ce trebuie sa numeri sint output-urile, care
sint numai
>> >> >doua, deci lower bound-ul are rezulta este de omega(1), evident
total
>> >> >nefolositor.
>> >> >
>> >> >Cristi
>> >> >
>> >> >On Thu, 5 Oct 2000, Mihai Badoiu wrote:
>> >> >
>> >> >> Voi asumati ca fiecare numar este O(1). Daca ar fi asa, ati
avea cel
>> >> >> mult c^O(1)=O(1) numere, si algoritmul ar merge in timp O(1).
>> >> >>
>> >> >> Oricel algoritm trebuie sa recunoasca toate permutarile. Cum
se cere
>> >> >> ca solutia sa fie deterministica, si modificand un bit se
schimba solutia
>> >> >> din 1 in 0, asta implica imputul sa fie cel mult O(n). Dar tu
trebuie
>> >> >> sa recunoshti cel putin n! inputuri diferite, si cum
log(n!)=\omega(n log n)
>> >> >> rezulta ca oricum ai reprezenta secventa cel putin una va fi
mai lunga
>> >> >> si algoritmul tau nu va merge in cel mai rau caz.
>> >> >>
>> >> >> --mihai
>> >> >> >
>> >> >> >>Yes, it is obvious that at every step at least one more #
gets into
>> >> >> >>the right position or an error is encountered, so you'll
finish in
>> >> >> >>O(n) time. However, there is a problem with this algorithm.
Do you
>> >> >> >>see it? The correct answer is "no, it cannot be done" Can
you tell
>> >> >> >>me why?
>> >> >> >>
>> >> >> >
>> >> >> > Can you write in Romanian, please?
>> >> >> > Ce e gresit, mai? Si eu aveam cam aceeasi idee, daca
erau
>> >> >> >diferente erau mici si nu mi le amintesc acum, si Cristi a
zis ca e
>> >> >> >bine.
>> >> >> >
>> >> >> >
>> >> >> > Mihai STROE
>> >> >> >
>> >> >> >
>> >> >> >>--mihai
>> >> >> >>>
>> >> >> >>>propun si eu o solutie.. bazata pe scrierea unei permutari
ca produs
>> >> >> >>>de transpozitii.. ar veni cam asa:
>> >> >> >>>
>> >> >> >>>parcurg vectorul; pentru fiecare element i:
>> >> >> >>> * fac verificarile banale ( sa nu fie <0 sau >n);
>> >> >> >>> * daca e ok, il duc pe pozitia pe care ar ocupa-o intr-o
>> >> >> >>>permutare, adica: daca v[i] = a, interschimb pozitiile i si
a;
>> >> >> >>>continui interschimbarile in acelasi mod pana cand pe
pozitia i
>> >> >> >>>ajunge numarul i sau dau de o eroare
>> >> >> >>>
>> >> >> >>>testele pentru a vedea daca nu cumva un numar se repeta
sunt:
>> >> >> >>> la interschimbare verific ca pe pozitiile pe care le
interschimb
>> >> >> >>>numere _diferite_;
>> >> >> >>> tot timpul terbuie sa am v[i]>=i (cand sunt pe pozitia i,
pe
>> >> >> >>>pozitiile 1..(i-1) se afla exact numerele 1..(i-1) ordonate
)
>> >> >> >>>
>> >> >> >>>algoritmul e liniar, memoria e o(1). liniaritatea vine din
faptul
>> >> >> >>>ca numarul de transpozitii e o(n).
>> >> >> >>>
>> >> >> >>>in caz ca nu am explicat bine, sursa e:
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>#include <stdio.h>
>> >> >> >>>
>> >> >> >>>int n, i;
>> >> >> >>>int v[1001];
>> >> >> >>>
>> >> >> >>>void citire(){
>> >> >> >>> FILE *f;
>> >> >> >>>
>> >> >> >>> f = fopen("permutare.in", "rt");
>> >> >> >>> fscanf(f, "%i", &n);
>> >> >> >>> for (i = 1; i <= n; i++)
>> >> >> >>> fscanf(f, "%i", &v[i]);
>> >> >> >>> fclose(f);
>> >> >> >>>}
>> >> >> >>>
>> >> >> >>>int ePermutare(){
>> >> >> >>> int a, b;
>> >> >> >>>
>> >> >> >>> for (i = 1; i <= n; i++){
>> >> >> >>> while (v[i] != i ){
>> >> >> >>> if (v[i] < i || v[i] > n ){
>> >> >> >>> return 0;
>> >> >> >>> }
>> >> >> >>> a = v[i];
>> >> >> >>> b = v[a];
>> >> >> >>> if (a == b){
>> >> >> >>> return 0;
>> >> >> >>> }
>> >> >> >>> v[i] = b;
>> >> >> >>> v[a] = a;
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>> return 1;
>> >> >> >>>}
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>void main(){
>> >> >> >>>
>> >> >> >>> citire();
>> >> >> >>> if (ePermutare())
>> >> >> >>> printf("E PREMUTARE !!\n");
>> >> >> >>> else printf("NU E PERMUTARE :( \n");
>> >> >> >>>}
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>
Privacy Policy-
Terms of Service
-
Guidelines
Copyright © 1994-2000
Yahoo! Inc. All rights reserved.