Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - zboj

Stran: 1 ... 50 51 [52] 53 54 ... 101
766
Vývoj / Re:Map vs. FlatMap
« kdy: 27. 09. 2016, 21:35:19 »
možná tam je, ale já ji nevidim, možná jsem se v tom trošku ztratil
otázka by mohla být jak pomocí (>>=) a return (když už teda chcete haskell) udělám z [1] a [2] hodnotu [1,2]
Možná jestli to nebude podobné, jako ten detail, že v Haskellu je
Kód: [Vybrat]
[1, 2, 3]
ve skutečnosti
Kód: [Vybrat]
1:2:3:[]
Na konkrétní implementaci nijak nezáleží. Streamy (např. v Javě) fungují podobně. V případě [1] a [2] stačí udělat jen "join" (aka "flatten") (což není přímá odpověď na otázku, jak to udělat pomocí >>=, ale "join" je jen x>>=id, kde id je identické zobrazení).
no a jak se to teda udělá?
Ve Swiftu:
Kód: [Vybrat]
[[1],[2]].flatMap{$0}

767
Vývoj / Re:Map vs. FlatMap
« kdy: 27. 09. 2016, 20:36:27 »
možná tam je, ale já ji nevidim, možná jsem se v tom trošku ztratil
otázka by mohla být jak pomocí (>>=) a return (když už teda chcete haskell) udělám z [1] a [2] hodnotu [1,2]
Možná jestli to nebude podobné, jako ten detail, že v Haskellu je
Kód: [Vybrat]
[1, 2, 3]
ve skutečnosti
Kód: [Vybrat]
1:2:3:[]
Na konkrétní implementaci nijak nezáleží. Streamy (např. v Javě) fungují podobně. V případě [1] a [2] stačí udělat jen "join" (aka "flatten") (což není přímá odpověď na otázku, jak to udělat pomocí >>=, ale "join" je jen x>>=id, kde id je identické zobrazení).

768
Vývoj / Re:Map vs. FlatMap
« kdy: 27. 09. 2016, 15:24:02 »
Ještě by asi bylo vhodné dodat, že nemusí jít jen o kolekce, ale že jde o hodně obecný koncept fungující i s Optional, Future apod.
Na vstupu nebo na výstupu? Já mám teda flatMap zafixováno tak, že vrací vždy kolekci. V ostatních případech se používají funkce s jiným jménem.

Abych to ještě upřesnil a ukázal na příkladu, pokud mám např. seznam [1,2,nil,3] typu [Int?] a chci odfiltrovat nil (a dostat [Int]), použiju metodu "map" Optionalu:
Kód: [Vybrat]
list.flatMap{$0.map{[$0]} ?? []}
Nenulové prvky se "vytáhnou" z Optional a udělá se z nich singleton, zatímco nil se převede na prázdný seznam, z čehož pak flatMap zase udělá seznam (joinem).
Neříkám, že ten tvůj způsob postrádá eleganci... Ale přijde mi, že jen využíváš chování flatMap, než, že by to na toto bylo určeno.

Já bych to třeba napsal takto:
Kód: [Vybrat]
map fromJust $ filter isJust seznam
Je to humpolácké, a mechanické, uznávám :-)

Každopádně, mám naučené spíše takové využití, kdy mám pole funkcí vracející pole. A nechci pole polí, ale, protože mi nezáleží na indexu, ale jen existenci, tak jen jednoúrovňové pole. Nebo když mám strom, a chci v něm najít výskyt nějakých prvků.

Takže mě oprav, na vstupu může být cokoliv, na výstupu je kolekce/pole. Nebo může být na výstupu i Future?
Jistě, na výstupu může cokoliv komplexního (přesněji jakýkoliv komplexní typ splňující monadické zákony), takže třeba Future nebo Optional, u Optional pak typ funkce bude T->T?. Nebo když to bude Future, dá se pak volání více funkcí pomocí flatMap zřetězit. Akorát by pak asi bylo lepší pojmenovat funkci "joinMap", ale to je jen terminologie, ostatně v Haskellu se tomu říká "bind" (což dává smysl pro různé typy kolekcí, kontejnerů apod.) a konvencí pro tuto operaci je >>=.

769
Vývoj / Re:Map vs. FlatMap
« kdy: 27. 09. 2016, 12:54:15 »
Ještě by asi bylo vhodné dodat, že nemusí jít jen o kolekce, ale že jde o hodně obecný koncept fungující i s Optional, Future apod.
Na vstupu nebo na výstupu? Já mám teda flatMap zafixováno tak, že vrací vždy kolekci. V ostatních případech se používají funkce s jiným jménem.

Abych to ještě upřesnil a ukázal na příkladu, pokud mám např. seznam [1,2,nil,3] typu [Int?] a chci odfiltrovat nil (a dostat [Int]), použiju metodu "map" Optionalu:
Kód: [Vybrat]
list.flatMap{$0.map{[$0]} ?? []}
Nenulové prvky se "vytáhnou" z Optional a udělá se z nich singleton, zatímco nil se převede na prázdný seznam, z čehož pak flatMap zase udělá seznam (joinem).

770
Vývoj / Re:Map vs. FlatMap
« kdy: 26. 09. 2016, 01:43:04 »
Ještě by asi bylo vhodné dodat, že nemusí jít jen o kolekce, ale že jde o hodně obecný koncept fungující i s Optional, Future apod.
Na vstupu nebo na výstupu? Já mám teda flatMap zafixováno tak, že vrací vždy kolekci. V ostatních případech se používají funkce s jiným jménem.
FlatMap je join.map a definuje se tak, aby splňovalo monadické zákony. Někdy se mu taky říká bind, ale až na terminologii je to obecný koncept vracející monadickou hodnotu a kolekce jsou jen jedna velmi specifická oblast použití.

771
Vývoj / Re:Map vs. FlatMap
« kdy: 25. 09. 2016, 16:02:26 »
Zkusim odpovedet trochu srozumitelneji, nez si to tu tradicne zvrhne a nekteri si zacnou nadavat do lopat a podobne.

map a flatMap jsou funkce/procedury vyssiho radu, v tomto pripade ve smyslu, ze jako svuj argument maji proceduru.

Funkce/procedura map dela to, ze vezme kolekci (seznam, stream, apod.) a na kazdy jeji prvek aplikuje predanou proceduru a vrati novou kolekci (seznam, stream).

Kód: [Vybrat]
Stream
.of(1, 2, 3, 4, 5)
.map(x -> x + 1)
.forEach(x -> System.out.println(x));
==> 2, 3, 4, 5, 6

Stream
.of(new int[] {1, 2}, new int[]  {3, 4}, new int[] {5, 6, 7})
.map(x -> x.length)
.forEach(x -> System.out.println(x));
==> 2, 2, 3

V prvnim pripade jsou prvky kolekce skalarni hodnoty (cela cisla), v druhem pripade jsou prvky kolekce pole (int[]), ale po kazde pro jednu hodnotu ze vstupni kolekce  vytvori pomoci predane procedury prave jednu hodnotu novou.

V pripade flatMap je to slozitejsi, protoze pro kazdou hodnotu ze vstupni kolekce je vytvorena nova kolekce hodnot (ktera muze obsahovat libovolne mnozstvi hodnot, klidne i zadnou) a tyto kolekce jsou pak spojeny v kolekci jednu.
Kód: [Vybrat]
Stream
.of(new int[] {1, 2}, new int[]  {3, 4}, new int[] {5, 6, 7})
.flatMapToInt(x -> Arrays.stream(x).map(y -> y + 1))
.forEach(x -> System.out.println(x));

==> 2, 3, 4, 5, 6, 7, 8
Stream
.of(1, 2, 3, 4, 5)
.flatMap(x -> Collections.nCopies(x, x).stream())
.forEach(x -> System.out.println(x));
==> 1, 2, 2, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 5
Ještě by asi bylo vhodné dodat, že nemusí jít jen o kolekce, ale že jde o hodně obecný koncept fungující i s Optional, Future apod.

772
Vývoj / Re:Map vs. FlatMap
« kdy: 24. 09. 2016, 17:16:45 »
flatMap je monada ;-)

map muze produkovat seznamy seznamu, pak je problem nacpat to do reduce. flatMap to vsechno vrati v jednom seznamu, kde vsechny objekty nejsou seznamy. krome toho je to monada v Haskellu, takze tim jde simulovat I/O a imperativni programco.

map -> [0,[1],[2,[3],[4]]]
flatMap -> [0,1,2,3,4]


Dvě technické: flatMap není monáda, na to nestačí (a chtěl jsem se tomuhle při vysvětlování vyhnout, když se někdo ptá na map vs. flatmap, tak mu to nepomůže.)

Ten příklad, co jsi napsal, nedává úplně smysl. Ta věc u mapu nejde v  haskellu napsat a ten výsledek flatmap ti klidně vypadne i z mapu, záleží, co na čím mapuješ.
Doplnění: monáda, když už teda, by bylo "map" (jakožto funktor) spolu s "unit" a "join" (přirozené transformace), přičemž join=flatten.

773
Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET
« kdy: 20. 09. 2016, 23:01:08 »
Už mě to moc nebaví, takže jenom krátce.

Vytvoření pole objektů není žádná optimalizace, je to přímočarý nativní přístup.

Vytvoření pole referencí na objekty je javovina, nic to nepřináší (kromě zjednodušení garbage collectoru), co se týká přístupu do paměti je to neoptimální. Většinou ta neoptimálnost nevadí, pokud ano, je to v Javě problém, protože to nejde normálně vyřešit, musí se to hackovat přes pole primitivních typů, což úplně rozbije datový model a kód v aplikaci.

Nazývat převedení pole referencí na pole objektů předčasnou optimalizací je úplně mimo, pole objektů by měl být nativní přístup, ale není, protože Java...
Tak toto je absolútna <|>vina. Referencie aj objekty sú v Random Access Memory, t.j. v pamäti s ľubovoľným prístupom. Moderné operačné systémy používajú virtuálnu adresáciu pamäte a nikto nezaručí, že časť poľa hodnôt bude v jednej časti fyzickej pamäte a druhá časť nebude celkom inde. Samozrejme platí, že pre procesor sú dáta najrýchlejšie prístupné v poradí register -> L1 -> L2 -> L3 -> RAM -> SWAP. Platí že je vyššia pravdepodobnosť, že pole hodnôt bude bližšie k procesoru (L1, L2,L3) ako keď pôjde o pole referencií, čím by výpočet teoreticky mohol prebehnúť rýchlejšie.
Keďže ale na serveri beží paralelne oveľa viac procesov ako je jadier procesorov, (na mojom serveri je to napríklad teraz 4 jadrá/211 procesov), procesy sa na jednom jadre prepínajú (o to sa stará OS), L1,L2 a L3 sa vyprázdňuje a načítava podľa potreby procesov (o to sa stará správca cache v procesore), pravdepodobnosť toho, že pole hodnôt zostane v cache počas celej práce s poľom je takmer nulová a celá snaha o takúto optimalizáciu nemá žiaden zmysel.
Oveľa väčší zmysel ako sa snažiť o ušetrenie pár nanosekúnd v prístupe k RAM je venovať sa problému, analyzovať ho, zjednodušiť a skrátiť a zrýchliť tým výpočet.
Z celej tejto diskusie mi vyplýva, že pri programovaní v C# sa musí hlavne všetko optimalizovať (keďže to nezvládne za neho OS) a celý jazyk je ako trošku lepší assembler, kdežto v Jave sa sústredím na problém a vyriešim ho tým oveľa rýchlejšie, priamočiarejšie a keďže pri tom nemusím používať všelijaké hacky, tak aj prehľadnejšie pre ostatných.
Celá diskuse začala tím, že R. Miček tvrdil, že Java zbytečně zatíží GC, protože nemá hodnotové typy, na rozdíl od C#, ve kterém to tedy bude efektivnější paměťově (ušetří se práce GC). Což je bezezbytku pravda. Zbytek jsou jen žvásty, co se nabalily jako sněhová koule na zpočátku věcnou a užitečnou radu.

774
Vývoj / Re:Postřehy ohledně architektury JavaScriptu
« kdy: 27. 08. 2016, 15:02:22 »
Nic proti, ale podle toho, co tady čtu, tak hubu bys možná konečně mohl zavřít ty ;-)

+1, ale trolly je lepší ignorovat ;)

775
Vývoj / Re:Postřehy ohledně architektury JavaScriptu
« kdy: 26. 08. 2016, 20:08:04 »
Citace
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.

Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(

Zrovna gettery a settery jsou ten nejhloupější cargo kult.
Cargo kult je vzorec chování, nemůže označovat konkrétní věc nebo koncept. Nicméně používání cizích slov bez znalosti jejich významu a kontextu použití už by cargo kult být mohl. Hezky ses ztrapnil, ale teď místo kecání na fórech by ses mohl vrátit do školy (doslova nebo obrazně), ať příště nepůsobíš jako ta poslední lopata (doufám, že na toto slovo nemá patent tvé dvojče "javaman").

776
Studium a uplatnění / Re:Jaký programovací jazyk zvolit?
« kdy: 26. 08. 2016, 20:03:25 »
..., return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.

Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Tak se podívej do vygenerovaného asembleru, jak to "není" goto. Pokud teda znáš asembler...

Když se podívám do returnu vygenerovaného do assembleru, tak tam goto skutečně není.
Tak se podívej znova. Případně někoho požádej, ať ti ten strojový kód vysvětlí.

777
Vývoj / Re:Postřehy ohledně architektury JavaScriptu
« kdy: 26. 08. 2016, 19:47:31 »
Citace
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.

Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(

778
Studium a uplatnění / Re:Jaký programovací jazyk zvolit?
« kdy: 26. 08. 2016, 19:41:20 »
..., return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.

Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.
Tak se podívej do vygenerovaného asembleru, jak to "není" goto. Pokud teda znáš asembler...

779
Vývoj / Re:Postřehy ohledně architektury JavaScriptu
« kdy: 26. 08. 2016, 16:16:13 »
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Alan Kay http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Nepředpokládám, že Kay měl na mysli nějaké částečné zapouzdření (hiding), které někdy funguje a někdy ne.

Zato já už nemám náladu dohadovat se s nějakými céčkaři přeškolenými na OOP, chci se vrátit k původnímu tématu, a to je Javascript a jeho použití. Jestli máte potřebu protřepávat způsob, jak pozalamovat OOP do Go, založte si pro to jinou diskusi.
To chápu, céčkaři jsou divná stvoření, taky jsem jim nepříšel na chuť. Stejně jako javascriptařům. Programování ostatně není věda, ale čistě praktická a pragmatická činnost, něco jako tesařina, a absolutně nemá smysl se bavit o tom, jaká míra zapouzdření je žádoucí, protože to závisí na kontextu. Takže cargo kult pozdravuje :p Prvním krokem k přechodu od žvanila k odborníkovi - přiznávám, ne každý na to intelektuálně má - bude naučení se věcné diskusi...

780
Studium a uplatnění / Re:Jaký programovací jazyk zvolit?
« kdy: 26. 08. 2016, 15:09:44 »
Jde spíš o zrušení větve "else" bez náhrady.
Pokud má program dělat to, co předtím, tak je náhrada nutná. Tipoval bych, že tou náhradou jsou returny. Mám pravdu?

Jestli jo, tak to raději to else.

return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.
Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.

A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.
Souhlas, return někde uprostřed je v podstatě goto, strukturovaný kód s else je mnohem čitelnější.

Stran: 1 ... 50 51 [52] 53 54 ... 101