Příspěvky

2026

Studium a uplatnění / Re:Praktická matematika

« kdy: 23. 09. 2017, 00:30:58 »

O algoritmus nejde. Jde o styl.

Pochybuju o tom, že na jakýmkoli kódu pod deset tisíc řádek můž být něco zásadního poznat.

2027

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 22:57:26 »

Jsem zvědavý na řešení od Prýmka

Ode mě nic nečekej, já žádnej algoritmickej lumen nejsu. A už vůbec se nebudu prsit nějakým řešením tady veřejně

2028

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 13:39:05 »

Myslím, že diskuse trochu ujela a je už o ničem. Nicméně někdy je dobré vědět, co se děje na pozadí,

Já to vidím tak, že jsme právě teď dojeli k tomu nejpodstatnějšímu: že totiž abstrakce není znalost o tom, jaké věci jsou "doopravdy". Není to žádná ontologie. Neznat nějakou abstrakci neznamená, že nerozumím světu. Spíš je to o pohledu na svět - když vidím součty v Excelu, můžu za tím vidět grupy. Zásadní otázka ale je, jestli mi tenhle pohled něco konkrétního přináší.

...a v tomhle já celkem souhlasím, že abstraktnější pohled ukazuje svět zase o něco zajímavější, se zase o něco jiným rozměrem. Ok, super! Ale Běžný Franta Programátor se toho nenažere

Sorry, ale když řekneš "oni to používají, jenom o tom neví", tak já (a může to být můj problém) to prostě čtu jako "oni ti prosťáčci ani neví, s čím pracují". Ale tak to prostě NENÍ. Oni můžou vědět velmi dobře, s čím pracují - a ten tvůj pohled na věc k tomu prostě nepotřebují, mají svůj pohled na věc, kterej je (pro daný účel) úplně ok.

představ si nějaký Extravurstprolog s predikáty vyšších řádů. Co můžeš očekávat, bude výpočet ekvivalentní prvořádovému Prologu nebo ne?

Máš pocit, že právě tohle je problém, který by Běžný Franta Programátor denodenně řešil?! V praxi by řešil tak maximálně to, jestli Extravurstprolog používá dostatečný množství lidí, aby to bylo jakžtakž odladěný, stabilní a našel dost odpovědí na SO

2029

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 12:56:52 »

Její práci nezlepší, když tomu bude říkat grupa, ale pracuje s grupou. A to je ta pointa - Pepa lepič může používat třeba katamorfismy, aniž by o tom věděl.

Dobře, budiž. A co z toho plyne? Proč to říkáš?

Já třeba teď momentálně když buším do klávesnice, tak možná excituju nějaký atomy v materiálu kláves. Možná jsem i spustil nějaký jánevím betarozpad aniž bych o tom věděl. A co?

2030

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 12:33:30 »

Python má dostatečně pružný typový systém, ten to umožňuje. Stačí implementovat metodu __add__

Ne, to neni pointa. Vidim, ze si nerozumime. Ale to nevadi, to se stava i v lepsi spolecnosti

2031

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 12:30:51 »

To není zavádějící, před chvilkou jsi to tvrdil o flatMap. Analogie s účetní nefunguje, nikdo netvrdí, že uživatel funkcionálního programu dojde ke kategoriím.

Nerozumel jsi mi. To tvoje "pouzivaji to, aniz by o tom vedeli" je zavadejici v tom, ze ctenari sugeruje myslenku, ze kdyby o tom vedeli, tak by se na jejich praci neco zasadne zmenilo. A to proste neni pravda.

Pokud jsi programator, ktery pochopi flatMap pro listy a pak flatMap treba pro ten Optional, tak by tvoji praci nijak moc neovlivnilo, kdybys chapal, ze to neni "pro list" a "pro optional", ale obecne pro cosi abstraktniho, co maji jakesi abstraktni properties. Ty to ve svem jazyce stejne nevyuzijes, protoze pro popis tech abstraktnich properties ve tvem jazyce stejne neni nastroj. Takze ty proste pouzivas flatMap pro list a pro Optional a to je stejne strop toho, co jsi ve svem jazyce schopen dosahnout.

Alegorie s ucetni je v tom, ze ucetni potrebuje scitat cisla. I kdyby vedela, ze scitani celych cisel je vlastne grupa, tak to jeji praci nijak nezkvalitni - porad bude scitat stejne jako scitala predtim. Jiste, je urcite super, kdyz si delnik ve sroubarne precte Vergilia v originale, jen houst! ale vic sroubu diky tomu stejne nevyrobi. Jo, bude pak "lepsim clovekem", coz urcite neni k zahozeni, ale na vyrobu sroubu to nema zadny _bezprostredni_ dopad (tady mas tu definici pojmu "bezprostredni", co jsi chtel).

2032

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 11:54:55 »

doporučuji Diskrétní matematiku od Matouška a Nešetřila

Souhlas, to je skvela kniha, ktera by mela byt pro informatiky povinnou cetbou

ale pokud vám to fyzik, který tu matematiku dobře zná, předem proseje a oddělí fyzikální zrno od matematických plev, dá se to pochopit.

Presne's uderil hrebicek na hlavicku: pokud ucitel dobre vi, o cem mluvi, a zaroven vi, co budou studenti v praxi delat, a zaroven ma chut jim to vysvetlit tak, aby to co nejlip pochopili, tak to jde jak po masle.

Problem je, ze u  spousty nasich ucitelu plati jenom prvni bod. Druhy malo kdy. A u tretiho plati nezridka primo opak: ucitel ma zadani podat to co nejsloziteji (at uz proto, aby zhoubne "oddelil zrno od plev", nebo proto, aby vypadal dulezite). Polehcujici okolnost je, ze to zhusta neni uplne chyba primo ucitele, ale spis systemu jako celku...

2033

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 11:50:38 »

No dobře tak tedy názorněji, typy řešit nemusím,

Nechtel jsem to videt nazorneji, ja vim, co a jak to dela. Ale teprve az se zacne bavit o typech, dojdeme k tomu, ze vetsina "beznych" jazyku to takhle obecne neumoznuje - protoze proste nemaji dostatecne obecny typovy system. Takze to "nic na tom neni" plati jenom tehdy, kdyz plati "vrazim tam plus a ono uz se mi to nejak secte". On ten flatMap totiz muze fungovat treba i na funkcich urciteho typu a to uz by se ti v pythonu dost blbe ilustrovalo Ze to jde na seznamech jednoduse, vime vsichni.

Takhle to nejspíš myslel i Mirek, že člověk - když není zbytí - tak nějak samospásem dojde ke kategoriím a spol., aniž by o tom věděl.

Obvykle zavadejici tvrzeni, na ktere odpovim obvyklym zpusobem: je to asi tak stejne pravdive jako tvrzeni, ze ucetni, ktera scita cisla v Excellu, dojde samospadem ke grupam, aniz by o tom vedela

2034

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 11:04:47 »

FlatMap to je tedy věda :-)

fl = reduce(lambda x,y: x + y, map(funct, list))

A jaky typ ma ten map, reduce a to +?

2035

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 11:03:59 »

S type classes to nijak přímo nesouvisí

Podle me to teda zatracene souvisi. Musis mit nejakej nastroj, kterym definujes, jake vlastnosti struktura musi mit, aby nad ni sel flatMap udelat. A tim nastrojem, ktery umozni kyzenou obecnost, jsou typeclasses Bez nich muzes flatMap fakt jenom overloadovat. Nebo bys mohl pouzit interfaces, ale to bych to API asi ani videt nechtel

2036

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 10:43:13 »

Tieto haskelizmy v jave nie su potrebne.

Java stejny problem resi pomoci interfaces. Jestli je to horsi nebo lepsi reseni, o tom by se dalo hadat roky

2037

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 10:20:06 »

Asi by bylo lepší citovat aspoň oficiální dokumentaci, internet je plný pochybných textů od ignorantů.

Ale vzdyt to cituju prave jako ilustraci toho, jak si k tomu "normalni programator" dojde. Studiem CT to neni, sorry. A ani to neni nutny.

Nicméně pravda je, že ve Swiftu se flatMap implementuje zvlášť, protože nemá higher-kinded types, pročež to v něm vůbec nejde genericky (zatím).

No dyt. To je moje pointa. "Normalni programator" to ve zcela abstraktni rovine nepotrebuje chapat, protoze jeho jazyk mu to stejne ve zcela abstraktni rovine neumoznuje pouzit. On ma proste k dispozici implementaci pro konkretni instance, typicky jenom pro jednu (seznam)  a kdyz se zadari, tak to ma *overloaded* i pro neco jinyho

Jasne ze duvod je v tom, ze jazyk nema typeclasses. Ale to je uplne jedno. O tom si muzeme povidat a snit o tom, jak jednou budou typeclasses v Jave. Zatim ale nejsou a timpadem je nasemu "normalnimu programatorovi" CT celkem k prdu

2038

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 10:02:33 »

Já myslel flatMap ve Swiftu, kde jde o obecný koncept používaný ve standardní knihovně pro mnoho tříd, nejen seznamy.

Swift neznám, takže to neumím fundovaně komentovat. Ale jak tak zběžně koukám, stejně "normální programátor" jde tou cestou, o které jsem psal - od listu se odpíchne dál. A to odpíchnutí je v "programátorských pojmech":

In other words, flatMap is specifically overloaded to deal with Optionals. It will take an array of optionals and return an array of unwrapped optionals without any nils.

https://www.natashatherobot.com/swift-2-flatmap/

Všímáš si toho jazyka? "Overloaded" (zvýraznění moje), žádná abstraktní algebra!

No nic, musím se vrátit k práci. Myslím, že si rozumíme a víc asi není proč tu slámu mlátit, ne? Měj se, dík za diskusi.

2039

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 09:57:39 »

hyeroglyfy

Sorry za grammar nazi poznámku, ale "hieroglyfy" je od řeckého "svaté písmo", proto měkké i v ἱερός. Stejně tak "hierarchie". S tvrdým y to trhá oči...

2040

Studium a uplatnění / Re:Praktická matematika

« kdy: 22. 09. 2017, 09:51:00 »

Když si teď na papír napíšeš obecný flatMap fungující se všemi typy (které poskytují flatten a fmap, přičemž nic jiného o nich nevíš), takže už jsi hodně hluboko v abstraktní algebře (a když si to nakreslíš, abys pochopil vztahy, dostaneš kom. diagram). KT vlastně jen poskytuje terminologii - když už znáš flatMap a flatten a další šaškárny, tak ti dá úvod do KT jen matematické termíny, žádné další poznatky. Lidi v tom většinou nevidí přínos, protože se abstrahuje od všeho konkrétního. Ale i jen standardizovaná terminologie je hodně šikovná věc.

No jo, to máš sice pravdu, ale takhle to funguje víceméně jenom v Haskellu V míň "akademicky čístých" jazycích neřešíš obecný flatMap, ale flatMap, který funguje víceméně jenom nad seznamy. Čili to primární, co tě zajímá, je konkrétní instance, která je triviální (mapem dostanu seznam seznamů a ten flattenuju - pochopí úplně každej).

A mimochodem, jakmile princip pochopíš nad seznamy, je už docela snadná cesta si uvědomit, že seznam je jenom jedna instance a že se to dá popsat abstraktně. Od konkrétního k abstraktnímu je vždycky snadnější a správnější cesta než naopak.

Ovšem i tak k tomu mám ještě jednu výhradu: tenhle krok většinou ten "normální" programátor ani vůbec nepotřebuje udělat, protože prostě flatMap nad ničím jiným než nad seznamem používat nebude (protože neprogramuje v Haskellu ani ničem podobným, kde by to mohl využít). Čili nejenže CT nepotřebuje, protože k abstrakci se může dostat přes konkrétno, ale on nepotřebuje ani to samotný abstraktno, docela dobře si vystačí jenom s konkrétnem