infoarena

 La Olimpiada Judeteana se va folosi acelasi compilator pentru sursele .cpp ca cel de pe infoarena?

 La OJI se va folosi borland c 3.1 :thumbdown:, in care nu poti sa aloci mai mult de 64 KB , iar cel de pe infoarena este compilator de gnu (gcc si g++) , asa ca trebuie sa fii atent la cat aloci .
  Un profesor de info imi zicea ca putem fi dati in judecata ca nu avem liceente de borland si ca ar trebui sa se puna si la OJI gcc.
Ar fi super sa puna si la OJI compilatoare de gnu, dar faza cu datul in judecata nu prea o mai cred, bc 3.1 cred ca este abandonware.
 

Din cate stiu eu, nu mai e nevoie de licenta Borland pentru a-l folosi. Au trecut deja 15 ani de la lansarea produsului. Cat despre gcc/g++ la judeteana ??? mi-am luat de mult timp gandul de la asa ceva. Daca zici vreunui profesor mai invechit ca la judeteana compilatoarele sunt antice si pline de bug-uri, o sa-ti tranteasca o replica de genul: "Dar la ce-ti trebuie mai mult?".

intr-adevar sunt de acord cu voi ca e cam nasoala treaba cu borlandu la oji. dar ganditi-va ca la urma urmei si solutia comisiei va fi facuta tot in borland. Deci dak stii computer science bine si ghicesti solutia corecta nu ar trebui sa ai probleme. Mai greu este ptr cei din comisie care vor fi nevoiti din cauza memoriei sa limiteze restrictiile foarte mult si nu va fi greu sa departajeze o solutie n log n de un n^2 ptr un n<=100 sa zicem.

eu cred ca daca e vreo problema cu limita de memorie la oji...puteti folosi si alocarea in heap  :D si ati putea sa testati timpul de executie cu clock inainte sa dati sursa comisiei..oricum bafta tuturor  :)

 Pai da' oricum ar fi mult mai bine sa puna gcc/g++ (desi ma indoiesc in viitorul apropiat). Unu la mana din motivul pe care l-a justificat Savin Tiberiu (ala cu N log N si cu N^2) , doi la mana e posibil cuiva sa-i vine o idee mai rapida si mai simpla care consuma un pic mai mult memeorie si trei la mana Borland-ul nu e doar invechit... e si plin de bug-uri....

...si 4 la mana, borland c 3.1 nu are STL  :D

da dar dak te gandesti oleaka logik cazul care l-am zis eu are cum sa existe (insa pot exista cazuri asemanatoare). De ce nu poate exista acel caz?? pentru ca dak ar exista o solutie n log n aceasta nu prea are cum sa consume memorie n^2 (ptr ca altfel ai face n^2 alocari de memorie ceea ce mareste complexitatea la n^2 si nu ar mai fi n log n) si dak nu poate consuma memorie n^2 atunci n-ul se poate mari ;). Insa ce am zis eu mai sus e doar un exemplu prost ales, ptr ca sunt aproape ca exista astfel de probleme. Succes tuturor la oji oricum si sa ne vedem cu bine la oni :D.

  agree with you  :thumbup:

Nu e o idee asa buna. heapul e si asa mai mic si declararea variabilelor in heap iti poate mari considerabil timpul de implementare. De ce zic asta?? ptr ca daca folosesti variabiile in heap tre sa renunti mai mult sau mai putin la recursivitate, si in anumite cazuri chiar se simte, de exemplu la backtracking, recursiv il implementezi in 2 min cu siguranta de 99% ca nu ai gresit la implementare, insa iterativ iti poate lua 10 min sa il implementezi si ink 10 min sa iti verifici greselile de implementare (poate nu e tocmai un exemplu bun dar exista si alti algoritmi care recursiv se implementeaza mult mai rapid).

Quick sort :mrgreen:. Cica e un chin sa-l scrii iterativ :D
:monkey:

ptr quick sort ai functia qsort care nu face parte din STL ;).

In heap nu ai memorie nelimitata; depinde de modelul de memorie la compilare. In far heap ai memorie nelimitata

Mda, da eu is in Pascal...  :thumbdown:. Si n-am functie qsort. Nu stiu daca nu este ceva prin help la Borland...  :-k
:monkey:

cum sa nu ?? stiu ca este. Cauta prin help qsort sau ceva de genu.

O sa caut. Nu mi-e instalat Borlandu, dar nici nu cred ca imi merge (am incercat mai demult). Totusi, la olimpiada o sa ma folosesc de qsortu din help daca am nevoie  :evil: (nu stiu daca se cere la a 7-a...  :-k )
:monkey: