Infoarena Monthly 2014, Runda 9

[•Teodor94]

Runda 9 va avea loc Luni, 13 octombrie la ora 19⁰⁰.
Va uram mult succes!  

[•chiriacandrei25]

Ce nu zice in ziua de azi un elev inainte de un concurs IA :
" Sper sa nu fac prost si sa nu-mi scad ratingul "

[•Teodor94]

Runda s-a incheiat. Clasamentul este public. Asteptam primele voastre impresii!

De asemenea, felicitari tuturor participantilor!  

[•Andrei1998]

Felicitari pentru runda , problemele de azi chiar mi-au placut. Problema 4 intr-adevar era putin mai greu de implementat, dar clasica. Setul de probleme a avut o problema usoara (dar originala), deci oricine putea termina concursul cu cel putin o problema. Problema 3 a fost putin cam tehnica, dar nu mi-a displacut. In schimb, cea mai smen problema mi s-a parut Problema cu Becuri, felicitari Radu Voroneanu , foarte originala, cu idee destul de bine ascunsa si solutie elementara (chiar daca trebuia data o atentie sporita unor cazuri particulare in constructia solutiei). Keep up the good work!  

[•Teodor94]

Problemele au fost adaugate in arhiva (spor la codat!), iar pagina cu solutii este in dezvoltare. Asteptam si solutiile voastre!

[•S7012MY]

Mie nu mi-a placut runda si in general nu prea va ies reusite rundele de monthly. Din cate tin minte, nu prea se respecta planificarea(o editie pe luna): editia din 2012 s-a prelungit pana prin aprilie si acum runda 9 a ajuns la jumatatea lui octombrie. Din exterior pare ca incepeti sa intarziati

Cred ca ar trebui sa va ganditi foarte bine care e scopul concursului si daca are sens sa-l tineti (exista concursuri precum topcoder, codeforces si hackerrank care sunt mult mai reusite si foarte similare, singura diferenta substantiala e ca in general au probleme mai misto).

Legat de sistemul de punctare, nu mi se pare foarte inspirat: trebuie sa rezolvi problema simpla cel mai repede din cauza ca valoreaza la fel de mult cat problema grea. Daca ai o eroare de compilare vei fi penalizat. Nu mi se pare in regula chestia asta pentru ca exista diverse versiuni de compilatoare. De exemplu mie nu imi da eroare daca nu includ cstring pentru strlen si, desi stiu asta, cand ma grabesc sa submitez uit si sunt penalizat.

Si acum despre runda de azi si despre atitudinea organizatorilor:
Problema simpla a fost misto si mi se pare foarte educativa pentru cei care incep programarea pentru a invata sa nu faca overflow. Mi s-a parut ca a fost singura problema reusita din concurs
La problema raci nu mi s-a parut in regula incurajarea unor implementari. Consider ca atat timp cat ai o implementare corecta a algoritmului, nu ar trebui sa conteze detaliile de limbaj (cel putin nu intr-un concurs de viteza).
Atitudinea propunatorului mi se pare total gresita si aroganta.  
Daca exista surse care iau 100p inseamna ca sursa mea e gresita indiferent daca s-a uitat pe ea sau nu(nu s-a uitat atunci cand i-am spus de problema). M-as bucura daca mi-ati explica de ce ati considerat ca o sursa ca asta: http://ideone.com/o76crl nu merita sa intre in timp, iar asta da http://ideone.com/vsYPYC si in ce fel ma face asta un programator mai bun(probabil nici nu v-ati gandit ca lumea ar putea sa foloseasca stringuri, desi nu as vrea sa va acuz fara sa am dovezi).
Cred ca ati putea alege mai cu grija oamenii care se ocupa de concursuri (Cel putin ati putea sa-i educati sa scrie cat de cat ingrijit. Exprimari precum neam si ceai (nu substantivele) nu reflecta nimic pozitiv despre cel care le-a folosit)  si poate ati putea folosi munca lor in scopuri mult mai utile comunitatii.
Problema suma5 mi s-a parut a k-a (unde k tinde la infinit) problema cu arbori de intervale de pe infoarena si sunt sigur ca am mai vazut aceeasi idee in multe locuri (cred ca si aici: http://www.infoarena.ro/problema/numerex).

Sper sa nu primesc clasicul raspuns "daca nu iti place runda, nu esti obligat sa participi" deoarece mi se pare ca reflecta doar nesimtire si aroganta. Eu pornesc de la premisa ca un concurs pe infoarena va fi unul reusit si sunt dezamagit atunci cand pierd timpul cu unele runde care nu sunt reusite. In prezent exista o gramada de site-uri, iar arhiva infoarena are aproape 1500 probleme. Cred ca accentul ar trebui sa cada pe calitate si nu pe cantitate. Cand m-am apucat eu de informatica nu stiam decat de topcoder, intre timp vremurile s-au schimbat, nu mai e nevoie de al x-lea concurs de viteza pe acelasi tipar cu singura diferenta ca e mai lung si mai prost si participa lumea pe el din cauza ca e pe un site popular.

[•florin.elfus]

Mie nu mi-a placut runda si in general nu prea va ies reusite rundele de monthly. Din cate tin minte, nu prea se respecta planificarea(o editie pe luna): editia din 2012 s-a prelungit pana prin aprilie si acum runda 9 a ajuns la jumatatea lui octombrie. Din exterior pare ca incepeti sa intarziati

Cred ca ar trebui sa va ganditi foarte bine care e scopul concursului si daca are sens sa-l tineti (exista concursuri precum topcoder, codeforces si hackerrank care sunt mult mai reusite si foarte similare, singura diferenta substantiala e ca in general au probleme mai misto).

Legat de sistemul de punctare, nu mi se pare foarte inspirat: trebuie sa rezolvi problema simpla cel mai repede din cauza ca valoreaza la fel de mult cat problema grea. Daca ai o eroare de compilare vei fi penalizat. Nu mi se pare in regula chestia asta pentru ca exista diverse versiuni de compilatoare. De exemplu mie nu imi da eroare daca nu includ cstring pentru strlen si, desi stiu asta, cand ma grabesc sa submitez uit si sunt penalizat.

Si acum despre runda de azi si despre atitudinea organizatorilor:
Problema simpla a fost misto si mi se pare foarte educativa pentru cei care incep programarea pentru a invata sa nu faca overflow. Mi s-a parut ca a fost singura problema reusita din concurs
La problema raci nu mi s-a parut in regula incurajarea unor implementari. Consider ca atat timp cat ai o implementare corecta a algoritmului, nu ar trebui sa conteze detaliile de limbaj (cel putin nu intr-un concurs de viteza).
Atitudinea propunatorului mi se pare total gresita si aroganta.  
Daca exista surse care iau 100p inseamna ca sursa mea e gresita indiferent daca s-a uitat pe ea sau nu(nu s-a uitat atunci cand i-am spus de problema). M-as bucura daca mi-ati explica de ce ati considerat ca o sursa ca asta: http://ideone.com/o76crl nu merita sa intre in timp, iar asta da http://ideone.com/vsYPYC si in ce fel ma face asta un programator mai bun(probabil nici nu v-ati gandit ca lumea ar putea sa foloseasca stringuri, desi nu as vrea sa va acuz fara sa am dovezi).
Cred ca ati putea alege mai cu grija oamenii care se ocupa de concursuri (Cel putin ati putea sa-i educati sa scrie cat de cat ingrijit. Exprimari precum neam si ceai (nu substantivele) nu reflecta nimic pozitiv despre cel care le-a folosit)  si poate ati putea folosi munca lor in scopuri mult mai utile comunitatii.
Problema suma5 mi s-a parut a k-a (unde k tinde la infinit) problema cu arbori de intervale de pe infoarena si sunt sigur ca am mai vazut aceeasi idee in multe locuri (cred ca si aici: http://www.infoarena.ro/problema/numerex).

Sper sa nu primesc clasicul raspuns "daca nu iti place runda, nu esti obligat sa participi" deoarece mi se pare ca reflecta doar nesimtire si aroganta. Eu pornesc de la premisa ca un concurs pe infoarena va fi unul reusit si sunt dezamagit atunci cand pierd timpul cu unele runde care nu sunt reusite. In prezent exista o gramada de site-uri, iar arhiva infoarena are aproape 1500 probleme. Cred ca accentul ar trebui sa cada pe calitate si nu pe cantitate. Cand m-am apucat eu de informatica nu stiam decat de topcoder, intre timp vremurile s-au schimbat, nu mai e nevoie de al x-lea concurs de viteza pe acelasi tipar cu singura diferenta ca e mai lung si mai prost si participa lumea pe el din cauza ca e pe un site popular.

Perfect de acord! Pe CF, autorii sunt obligati sa puna limita de timp suficient de larga ca o solutie cu complexitate optima, dar scrisa neoptim sa treaca, chiar daca e posibil ca unele solutii cu complexitate neoptima, dar scrise cu optimizari sa treaca. Mi se pare foarte buna ideea lor, in felul asta poti pune accentul pe idee, nu pe detalii (plictisitoare dupa parerea mea) de implementare.

Sunt de acord si ca fiecare problema ar trebui sa aiba ceva unic. Concursurile si-ar pierde tot farmecul daca ar fi ceva in genul care stie mai multi algoritmi si care poate sa-i scrie mai repede. E ok prima, a doua oara, dar de la a x-a oara te plictisesti deja si isi pierde tot farmecul concursul. Respect comisiei ca isi rapeste din timp pe gratis sa organizeze... totusi nu e ok sa facem concursuri doar de dragul de a le face. De fiecare data cand am fost intr-o comisie am incercat ca problemele mele sa aduca ceva nou. Cand n-am probleme "bune", nu propun. Polonezii fac la fel: http://main.edu.pl/en. Un AC de acolo, pe o idee total noua e mult mai satisfacatoare decat un AC cand codezi acelasi lucru a x-a oara. Problemele #3 si #4 nu aveau ce cauta in concurs dupa parerea mea. In schimb, problema #2 chiar mi-a placut, cred ca asa ar tebui sa arate toate problemele de olimpiada.

[•PetcuIoan]

QQ.
Problema usoara a fost intr-adevar utila.
Citirea cu stringuri este mai lenta, infoarena este orientata in principal catre elevii de liceu care vor sa participe la olimpiada, la olimpiada poti sa-ti iei teapa daca citesti cu stringuri.
Sunt de acord ca suma5 este a N-a problema cu arbori de intevale, dar prezinta un smen pe care lumea noua nu-l prea stie.

[•klamathix]

Despre concursul de azi:

Nu e politica noastră să punem limite foarte strânse. Eu am adresat problema asta de mai multe ori și în cadrul echipei. Totuși se întâmplă ca lumea să uite să ia aspectul ăsta în considerare sau să nu reușească să facă chestia asta în mod satisfăcător. Se întâmplă și pe Codeforces, eu am luat TLE din cauza constantei la memorie (era 2). Deci chiar dacă politica oficială e ok, se poate pierde ideea pe parcurs din diverse motive. În cazul de față, recunosc că 0.3 și 500.000 e cam strâns. We'll work on it .

Comentariile lui Petru legate de comisie le las deoparte, e mai bine pentru toată lumea.

Despre Monthly in general:

Ideea cu Monthly-ul era, în mare, să avem un concurs cu frecvență mai mare în care dăm probleme insuficient de consistente (sau dificile) ca să constituie probleme de olimpiadă, dar totuși au ceva novelty sau ceva drăguț la ele. Exemplu: http://www.infoarena.ro/problema/classictask. Iar setul ar fi fost completat eventual de probleme mai de implementare sau de probleme primite de la useri. Ce s-a întâmplat e că în general lumea nu e foarte bună la estimat dificultăți (niște exemple care probabil mergeau și pe la lot http://www.infoarena.ro/problema/graf2, http://www.infoarena.ro/problema/culori4), iar în timp concursul a ajuns să aibă uneori 4 probleme cu background teoretic destul de heavy si stil asemănător cu runde de CF, deși nu asta era intenția inițială. Evident că un asemenea concurs nu e sustenabil pe perioada unui an întreg. Apar și runde în care nu sunteți mulțumiți de calitatea problemelor. Cu toate acestea cred că momentele bune au fost mai dese decât cele mai nefericite și că mare parte a comunității a avut ceva de câștigat prin participarea la concurs.

Sunt de acord că e nevoie de o discuție internă pe tema Monthly. Va avea loc și vom hotărî încotro se va îndrepta concursul.

Cât despre filozofia unei probleme bune de informatică, sunt multe de discutat. Eu fac lobby pentru awareness în legătură cu calitatea problemelor până se plictisește lumea de mine Și eu tot pe polonezi îî dau exemplu. Cu toate acestea, când vi se pare că o problemă nu aduce nimic nou, încercați să fiți mai finuți și să-i explicați autorului de ce credeți asta. Până la urmă toată lumea are intenții bune aici.

Apreciem feedback-ul vostru, vom discuta pe marginea lui . Petru, mai învață de la Elfus niște diplomație .

[•Teodor94]

In legatura cu scopul concursului Infoarena Monthly, dupa cum a mentionat si Mihai, o sa gandim mai bine directia in care ne vom indrepta cu urmatoarea editie si strategia pe care o vom aborda pentru a spori calitatea concursului.

In legatura cu runda 9, imi pare rau sa aud ca singura problema care v-a starnit interesul a fost Problema A, dar se intampla uneori ca intentiile organizatorilor sa nu aiba rezultatul mult dorit, iar setul de probleme sa nu fie apreciat. Imi asum responsabilitatea pentru problema Raci si limita de timp nu foarte stransa, dar stransa. Este insa destul de greu sa gasesti limita "perfecta" pentru o problema, mai ales cand aceasta admite mai multe solutii sau cand folosirea a doua structuri de date diferite poate produce schimbari destul de mari in timpul de executie. Nici noi nu ne dorim ca limitele de timp sa fie stranse si ne pare rau cand acest lucru se intampla. Ne vom gandi la o strategie cu ajutorul careia sa nu mai intalnim aceasta problema pe viitor.

Atitudinea propunatorului mi se pare total gresita si aroganta.

In legatura cu mesajele adresate comisiei, in calitate de organizator al acestui concurs, o sa ii multumesc lui Petru pentru atitudinea sa corecta.

[•S7012MY]

Editat de catre admin: Mesajul a fost sters intrucat nu arata decat bataie de joc si lipsa de respect din partea utilizatorului.

[•GavrilaVlad]

Desi nu am participat la concurs, pot sa spun urmatoarele despre probleme:

Problema A - simpatica, userii noi au ocazia sa afle despre problemele cauzate de overflow, iar problema acopera bine subiectul.
Problema cu becuri - o idee frumoasa si bine ascunsa, toti concurentii au ocazia de a se confrunta cu o problema ad-hoc de calitate.
Raci - idee destul de clasica, insa concurentii pot sa-si aminteasca deque-ul cu aceasta problema, si sa invete ca parsarea este utila in cazul unor limite de timp stranse si ca deque-ul din STL se misca foarte greu.
Suma5 - desi sunt 100% sigur ca am mai vazut problema asta undeva, nu sunt la fel de sigur ca toti userii au mai vazut-o. Chiar si un user mai experimentat (namely Elfus, numit aici cu acordul lui), a vazut ca implementarea lui a arborilor de intervale cu lazy update nu este 100% corecta si acum are ocazia sa remedieze aceasta problema.

Concluzia: desi problemele nu sunt toate originale sau cu idei frumoase, mi se par perfecte pentru un concurs de antrenament, cum ar trebui sa si fie Monthly, dupa parerea mea. Problemele rundei 9, desi n-ar fi potrivite pentru un concurs precum Algoritmiada sau ONI, au oferit participantilor multe situatii in care pot invata facand greseli la probleme pe care le considerau clasice, iar acest tip de concurs mi se pare la fel de important ca unul cu probleme originale din care participantii pot afla idei noi. Cred ca Monthly ar trebui sa continue pe acesta idee.

[•Maarcell]

Problemele din aceasta runda sunt interesante chiar daca nu am reusit sa particip, dar totusi putin ma irita cand sunt postate solutiile doar partial, iar apoi autorii uita sa completeze.
Nu vreau sa fiu pretentios, dar ar putea cineva macar sa descrie concis solutia pentru problema cu becuri?
Mersi mult.

[•PlayLikeNeverB4]

Am completat articolul. Spor la invatat.

[•Maarcell]

Am completat articolul. Spor la invatat.

Multumesc mult!  
Deasemeni vreau sa mentionez ca la solutia la problema Suma5, ati scris "unirea a doua noduri a si b intr-un singur nod c", dar in codul prezentat este realizata unirea a nodurilor b si c in nodul a. (o greseala de notatie presupun eu).

[•Andrei1998]

Greseala mea cand am scris solutia la problema Suma5. Am corectat, sper ca acum e bine.

[•xtreme77]

Salut ,

Nu vreau sa par insistent,sau enervant,dar as vrea sa intreb cand se va face update la rating.

Multumesc si numai bine.