zravce a rychlost

[derte]

Riesil som zravce1 v jave a narazil na vela timeoutu, tak som optimalizoval, az som to vzdal s tym ze to asi ma niake rychlejsie riesenie. Po postazovani sa ostatnym som zistil, ze to nie moj program bol zly, len casovy limit boltak nizko, ze presli len Cckove(vraj aj python nebol dost rychly).
Nebolo by mozne a vhodne zvysit casovy limit(asi by stacilo aj konstante to by pomohlo pri takychto bleskovych kde je 6 nasobok stale kratsie ako sa java spamata) pre neC jazyky(ktore nie kazdy pouziva rad), alebo aspon maly warning ze prejde len C by sa zisiel, casto je timeout chybou programu a takymto neriesitelnym stavom sa strati kopa casu.

[Pascal]

No alebo teda nemat farmarsky testovac a upravovat limit podla jazyka v ktorom je riesenie? Neee, to sa tu take diat nebude

(ale btw, aj ja mam pocit ze u kspakov fici taky "C power" (a teda aj by som zacal flame ze preco je java lepsia ako c ale nemam na to cas ))

[Koniiiik]

(23.04.2012 20:01:11)Pascal Napísal:  No alebo teda nemat farmarsky testovac a upravovat limit podla jazyka v ktorom je riesenie? Neee, to sa tu take diat nebude

Súčasťou riešenia problému je aj výber nástroja (programovacieho jazyka), pomocou ktorého problém pôjde čo najefektívnejšie vyriešiť. Pokiaľ v nejakej úlohe treba čítať a vypisovať obrovské vstupy a výstupy, automaticky by mal zazvoniť zvonček, že Java nie, lebo bude šialene pomalá.

(23.04.2012 20:01:11)Pascal Napísal:  (ale btw, aj ja mam pocit ze u kspakov fici taky "C power" (a teda aj by som zacal flame ze preco je java lepsia ako c ale nemam na to cas ))

Čo ja viem, skôr mám pocit, že v poslednej dobe tá časť vedúcich, s ktorými som častejšie v kontakte, spolu so mnou nadáva na C++ a veci, ktoré má fakt zle vymyslené. d-:

Ale inak ti prudko neodporúčam púšťať sa do debát, ktorý jazyk je lepší ako nejaký iný, sú úplne od veci, zbytočné a nič neprinášajú. Zmysel by malo možno tak baviť sa o tom, ktorý jazyk je vhodnejší na akú úlohu a za akých podmienok. A pri takom rýchlostnom programovaní má C++ nespochybniteľnú výhodu v tom, že je rýchlejšie.

[USAmec]

(23.04.2012 20:27:50)Koniiiik Napísal:  Ale inak ti prudko neodporúčam púšťať sa do debát, ktorý jazyk je lepší ako nejaký iný, sú úplne od veci, zbytočné a nič neprinášajú. Zmysel by malo možno tak baviť sa o tom, ktorý jazyk je vhodnejší na akú úlohu a za akých podmienok. A pri takom rýchlostnom programovaní má C++ nespochybniteľnú výhodu v tom, že je rýchlejšie.

Pockat. Su jazyky, ktore su za kazdych podmienok horsie ako ostatne.
A vsetci vieme, ktore to su

---

este aby som nebol uplne offtopic, misof je teraz celkom zaneprazdneny,
takze tato issue nebude asi tak rychlo vyriesena.

[Koniiiik]

(23.04.2012 22:12:51)USAmec Napísal:  Pockat. Su jazyky, ktore su za kazdych podmienok horsie ako ostatne.
A vsetci vieme, ktore to su

Tak zase keď si chceš na svoju osobnú stránku iba strčiť vypisovanie aktuálneho dátumu, budeš na to zbytočne vyťahovať Django alebo GWT, všakže. d-:

[mišof]

Tak oficiálna odpoveď:

• Nebolo zamýšľané mať natoľko tesný časový limit, aby asymptoticky dobré riešenia v Jave (alebo inom jazyku) neprešli. To bola moja chyba.
• Aj žravce1, aj žravce2 momentálne majú akceptované riešenia v Jave, C# a dokonca aj Pythone. Takže nie je úplne pravda, že to v Jave nešlo
• Časť problému je čítanie vstupu. Java v tom v princípe nie je až taká strašná, to len Scanner je fakt príšerne pomalý. Akože plus sekunda len na načítanie takto veľkého vstupu. Java + vidím veľký vstup = čo už, aspoň BufferedReader.
• Druhá časť problému je, že pre žravce existujú riešenia s rovnakou asymptotickou zložitosťou, ale výrazne sa líšiace konštantným faktorom. Riešenie "usporiadam a prejdem" potrebuje v C++ tak štvrť sekundy, takže 2 sekundy pre žravce1 / 5 sekúnd pre žravce2 sa zdala byť dostatočná rezerva. Hja, nebola, niektoré riešenia, ktoré si žravce udržiavali v usporiadaných množinách, mali problémy.
• Extra limity pre rôzne jazyky nebudú. Get over it. Use the right tool for the job. Ak je dát málo, vyberiem si pre mňa pohodlnejšiu vec, ak ich je veľa, účinnejšiu. (Aj na rýchlostnom sú úlohy oboch typov.)
  

howgh