Buguri la concursurile de programare si nu numai

[•QSilver]

Am avut si eu probleme la OJI 2011 tot cu int in loc de short si -100 de puncte.

[•andunhill]

Cel mai enervant bug: for(i = N; i >= 1; i++)  .

[•swim406]

din instinct am dat un ctrl+s , insa nu am observat ca de fapt apasasem s + ctrl + s , si astfel am salvat sursa cu un s in plus. Asta a facut diferenta de la 80 la  0 puncte ).

De asta nu m-am calificat eu anul trecut la ONI. Am zis că nu mai apăs ctrl+s în veci la concursuri. )

[•a_h1926]

Aveti grija cu numele constantelor, eu am pierdut 80 de puncte la o problema chiar acum la ONI pentru ca in loc sa declar un arbore de intervale AInt[3*XMax] l-am declarat AInt[3*NMax], unde XMax era 100005 si NMax era 805   
In acest fel, in loc sa fiu pe locul 6, am ajuns pe 14, asa ca fiti foarte atenti la lucruri de genul acesta, pot costa foarte scump.

[•S7012MY]

Int in loc de long long. Depasirea poate fi mare iar numarul sa fie pozitiv iar rezultatul sa para bun )

[•S7012MY]

Grija mare tot la long long cand faceti descompuneri. Codul urmator cicleaza cand incerc sa descompun un numar prim foarte mare:
http://community.topcoder.com/stat?c=problem_solution&rm=312577&rd=14732&pm=11135&cr=22895893

Am pierdut niste bani din cauza asta 

[•MciprianM]

Tot int in loc de long long  La variabila i

[•S7012MY]

Tot int in loc de long long  La variabila i

N-ar fi afectat daca faceam descompunerea cum trebuie

[•MciprianM]

Ce nu inteleg e de ce te zgarcesti la o variabila? Crezi ca faci economie? De regula, intr-o problema in care e necesar sa am o variabila long long, le fac toate long long, ca sa ma asigur ca nu am probleme legate de domeniul de valori al variabilei. Exceptie fac sirurile care pot duce la "Limita de memorie depasita". Acolo, intai fac un calcul sa vad daca imi ajunge memoria, si daca nu imi ajunge sau daca cred ca daca folosesc mai putina memorie imi va imbunatati sesizabil viteza de executie a programului (adica daca imi cresc sansele sa prind teste in plus), atunci folosesc int (bineinteles doar daca valorile incap pe int), iar mai apoi urmaresc cu atentie toate locurile in care folosesc sirul respectiv ca sa nu am probleme. In general, cu cat e mai simplu codul, cu atat mai bine. Nu are rost sa te complici pentru cativa bytes in plus sau in minus.

P.S.: Cum faceai descompunerea "ca sa fie bine"?

[•klamathix]

Deseori te omoara timpul rau de tot daca faci toate operatiile pe long long  .

[•pauldb]

Grija mare tot la long long cand faceti descompuneri. Codul urmator cicleaza cand incerc sa descompun un numar prim foarte mare:
http://community.topcoder.com/stat?c=problem_solution&rm=312577&rd=14732&pm=11135&cr=22895893

Am pierdut niste bani din cauza asta 

O alta greseala comuna si inrudita e la ciurului lui Eratostene:

Cod:

for (int i = 2; i <= n; ++i) {
   if (prime[i]) {
     for (long long j = (long long) i*i; j <= n; j += i) {
       prime[j] = 0;
   }
}

Daca nu pui acolo long long pentru n = 65 000 deja programul cicleaza. Ma rog, mai exista si alte moduri elegante de a evita asta (gen i*i <= n), dar am vazut ca lumea tinde sa faca asa. Fiti atenti.

[•S7012MY]

Ce nu inteleg e de ce te zgarcesti la o variabila? Crezi ca faci economie? De regula, intr-o problema in care e necesar sa am o variabila long long, le fac toate long long, ca sa ma asigur ca nu am probleme legate de domeniul de valori al variabilei. Exceptie fac sirurile care pot duce la "Limita de memorie depasita". Acolo, intai fac un calcul sa vad daca imi ajunge memoria, si daca nu imi ajunge sau daca cred ca daca folosesc mai putina memorie imi va imbunatati sesizabil viteza de executie a programului (adica daca imi cresc sansele sa prind teste in plus), atunci folosesc int (bineinteles doar daca valorile incap pe int), iar mai apoi urmaresc cu atentie toate locurile in care folosesc sirul respectiv ca sa nu am probleme. In general, cu cat e mai simplu codul, cu atat mai bine. Nu are rost sa te complici pentru cativa bytes in plus sau in minus.

P.S.: Cum faceai descompunerea "ca sa fie bine"?

Multumesc de sfat. E foarte tare ca il dau si eu, dar nu il aplic. O sa incerc sa tin cont de el

Descompunerea clasica pana la radical din numar

[•MciprianM]

Deseori te omoara timpul rau de tot daca faci toate operatiile pe long long  .

Intr-adevar, dureaza cu pana la 150% mai mult la inmultire si cu 100% mai mult la adunare daca faci asa:

Cod:

long long v = 0, i;
for (i = 0; i <= 1000000000; ++ i) {
    v = v + i;
}

fata de asa:

Cod:

int v = 0, i;
for (i = 0; i <= 1000000000; ++ i) {
    v = v + i;
}

Dar dureaza cu 83% mai mult la adunare si 24% mai mult la inmultire daca faci asa:

Cod:

long long v = 0, i;
for (i = 0; i <= 1000000000; ++ i) {
    v = v + i;
}

fata de asa:

Cod:

long long v = 0;
int i;
for (i = 0; i <= 1000000000; ++ i) {
    v = v + i;
}

Daca programul tau e la limita, intr-adevar conteaza optimizarile astea, dar daca nu consuma nici macar jumatate sau o treime din limita de timp, de ce sa te complici?
(Pe topcoder limita e de 2 secunde cam la toate problemele, desi 0.1 secunde ar fi arhisuficient la majoritatea).