Mea culpa. Am gresit eu. Scuze pt oftici 

PS : 100 fara sa renunt de STL 

Cine se mai duce la concursuri 
Cel putin la ACM nu apar probleme cu limitele stranse de timp 
Merci oricum.. back to the basics 

PS : Pascal chiar are vreo sansa?

Am nevoie si eu de lamurire 
Fac sortarea in NlogN pe un vector<pair<int,int>> si iau TLE
citire numai - 244 ms - http://infoarena.ro/job_detail/188199
citire + sortare numai - TLE - http://infoarena.ro/job_detail/188201
Daca nu intra nici cu vectoruri si cu citire din stream in timp, in pascal e chiar "impossible, like girls in stilettoes trying to run".
N-as dori sa renunt de STL si de programarea propriu-zis C++ 
Hint?

 
Mea culpa ... nu ma mai pun la debug 5 AM. Thx.

PS:

int strcmp ( const char * str1, const char * str2 );
...
A zero value indicates that both strings are equal.
A value greater than zero indicates that the first character that does not match has a greater value in str1 than in str2; And a value less than zero indicates the opposite.

Deci sursa :

Cod:

int comp(int a, int b) {
	return strcmp( m[a], m[b] );

..trebuie modificata la fel.

Iata o chestie ciudata:

Cod:

...

string K[MAX];
int N,R[MAX];

int comp(int a,int b){    
    return K[b] > K[a];
    }

int comp2(int a,int b){    
    return K[b].compare(K[a]);
    }

...

sort(R,R+N,comp);
// resetare R, R[i] =i;
sort(R,R+N,comp2);

...

prima sortare merge, al doilea pare a nu avea nici un efect asupra arrayului.
ceva idee?

Am incercat sa implementez si sa testez cateva variatii cu o solutie cu hashuri.. si anumite lucruri nu mi se par clare 
 - scanf mai repede decat getline?    am mai gasit informatii referitoare le problema, incepand cu versiunile GNU G++ 2.7.x  functiile IO din C++ sunt (mult) mai lente.. (iar testand aceeasi surse in VC++  rezultatele sunt opuse  - getline aprox. 2 ori mai rapida)..  limita e cam stransa.. oricum o solutie naiva nu se-ncadreaza in timp, deci mi se pare timpul de executie "fortata"
 - chiar daca doua valori hash asociati pt doi subsiruri sunt egali, totusi exista o sansa ca ele sa nu fie identice; de aceea, de obicei se implementeaza o testare "caracter-cu-caracter"; dar o astfel de sursa NU se incadreaza in timp...chiar daca verificarea e facuta pe baza a mai multori functii hash, solutia pierde din generalitatea sa, avand o complexitate O(N) "fortata" - si in unele cazuri chiar va fi mai optima decat KMP

Starcraft - Brood War..    De cinci ani nu m-am saturat de el.. Ah, si Baldur's Gate.. pe BG2 am terminat-o de 5 ori.. Truly addictive.. 

Coordonatele neoanelor vor fi numere intregi?

Problema Grad... Am primit fisier de iesire lipsa.. am incercat apoi si cu solutia oficiala.. aceeasi eroare. (de ce sa nu dau vina pe evaluator in loc sa-mi gasesc eu greselile  ). job 34999 (34999 e prim oare?)

Later edit: Rezolvat, prostia mea.. scuze.

Lucrez in Pascal si 65-70 era punctajul maxim pe care luasem.. O(N^2*M), am incercat si cu operatii pe biti, si fara si nu mai pot nici optimiza.. E posibil 100 cu Pascal? 

Am facut-o in Pascal si primesc TLE pe 9,10  Afisare cu for-uri, am incercat cu matrice si cu afisare directa.. tot 80. Nu-i cam strans limita pt bietul Pascal? 

Fiecare coordinata al dreptunghiurilor capa in intervalul [0..10^6] sau numai coltul stanga jos?

Cred ca a patit ceva evaluatorul. Sursele fpc nu pot fi evaluate. Da    "Blocked system call: getrlimit." pe toate. (job 19455 si 19373).

job #4692
job #4693