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

Settle Your Debt Sweepstakes!
Download Attachments
    Prev | Next | Inbox
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
Add Addresses

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"); 
>> >> >> >>>}
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>        
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>        
>> >> >> >>>        
>> >> >> >>>          
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> 
>> >> >> 
>> >> >
>> >> 
>> >> 
>> >
>> 
>> 
>
>

     Prev | Next | Inbox
Download Attachments

Yahoo! Messenger - Send instant messages to your online friends.
Address Book · Alerts · Auctions · Bill Pay · Bookmarks · Briefcase · Broadcast · Calendar · Chat · Classifieds · Clubs · Companion · 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-2000 Yahoo! Inc. All rights reserved.