h2. 4. In timpul concursului

Imediat ce primiti problemele, cititi toate enunturile si faceti-va o idee aproximativa despre gradul de dificultate al fiecarei probleme. Neaparat verificati daca se dau limite pentru datele de intrare (numarul maxim de elemente ale unui vector si valoarea maxima a acestora, numarul maxim de noduri dintr-un graf, etc.) si pentru timpii de executie pentru fiecare test. Dimensiunea input-ului poate schimba radical dificultatea problemei. Spre exemplu, pentru un vecotr cu N ≤ 200 elemente, un algoritm O(N^3^) merge rezonabil, pe cand pentru N ≤ 2000 acelasi algoritm ar depasi cu mult cele cateva sutimi de secunda care se acorda de obicei. In primele zece minute (sau mai mult) nu se atinge calculatorul. Intotdeauna, cand cititi o problema, este indicat sa intoarceti foaia pentru a vedea daca enuntul continua si pe verso. De obicei, in primele 30 sau 60 de minute ale concursului pot fi adresate intrebari comisiei, pentru a clarifica eventualele ambiguitati din enunturi. Acestea sunt redactate in scris, foile sunt preluate de supraveghetorul din sala si trimise la comisie. Raspunsul s-ar putea sa intarzie, deci este indicat sa nu irositi timpul asteptand raspunsul fara a mai face nimic altceva. Puteti fie sa va ganditi la rezolvarea unei probleme, fie sa incepeti sa implementati (daca exista ceva usor de implementat, cum ar fi o problema simpla sau o rutina pentru citirea datelor de intrare). In majoritatea situatiilor, intrebarile trebuie formulate in asa fel incat raspunsul sa fie _Da_ sau _Nu__. Daca intrebarea nu este astfel exprimata sau daca raspunsul se gaseste in textul problemei, veti primi raspunsul _Fara comentarii_, caz in care va trebui mai intai sa studiati corectitudinea intrebarii si, daca aceasta este corect formulata, sa recititi enuntul problemei. Concurentii trebuie sa profite cat mai mult de aceasta perioada, pentru a clarifica eventualele nelamuriri. Un lucru important este ca nu trebuie sa acceptati raspunsuri daca acestea nu sunt insotite de semnatura unui membru al comisiei.

Imediat ce primiti problemele, cititi toate enunturile si faceti-va o idee aproximativa despre gradul de dificultate al fiecarei probleme. Neaparat verificati daca se dau limite pentru datele de intrare (numarul maxim de elemente ale unui vector si valoarea maxima a acestora, numarul maxim de noduri dintr-un graf, etc.) si pentru timpii de executie pentru fiecare test. Dimensiunea input-ului poate schimba radical dificultatea problemei. Spre exemplu, pentru un vecotr cu N ≤ 200 elemente, un algoritm O(N^3^) merge rezonabil, pe cand pentru N ≤ 2000 acelasi algoritm ar depasi cu mult cele cateva sutimi de secunda care se acorda de obicei. In primele zece minute (sau mai mult) nu se atinge calculatorul. Intotdeauna, cand cititi o problema, este indicat sa intoarceti foaia pentru a vedea daca enuntul continua si pe verso. De obicei, in primele 30 sau 60 de minute ale concursului pot fi adresate intrebari comisiei, pentru a clarifica eventualele ambiguitati din enunturi. Acestea sunt redactate in scris, foile sunt preluate de supraveghetorul din sala si trimise la comisie. Raspunsul s-ar putea sa intarzie, deci este indicat sa nu irositi timpul asteptand raspunsul fara a mai face nimic altceva. Puteti fie sa va ganditi la rezolvarea unei probleme, fie sa incepeti sa implementati (daca exista ceva usor de implementat, cum ar fi o problema simpla sau o rutina pentru citirea datelor de intrare). In majoritatea situatiilor, intrebarile trebuie formulate in asa fel incat raspunsul sa fie _Da_ sau _Nu_. Daca intrebarea nu este astfel exprimata sau daca raspunsul se gaseste in textul problemei, veti primi raspunsul _Fara comentarii_, caz in care va trebui mai intai sa studiati corectitudinea intrebarii si, daca aceasta este corect formulata, sa recititi enuntul problemei. Concurentii trebuie sa profite cat mai mult de aceasta perioada, pentru a clarifica eventualele nelamuriri. Un lucru important este ca nu trebuie sa acceptati raspunsuri daca acestea nu sunt insotite de semnatura unui membru al comisiei.

Faceti o impartire a timpului pentru problemele ramase proportional cu dificultatea aparenta a fiecarei probleme. In general problemele au punctaje egale. Incercati sa nu depasiti niciodata limitele de timp pe care le-ati fixat. Daca in schimb reusiti sa economisiti timp fata de cat v-ati propus, cu atat mai bine, veti face o realocare a timpului si veti avea mai mult pentru celelalte probleme. Apucati-va de problema **cea mai simpla**. Mai bine sa duceti la bun sfarsit o problema usoara, decat sa va apucati de o problema grea si sa nu terminati nici una. Daca toate problemele par grele, alegeti-o pe cea din domeniul care va este cel mai familiar, in care ati lucrat cel mai mult. Daca va este indiferent si acest lucru, alegeti o problema unde simtiti ca aveti o idee simpla de rezolvare.

* O situatie mai delicata apare cand fisierul de intrare contine mai multe seturi de date (teste). In acest caz, atentia trebuie sporita, deoarece daca la primul sau al doilea test programul vostru da eroare si se opreste din executie, veti pierde automat si toate celelalte teste care urmeaza. Daca in fisierul de intrare exista un singur set de date, atunci pierderea din vedere a unui caz particular al problemei nu putea duce, in cel mai rau caz, decat la picarea unui test. Asa insa, picarea unui test poate atrage dupa sine picarea tuturor celor care il urmeaza. Pe langa corectitudinea strict necesara, programul trebuie sa se incadreze is in timp pentru orice fel de test. Daca la primul sau al doilea test din suita programul depaseste timpul (sau, si mai rau, se blocheaza), e foarte probabil sa fie oprit din executie de catre comisie, deci din nou veti pierde toate testele care au ramas neexecutate.
* Tot in situatia in care exista mai multe seturi de date in fisierul de intrare, daca iesirea se face intr-un fisier, este bine ca dupa afisarea rezultatului pentru fiecare test sa actualizati fisierul de iesire. In felul acesta, chiar daca la unul din teste programul se blocheaza sau da eroare, rezultatele deja scrise raman scrise. Altfel, e posibil ca rezultatele de la testele anterioare sa ramana intr-un buffer in memorie, fara a fi "varsate" pe disc.

Tot la partea de implementare, este bine ca codul sa fie cat mai scurt si cat mai optimizat - dar, despre scrierea unui cod cat mai eficient se poate face un articol cam la fel de mare cat acesta, deci nu se va trata acest subiect aici - metoda cea mai buna in acest sens este sa invatati din sursele altora. Puteti incepe cu articolele "_12 ponturi pentru programatorii C/C++_":http://infoarena.ro/12-ponturi-pentru-programatorii-CC si "_Multe smenuri de programare in C/C++... si nu numai!_":http://infoarena.ro/Multe-smenuri-de-programare-in-CC-si-nu-numai si sectiunea "Links":http://infoarena.ro/links.

Tot la partea de implementare, este bine ca codul sa fie cat mai scurt si cat mai optimizat - dar, despre scrierea unui cod cat mai eficient se poate face un articol cam la fel de mare cat acesta, deci nu se va trata acest subiect aici - metoda cea mai buna in acest sens este sa invatati din sursele altora. Puteti incepe cu articolele "_12 ponturi pentru programatorii C/C++_":http://infoarena.ro/12-ponturi-pentru-programatorii-CC si "_Multe smenuri de programare in C/C++... si nu numai!_":http://infoarena.ro/Multe-smenuri-de-programare-in-CC-si-nu-numai si sectiunea "Links":http://infoarena.ro/links.
 
Mai ramane doar partea de depanare. O metoda buna de depanare este urmatoarea:
* Incepeti cu un test nici prea simplu, nici prea complicat (si usor de urmarit cu creionul pe hartie) si executati-l de la cap la coada. Daca merge perfect, treceti la teste mai complexe (se recomanda **minim** 4 test si maxim 7-8). Daca le trece si pe acestea, puteti zambi. Totusi, daca programul vostru a mers perfect pe 7-8 teste date la intamplare, exista sanse (dar nu extrem de mari!) sa mearga pe majoritatea testelor comisiei, sau chiar pe toate.
* Exemplul dat in enunt nu are in general nici o semnificatie deosebita (de fapt, are mai curand darul de a semana confuzie printre concurenti), iar daca programul merge pe acest test particular, nu inseamna ca o sa mearga si pe alte teste.
* Daca la unul din teste programul nu merge corespunzator, rulati din nou testul , dar de data aceasta procedura cu procedura. Dupa fiecare procedura evaluati variabilele si vedeti daca au valorile asteptate. In felul acesta puteti localiza cu precizie procedura, apoi linia unde se afla eroarea. Corectati in aceasta maniera toate erorile, pana cand testul este trecut.
* In acest moment, luati de la capat toate testele pe care programul le-a trecut deja. In urma depanarii, s-ar putea ca alte greseli sa iasa la suprafata si programul sa nu mai mearga pe vechile teste.
* Repetati procedeul de mai sus pana cand toate testele merg. Daca va obisnuiti sa programati modular si ingrijit, depanarea si testarea n-ar trebui sa dureze mai mult de 5-25 minute. Din acest moment, nu mai modificati nici macar o litera in program, sau daca o faceti pastrati-va in prealabil o copie. Nu va bazati pe faptul ca puteti sa tineti minte modificarile facute si sa refaceti oricand forma initiala a programului in caz ca noua versiune nu va fi buna.
* Daca totusi nu-i puteti "da de cap" programului, iar timpul alocat problemei respective expira, aduceti programul la o forma in care sa mearga macar pe o parte din teste si treceti la problema urmatoare.