Programátorský úkol

[D.A. Tiger]

Obrovsky dik za odkaz na www.codewars.com

[Reklama]

[Aoidhghean]

nic moc, ale 10sek rozmyslania a 10min pisania:

Kód: [Vybrat]

#include <stdlib.h>

int *gen(int m, int n) {
int *out =  new int[m * n];
for (int i = 0; i < m * n; ++i) {
out[i] = i;
}
return out;
}

int main() {
int m = 1000, n = 1000;
int stride = m;
int *arr = gen(m, n);
int *res = new int[m * n];
int pos = 0;
int x = -1;
int y = 0;
int d = 1;
--n;
while (m || n) {
for (int i = 0; i < m; ++i) {
x += d;
res[pos++] = arr[x + y * stride];
}
if (m) --m;
for (int i = 0; i < n; ++i) {
y += d;
res[pos++] = arr[x + y * stride];
}
if (n) --n;
d *= -1;
}
delete res;
delete ar
return 0;
}


To by u zkoušky neprošlo.

[borekz]

Stačilo by d = -d.

[noef]

Jak pise cumil, v praxi predcasna optimalizace jen skodi - ve vetsine pripadu je totiz zcela zbytecna, protoze realne bottlenecky byly/jsou jinde (napr. db, disk, sit). Optimalizaci se akorat zavlece spousta chyb a celkove cena bude vyrazne vyssi. Nevim, co resite s knihovnami, me reseni, ktere lze zkratit takto (mozna to pujde i vic):

Kód: [Vybrat]

import Data.List
snakeWalk (x:xs) = x ++ snakeWalk (reverse $ transpose xs)
snakeWalk [] = []
Pouziva to jen std. knihovnu, je to velmi citelne na rozdil od tech rucnich prochazeni matici, a pro zadana data to nebude mit snad ani meritelny horsi vykon oproti tem "optimalnim" necitelnym resenim (v zadani neni pozadavek na rychlost/pametovou narocnost; navic nekdo pokrocilejsi uvdel nejakou knihovnu, ktera mozna resi i ten problem s vykonem). Take k tomuto kodu nemusim pomalu psat testy, nebo jen velmi malo. Kdyz caruji s indexy, bodam na pameti a mam nekolik vetvi, tak bude potreba dost testu, abych si byl jisty, ze to opravdu funguje vzdy. A svete div se, ne vsude se testuje (nekde jsou dokonce testy prisne zakazane jako ztrata casu), tam je pak muj naivni FP pristup nejvhodnejsi, protoze kod je tak kratky, ze sance na chyby je mala (vzpominam na studie, ze pocet bugu roste se delkou [znaky/radky] zdrojaku).

PS: Za nepouziti knihoven a matlani si hranatych kol se bezne vyhazuje. Bavime se snad o praci, ne o skole, ne?

[Lord Zoidberg]

Jak pise cumil, v praxi predcasna optimalizace jen skodi - ve vetsine pripadu je totiz zcela zbytecna, protoze realne bottlenecky byly/jsou jinde (napr. db, disk, sit). Optimalizaci se akorat zavlece spousta chyb a celkove cena bude vyrazne vyssi.
...  Bavime se snad o praci, ne o skole, ne?

Myslim, ze jde hlavne o to zamyslet se nad danym pouzitim. Kolega napsal krasny parser souboru presne timto minimalstickym (pythonickym) stylem. Fungovalo to na testovaci priklady do 100MB. Soubory ktere zkoumame maji 8GB a vic, pythonicky parser nacita data nekolik hodin.  FORTRANicky napsany parser to zvladne za par minut.  Myslite, ze nekdo jiny krome autora toho pythonickeho parseru jej oceni? Ne, protoze takovy program je k nicemu.

[Reklama]

[Filip Jirsák]

Jak pise cumil, v praxi predcasna optimalizace jen skodi - ve vetsine pripadu je totiz zcela zbytecna, protoze realne bottlenecky byly/jsou jinde (napr. db, disk, sit). Optimalizaci se akorat zavlece spousta chyb a celkove cena bude vyrazne vyssi. Nevim, co resite s knihovnami, me reseni, ktere lze zkratit takto (mozna to pujde i vic):

Hezky si protiřečíte – nejprve odsuzujete předčasnou optimalizaci, a pak hned jednu předvedete (zkracování kódu).

pro zadana data to nebude mit snad ani meritelny horsi vykon oproti tem "optimalnim" necitelnym resenim (v zadani neni pozadavek na rychlost/pametovou narocnost; navic nekdo pokrocilejsi uvdel nejakou knihovnu, ktera mozna resi i ten problem s vykonem).

Vaše řešení je ovšem také nečitelné, zejména proto, že dělá něco úplně jiného, než je v zadání. V zadání není ani slůvko o otáčení matice. Jistě, lze relativně snadno dokázat, že řešení s transpozicí matice je ekvivalentní zadání, ale to už je něco, co v tom vašem řešení není vůbec vidět.

Tohle je nevýhoda školních úloh, že známe jenom malinkou část zadání, takže není možné rozhodnout, které řešení je nejlepší. Možná by to byl jen nějaký prototyp nad malými daty, takže nevadí, že pracuje s daty neoptimálně a není jasné, co dělá. Možná máme k dispozici knihovnu, která transpozici provádí tak, že nechá data na místě a změní implementaci metod, které se nad maticí volají. Nebo je možné, že „šnekovité“ procházení je jen jeden z více požadovaných průchodů maticí a další bude třeba procházení cik-cak, kde transpozice nepomůže, takže je správné implementovat různé způsoby průchodu maticí.

[noef]

Jak pise cumil, v praxi predcasna optimalizace jen skodi - ve vetsine pripadu je totiz zcela zbytecna, protoze realne bottlenecky byly/jsou jinde (napr. db, disk, sit). Optimalizaci se akorat zavlece spousta chyb a celkove cena bude vyrazne vyssi. Nevim, co resite s knihovnami, me reseni, ktere lze zkratit takto (mozna to pujde i vic):

Hezky si protiřečíte – nejprve odsuzujete předčasnou optimalizaci, a pak hned jednu předvedete (zkracování kódu).

Kdybych chtel jet na delku, tak tohle je kratsi:

Kód: [Vybrat]

import Data.List
snakeWalk2 y = case y of (x:xs) -> x ++ snakeWalk2 (reverse $ transpose xs); [] -> []

Ale asi mate castecne pravdu, moje puvodni reseni je nejlepsi z hlediska udrzovatelnosti a splneni pozadavku zadani. Tohle^ reseni je horsi, prestoze ma mene radku (ma vice znaku na radek, horsi citelnost, ale mozna z pohledu pravdepodobnosti mnozstvi chyb to vychazi lepe). Programator se IMO ma snazit nemit svuj program zbytecne dlouhy (vhodne pouziti podmineneho vyrazu, preferovani fluent interface, pouzivani FP pristupu, kde to dava smysl atd.), smozrejme, se to nesmi prehnat, aby zase neutrpela citelnost. Po pravde vice necitelne mi prijde treba if-else roztahane na 5 radku, prestoze obe vetve vraci trivialni vyraz -> po prevedeni na podm. vyraz v return je to na jeden radek misto 5, kde vice jak polovina jsou zbytecne (priklad z pouzivani JS a bezneho stylu vynucenych slozenych zavorek u if a else). Podobne case classy ve Scale (casto 1 radek) vs. ty hruzy v Jave (desitka radku a vic, protoze fieldy+gettery+settery).

pro zadana data to nebude mit snad ani meritelny horsi vykon oproti tem "optimalnim" necitelnym resenim (v zadani neni pozadavek na rychlost/pametovou narocnost; navic nekdo pokrocilejsi uvdel nejakou knihovnu, ktera mozna resi i ten problem s vykonem).

Vaše řešení je ovšem také nečitelné, zejména proto, že dělá něco úplně jiného, než je v zadání. V zadání není ani slůvko o otáčení matice. Jistě, lze relativně snadno dokázat, že řešení s transpozicí matice je ekvivalentní zadání, ale to už je něco, co v tom vašem řešení není vůbec vidět.

Tohle je nevýhoda školních úloh, že známe jenom malinkou část zadání, takže není možné rozhodnout, které řešení je nejlepší. Možná by to byl jen nějaký prototyp nad malými daty, takže nevadí, že pracuje s daty neoptimálně a není jasné, co dělá. Možná máme k dispozici knihovnu, která transpozici provádí tak, že nechá data na místě a změní implementaci metod, které se nad maticí volají. Nebo je možné, že „šnekovité“ procházení je jen jeden z více požadovaných průchodů maticí a další bude třeba procházení cik-cak, kde transpozice nepomůže, takže je správné implementovat různé způsoby průchodu maticí.

Jak jsem psal - zadani to splnuje, pro zadana data to funguje, o nejakem skalovani ci omzenenich neni v zadani ani slovo. To, co pise nekdo s parserem v Pythonu, to vidim jako chybu zadani - chybela zminka o tom, ze povaha testovacich dat neodpovida datum v produkci a take jak to ma byt rychle (asi se mely dodat testovaci data podobna tem v produkci, pripadne predepsat omezeni - napr. 1GB dat za minutu), nebo chyba na strane programatora - nedodrzeni zadani. V praxi se nesetkavam s tim, ze mam presne predepsany algoritmus (ale priznavam, ze to se muze dost lisit, asi jsem spis dev, nez programator, pracuju v male firme, na projektu doslova par lidi, klient setri jak muze a asi bude hrat roli jeste vice faktoru) - vetsinou jde o vyreseni ukolu, ne o implementaci presne zadaneho algoritmu. Stejne tak nemivam zadane vnitrni struktury, omezeni na pouzivane oprace atp. Pokud knihovna vyrazne zkrati dobu implementace, tak navrhnu jeji pouziti a ve vetsine pripadu je to schvalene (maloco z obecnych veci si opravdu musim implementovat sam).

[mon]

Skusky, ako na skole? To niekoho zaujima?

Pisal som to na dobru noc 10min o  1 v noci. Takze verim, ze su tam dake chyby.

nic moc, ale 10sek rozmyslania a 10min pisania:

Kód: [Vybrat]

#include <stdlib.h>

int *gen(int m, int n) {
int *out =  new int[m * n];
for (int i = 0; i < m * n; ++i) {
out[i] = i;
}
return out;
}

int main() {
int m = 1000, n = 1000;
int stride = m;
int *arr = gen(m, n);
int *res = new int[m * n];
int pos = 0;
int x = -1;
int y = 0;
int d = 1;
--n;
while (m || n) {
for (int i = 0; i < m; ++i) {
x += d;
res[pos++] = arr[x + y * stride];
}
if (m) --m;
for (int i = 0; i < n; ++i) {
y += d;
res[pos++] = arr[x + y * stride];
}
if (n) --n;
d *= -1;
}
delete res;
delete ar
return 0;
}


To by u zkoušky neprošlo.

[lopata]

Pisal som to na dobru noc 10min o  1 v noci. Takze verim, ze su tam dake chyby.

Kdyby jenom chyby, ten kód je úplně hrozný. Syntaxticky C++, sémanticky C. Odstrašující příklad, jak by se to nemělo dělat.

[Filip Jirsák]

Programator se IMO ma snazit nemit svuj program zbytecne dlouhy

Podstatné je tam to zbytečně (což se zároveň těžko měří). Ale stejně, jako by program neměl být zbytečně dlouhý, neměl by být ani zbytečně neefektivní. Podle mého názoru je z tohohle pohledu ta transpozice matice už za hranou (pokud by nešlo o prototyp).

smozrejme, se to nesmi prehnat, aby zase neutrpela citelnost

Já to vnímám spíš opačně – program by se měl zkrátit, pokud se tím zlepší čitelnost. A pokud se tím zlepší čitelnost, měl by se naopak prodloužit (pokud to není místo kritické na výkon). Proto by ty výše uvedené příklady, které matici procházejí pomocí cyklů, byly mnohem čitelnější, kdyby tam místo vnořených cyklů byly čtyři funkce pro procházení pole ve čtyřech směrech.

Po pravde vice necitelne mi prijde treba if-else roztahane na 5 radku, prestoze obe vetve vraci trivialni vyraz -> po prevedeni na podm. vyraz v return je to na jeden radek misto 5, kde vice jak polovina jsou zbytecne (priklad z pouzivani JS a bezneho stylu vynucenych slozenych zavorek u if a else).

Tohle já vnímám přesně opačně. Podmíněným výrazům se vyhýbám, pokud to není jednoduchá podmínka a dvě konstanty. Jinak z toho vznikají tři složité výrazy na jednom řádku, je to nepřehledné, musí se řešit priorita operátorů, špatně se to debuguje nebo upravuje. Vynechání složených závorek u triviálních výrazů považuju za chybu – už jsem viděl tolik chyb způsobených tím, že to vypadalo, že je v podmínce složený příkaz, ale on to byl jednoduchý výraz a zbytek pokračoval za ifem…

Jak jsem psal - zadani to splnuje, pro zadana data to funguje, o nejakem skalovani ci omzenenich neni v zadani ani slovo.

Ano, ale to je problém školních úloh, že zadání splňují i velmi hloupá řešení, a často naopak chytrá řešení zadání školní úlohy nesplní (přestože by se v praxi dala použít).

To, co pise nekdo s parserem v Pythonu, to vidim jako chybu zadani

Tohle je ovšem věc, kterou musí umět každý analytik, a také každý programátor, který není jen lepič kódu – rozpoznat, co v zadání je špatně nebo co by tam mohlo chybět, a případně si to se zadavatelem vyjasnit. Zadavatel vždy v zadání požaduje něco jiného, než co chce, a chce něco jiného, než co potřebuje. Ideální je, když nakonec dostane to, co potřebuje, ne to, co chtěl nebo co požadoval.

V praxi se nesetkavam s tim, ze mam presne predepsany algoritmus (ale priznavam, ze to se muze dost lisit, asi jsem spis dev, nez programator, pracuju v male firme, na projektu doslova par lidi, klient setri jak muze a asi bude hrat roli jeste vice faktoru) - vetsinou jde o vyreseni ukolu, ne o implementaci presne zadaneho algoritmu. Stejne tak nemivam zadane vnitrni struktury, omezeni na pouzivane oprace atp. Pokud knihovna vyrazne zkrati dobu implementace, tak navrhnu jeji pouziti a ve vetsine pripadu je to schvalene (maloco z obecnych veci si opravdu musim implementovat sam).

Ano, tohle je dost podstatné a moc nechápu, proč se dnes u programátorů často řeší jenom algoritmy, když už jsou stejně všechny naprogramované v knihovnách a programátor často potřebuje vědět především to, kde tu implementaci najde hotovou a hlavně jak si ověřit předpoklady té knihovny a jak ji správně propojit se svým kódem a s dalšími knihovnami.

[mon]

Pisal som to na dobru noc 10min o  1 v noci. Takze verim, ze su tam dake chyby.

Kdyby jenom chyby, ten kód je úplně hrozný. Syntaxticky C++, sémanticky C. Odstrašující příklad, jak by se to nemělo dělat.

Mal som tu pre teba nieco dlhsie rozpisane, ale nakoniec len napisem, ze zero fuck given. Bo ked takto kritizujes 10min prototyp nema zmysel nic pisat.

[KamSePodeloProgramovani]

Kam se podelo programovani? To jako fakt vyuzit lambda, list na tak trivialni ukol jako je prace s polem?! Ja bych zakazal ve skolach pythony, javy, C# a pekne se vsichni naucte prvni strukturovane programovani napr. v Cecku. Za mich mladych let se vsechno muselo psat a nebylo to od veci. Dneska kazdy napere na trivialni problem x frameworku, protoze pameti je dost tak proc bych to resil.

[noef]

Ke codewars a project euler bych doplnil jeste https://adventofcode.com (posledni verzi jsem nedelal, ale predposledni se mi hodne libila - kratke pribehy za ulohami byly skvele ) a https://www.codingame.com (to jsem moc nezkousel, ale minimalne zacatky to vypada zajimave).

[lopata]

Mal som tu pre teba nieco dlhsie rozpisane, ale nakoniec len napisem, ze zero fuck given. Bo ked takto kritizujes 10min prototyp nema zmysel nic pisat.

Podívej, ten tvůj kód je špatný. Je úplně jedno, jestli jsi ho dělal 10 minut nebo 10 hodin, pořád je stejně špatný. Takový kód nemá cenu prezentovat.

[gll]

Kam se podelo programovani? To jako fakt vyuzit lambda, list na tak trivialni ukol jako je prace s polem?! Ja bych zakazal ve skolach pythony, javy, C# a pekne se vsichni naucte prvni strukturovane programovani napr. v Cecku. Za mich mladych let se vsechno muselo psat a nebylo to od veci. Dneska kazdy napere na trivialni problem x frameworku, protoze pameti je dost tak proc bych to resil.

nechtěl bych být tvůj zaměstnavatel.