h3. Discutiile cu alti elevi si profesori
Puteti invata foarte mult de la profesori, si in special de la elevi mai experimentati! Exista foarte multe exemple de elvei pentru care a contat foarte mult pregatirea individuala, dar exista unii care au fost ajutati de pregatirea organizata, in grupuri de elevi, sub indrumarea unor profesori cu preocupari de acest gen. In cadrul pregatirilor de acest tip se discuta algoritmi, se propun probleme spre rezolvare, se discuta diversele modalitati de rezolvare, se obtin mai multe informatii despre concursuri, etc. In plus, elevii aduc in discutie diverse probleme cu care s-au intalnit in cadrul pregatirii individuale. Daca doriti sa participati la astfel de pregatiri, trebuie sa luati legatura cu alti elevi interesati de concursuri, sau cu profesori care se ocupa de pregatirea elevilor pentru olimpiade. In prezent se organizeaza pregatiri la nivel de liceu, oras, judet, etc. in anumite zone. Astfel de pregatiri cresc valoarea tuturor participantilor, deci sunt foarte importanta. Pregatirile organizate au luat amploare odata cu infiintarea centrelor de excelenta. Pentru a intra in contact cu alti elevi interesati puteti folosi "forumul infoarena":http://infoarena.ro/forum si "forumul revistei GInfo":http://ba.toptalent.ro/forum.
Puteti invata foarte mult de la profesori, si in special de la elevi mai experimentati! Exista foarte multe exemple de elvei pentru care a contat foarte mult pregatirea individuala, dar exista unii care au fost ajutati de pregatirea organizata, in grupuri de elevi, sub indrumarea unor profesori cu preocupari de acest gen. In cadrul pregatirilor de acest tip se discuta algoritmi, se propun probleme spre rezolvare, se discuta diversele modalitati de rezolvare, se obtin mai multe informatii despre concursuri, etc. In plus, elevii aduc in discutie diverse probleme cu care s-au intalnit in cadrul pregatirii individuale. Daca doriti sa participati la astfel de pregatiri, trebuie sa luati legatura cu alti elevi interesati de concursuri, sau cu profesori care se ocupa de pregatirea elevilor pentru olimpiade. In prezent se organizeaza pregatiri la nivel de liceu, oras, judet, etc. in anumite zone. Astfel de pregatiri cresc valoarea tuturor participantilor, deci sunt foarte importanta. Pregatirile organizate au luat amploare odata cu infiintarea centrelor de excelenta. Pentru a intra in contact cu alti elevi interesati puteti folosi "forumul infoarena":http://infoarena.ro/forum si "forumul revistei GInfo":http://ba.toptalent.ro/forum.
h3. Pregatirea de la locul desfasurarii probei
Desi ar putea parea bizar, acest aspect este foarte important, dar este neglijat de multe ori de catre concurenti. Aceasta pregatire consta in:
* somn odihnitor in noaptea care precede ziua concursului **(foarte important!)**
* obtinerea atitudinii mentale dorite
* prezentarea la timp in sala, cu toate obiectele necesare
Exista cateva obiecte pe care ar trebui sa le aveti la voi. In timpul concursului trebuie tinuta o evidenta drastica a timpului scurs si a celui ramas. E drept ca in general supraveghetorii anunta din cand in cand timpul care a trecut, dar e bine sa nu va bazati pe nimeni si nimic altceva decat pe voi insiva. Unii pot spune _Ei, ce nevoie am de ceas, oricum am ceasul calculatorului la indemana_. Asa e, dar e incomod sa te opresti mereu la jumatatea unei idei si sa verifici cat e ceasul schimband consola sau minimizand fereastra de lucru. In ceea ce priveste hartia de scris, ea este in mod sigur necesara. De fapt, o parte importanta a rezolvarii unei probleme este proiectarea matematica a algoritmului, lucru care nu se poate face decat cu creionul pe hartie. Pe langa aceasta, majoritatea problemelor opereaza cu vectori, matrice, arbori, grafuri, etc., iar exemplele pe care este testat programul realizat trebuie neaparat verificate "de mana". Este recomandat sa aveti mereu si hartie de matematica; este foarte folositoare pentru problemele de geometrie analitica, precum si penntru reprezentarea matricelor. Nu in ultimul rand, ar fi bine sa aveti o sticla de suc si o ciocolata; din nefericire, concursul incepe deseori cu intarziere si este bine ca foamea sau setea sa nu va preocupe in timpul rezolvarii problemelor.
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.
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.
Incepeti sa va ganditi la algoritmi cat mai buni, estimand in acelasi timp si cat v-ar lua ca sa-i implementati. Faceti, pentru fiecare idee care va vine, calculul complexitatii. Nu trebuie neaparat sa gasiti cel mai eficient algoritm, ci numai unul suficient de bun. In general, trebuie ca, dintre toti algoritmii care se incadreaza in timpul de rulare, sa-l alegeti pe cel care este cel mai usor de implementat. Daca algoritmul gasit este greu de implementat, mai cautati altul o vreme. Trebuie insa ca timpul petrecut pentru gasirea unui nou algoritm plus timpul necesar pentru scrierea programului sa nu depaseasca timpul necesar pentru implementarea primului algoritm, altfel nu castigati nimic. Deci nu exagerati cu cautarile si nu incercati sa reduceti dincolo de limita imposibilului complexitatea algoritmului. Mai ales, nu uitati ca programul nu poate avea o complexitate mai mica decat dimensiunea input-ului sau a output-ului. De exemplu, daca programul citeste sau scrie matrice de dimensiune N*N, nu are sens sa va bateti capul ca sa gasiti un algoritm mai bun decat O(N^2^). Dintre toate ideile de implementare gasite (care se incadreaza fara probleme in timp), o veti alege pe cea mai scurta ca lungime de cod.
In general, pentru orice problema exista cel putin o solutie, fie si una slaba. Sunt numeroase cazurile cand nu va vine alta idee de rezolvare decat cea slaba. De regula, cand nu aveti in minte decat o rezolvare neeficienta a problemei, care stiti ca nu o sa treaca toate testele (un backtracking, sau un O(N^5^), O(N^6^), etc.) e bine sa incercati urmatorul lucru:
* Calculati cam cat timp v-ar trebui ca sa implementati rezolvarea slaba. In acest calcul trebuie sa includeti si un timp estimativ de depanare a programului (care variaza de la persoana la persoana) si pe cel de testare. Daca sunteti foarte siguri pe voi, puteti sa neglijati timpul de testare, dar orice program trebuie testat cel putin pe exemplul de pe foaie.
* Pentru a avea sanse mai mari sa gasiti o alta solutie, este indicat sa incercati sa ignorati complet solutia slaba, sa nu o luati ca punct de plecare. Incercati sa va "goliti" mintea si sa gasiti ceva nou, altfel va veti invarti mereu in cerc.
* Daca va vine vreo idee mai buna, ati scapat de griji si va apucati de implementare (daca aveti timpul necesar).
Din acest moment, pentru varianta aleasa veti scrie programul, fara a va mai gandi la altceva, chiar daca pe parcurs va vin alte idei. Iata unele lucruri pe care e bine sa le stiti despre scrierea unui program:
* Datele de intrare se presupun a fi corecte. Aceasta este o regula nescrisa (uneori) a concursului de informatica.
* Efectul optiunilor de compilare asupra vitezei este semnificativ.
* Daca se poate, evitati lucrul cu pointeri. Programele care ii folosesc sunt mai greu de depanat si se pot bloca mult mai usor.
* Evitati lucrul cu numere reale (comparatii, impartiri, etc.), daca puteti. Operatiile in virgula mobila sunt mult mai lente.
* Alegeti-va numele de variabile in asa fel incat programul sa fie clar. Sunt permise mai mult de doua litere! Numele fiecarei proceduri, functii, variabile trebuie sa-i explice clar utilitatea. E drept, lungimea programului creste, dar codul devine mult mai limpede si timpul de depanare scade foarte mult. Ca o regula generala, claritatea programelor face mult mai usoara intelegerea lor chiar si dupa o perioada mai indelungata de timp (luni, ani). Nu trebuie nici sa cadeti in cealalta extrema. De exemplu, nu depasiti 10 caractere pentru un nume de variabila.
* Salvati programul cat mai des. Daca va obisnuiti, chiar la fiecare 2-3 linii. Dupa ce o sa va intre in reflex n-o sa va mai incomodeze cu nimic acest obicei. Au fost cazuri in care o pana de curent prindea pe picior gresit multi concurenti, iar dupa aceea nu mai este absolut nimic de facut, pentru ca nimeni nu va va crede pe cuvant ca ati facut programul si ca el mergea.
* Obisnuiti-va sa programati modular. Faceti proceduri separate pentru citirea si initializarea datelor, pentru sortare, pentru afisarea rezultatelor, etc. In general nu se recomanda sa scrieti proceduri in alte proceduri (adica e bine ca toate procedurile sa apartina direct de programul principal). Procedurile, acolo unde e posibil, nu trebuie sa depaseasca un ecran, pentru a putea avea o viziune de ansamblu asupra fiecareia in parte. Acest lucru ajuta mult la depanare.
* Rulati programul cat mai des, daca timpul va permite. In primul rand dupa ce scrieti procedura de citire a datelor. Daca e nevoie de sortarea datelor de intrare, nu strica sa va convingeti ca programul sorteaza bine, ruland 2-3 teste oarecare. E pacat sa pierdeti puncte dintr-o greseala copilareasca.
* 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 rubrica "Links":http://infoarena.ro/links.
