Příspěvky

2656

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 19:52:34 »

oni tvrdí, že mé programy budou stejně rychlé i když ty mutable části nepoužiji.

To je fakt marný...

Můžeš mi nějak polopaticky vysvětlit, z jakého důvodu potřebuješ tak zarputile dokazovat, že FP je pomalejší?

(a pak že jí mám nějaké "náboženství", ufff...)

2657

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 09:43:14 »

Ja si dokazu predstavit kompilator, ktery nejaky vicemene standardni postup prace v lambda kalkulu prevede do nahodnych pristupu do pameti.. (Muzes si treba predstavit vyvazeny binarni strom, ktery je implementovan jako pole.) Takze ano, jde to.

Myslím, že se tady hlavně motají dohromady dvě věci: teoretická možnost výpočtu ve stejném množství kroků a praktický způsob, jak se v jednom nebo druhém případě reálně programuje a jaký je pak výkon toho kódu na reálném stroji.

Z toho teoretického pohledu (a to měl myslím zboj na mysli) je velice snadný v FP "simulovat" (na teoretické rovině) mutabilní výpočet - jestliže mutabilní výpočet je nějaká posloupnost kroků a,b,c, které nějak manipulují s pamětí, tak v imutabilním fp budu mít prostě   c(b(a(ram))) - funkce si předávají pole, které je jakoby RAM a můžou ho klidně měnit. Na teoretické rovině je tím causa finita. Dokonce k tomu můžu přidat, že na praktické rovině při tomhle přístupu ani nevzniká problém s kopírováním té struktury "ram", protože překladač ví, že se použije jenom jednou, takže ji vůbec kopírovat nemusí. Výkon je teda zjevně úplně stejný jako v ne-FP implementaci.

2658

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 09:07:04 »

Slozitost maker se precenuje. Ve finale to neni zase o tolik horsi nez funkce

Přesněji je to úplně stejné, protože (dobře udělaná) makra jsou funkce

Jediný rozdíl je v tom, že makra se spouští při překladu a manipulují s kódem, který se dál ještě překládá a spouští. Takže ta horší srozumitelnost je daná tím, že makro mi vygeneruje nějakou funkci, která se pak ještě spustí. Pokud teda chci vědět "co to dělá", musím v hlavě zvážit dva po sobě následující kroky (transformace při překladu, spuštění při běhu), zatímco u normální funkce jenom jeden (spuštění při běhu).

2659

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 08:32:22 »

Argumentace Turingem funguje jedním směrem. Pokud by bylo možné na Turingově stroji rozhodnout halting problém, bylo by ho možné rozhodnout i pro jakýkoliv Java program na reálném stroji. Opačně to obecně neplatí.

[Poslední příspěvek k TS, už jsme se tady o tom naplácali dost nedávno]

Pokud by bylo možné vyřešit zastavení neomezeného stroje na neomezeném stroji, tak by to mělo (jakýkoli) praktický důsledek pro omezený stroj? Určitě?

To není "halting problem", to je "TM halting problem".

Vždyť to, co jsi citoval, to popisuje úplně přesně: neomezený stroj může pořád utíkat do nových a nových stavů. Proto ho nejde "vyčíslit" ani neomezeným strojem, protože ten bude taky jenom procházet ty nové a nové stavy (a nikdy neskončí). Pro omezený stroj to nemá důsledek vůbec žádný a problém zastavení neomezeného stroje nás z praktického hlediska tak nějak moc nepálí

Čili pokud se bavíme o problému zastavení omezeného stroje, je to úplně jiný problém a Turing pro něj neplatí ani "jedním směrem".

2660

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 00:24:24 »

díky tomu, že je to lazy, se procházení zastaví po nalezní vrcholu? To na asymptotické složitosti nic nezmění.

...a došlo na moje slova

No... neuraž se, ale já bych teda nechtěl vidět, jak bys tu složitost pro konkrétní implementaci počítal

Tak radši dobrou

2661

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 00:08:20 »

Ale když člověk zrovna čeká na doběhnutí make při ladění obskurní chyby v poměrně low-level kódu v C++, tak je čtení názorů místních odborníků na teorii vyčíslitelnosti, složitosti a programovacích jazyků docela dobrý relax

Jj, taky občas praktikuju

2662

Vývoj / Re:Dědičnost dnes

« kdy: 03. 02. 2017, 00:06:35 »

Pro výběr hran vedoucích z vrcholu se prochází všechny vrcholy grafu v každém kroku.

Nezapomněl jsi, že Haskell je lazy?! )

2663

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 23:16:26 »

Na reálném počítači to teoreticky řešitelné je, prakticky ale ne:

Kvituji s velkým vděkem, že jsi pastnul text, který podstatu problému perfektně vystihuje (daleko líp než napůl pochopený Turing, jak je tady zhusta vidět). Jenom škoda, že neuvádíš, odkud ta citace je.

Nicméně pořád se se mnou míjíš, já jsem netvrdil, že to řešitelné je, tvrdil jsem, že uvedená argumentace Turingem je chybná, neplatná. Pokud se na tomhle shodneme všichni, dá se jít dál a Turinga nechat spát

Což samozřejmě nevylučuje, že někdy někdo přijde s lepším řešením, jak to v rozumném čase rozhodnout, zatím se to ale nikomu nepovedlo.

Co "to"? Pro libovolný javovský program rozhodnout, jestli se na nějakém reálném hw zastaví? To se nejspíš nikomu (obecně) nepovede, protože to (obecně) není zajímavý problém.

Pro nějaký omezený subset to nepochybně jde, vždyť tady už proběhl odkaz. Pro ne-subset to nikoho nezajímá, protože v reálném programu hraje roli taky síť, disk, atd. atd. Reálný svět IT je o dost pestřejší než číslo na pásce

2664

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 21:42:29 »

Tak já nevím, já když do Googlu zadám "haskell dijkstra algorithm", tak to mám hned na prvních třech pozicích. Ale možná mám jinej Google.

Implementace, které jsem našel, používají knihovny, které uvnitř nejsou FP.

Já mam vážně asi nějakej jinej Google. U mě je druhý odkaz tohle: https://github.com/ddrake/haskell-dijkstra
Tam jsou nějaké "unitř ne-FP knihovny"?

(Teda úplně nechápu, co to je za kritérium - když budu mít céčkový kód, který použije knihovnu s kouskem assembleru, tak? No ale nešť...)

2665

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 20:35:07 »

Rád ti to vysvětlím. Už v roce 1936 Alan Turing dokázal, že nexistuje obecný algoritmus, který by řešil problém zastavení pro všechny vstupy všech programů na Turingově stroji.

Pravda.

Možná víš, že Java je Turing complete programovací jazyk. Prakticky to znamená, že nelze rozhodnout jestli je nějaký (netriviální) program (v Javě) správný a bude fungovat pro jakýkoliv vstup.

Nepravda. Ten zmíněný důkaz něco říká o neomezeném stroji, který nemáme a nikdy mít nebudeme. Pokud je stroj jakýmkoli způsobem omezený, např. počtem atomů ve vesmíru, neříká o něm zmíněný Turingův objev vůbec nic. Protože o takovém stroji prostě a jednoduše nehovoří, stejně jako nehovoří třeba o maximálním možném množství žab v jihočeských rybnících. Že je Java turingovsky kompletní s tím souvisí jenom víceméně okrajově.

Čili argumentuješ chybně: z toho, co víme o halting problému pro TM, neplyne vůbec nic pro konkrétní algoritmus v javě běžící na nějakém reálném (nebo realisticky myslitelném) počítači.

Tvoje tvzení: [...] je nesmysl, který tvrdíš, protože neznáš základy IT.

Byl bych v těch odsudcích raději skromnější...

2666

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 20:24:07 »

To jsou věci teda, člověk je jeden den totálně nasazenej v práci a pak koukne na Root a tady je takovej armageddon! Teda pánové... Obzvlášť ty motanice kolem O-notace jsou teda výživný... Do toho se už ani motat nebudu

Já jsem požadoval konkrétní implementaci konkrétního algoritmu, v konkrétním FP jazyku bez side efektů, která po překladu vygeneruje pro reálný HW stejně efektivní kód (stačí z hlediska asymptotické složitosti) jako implementace v imperativním jazyku.

No... neuraž se, ale já bych teda nechtěl vidět, jak bys tu složitost pro konkrétní implementaci počítal - a jak bysme se tady přes fórum shodli na tom, že ten výpočet je správně...

Přijde mi, že Zboj, Prýmkem a vy máte své náboženství a snažíte se ho obhajovat za každou cenu. Když náhodou nemáte pravdu, tak protivníka ubijete argumentem "to v praxi není rozhodující" nebo naopak pseudointelektuálními žvásty (ty používá hlavně zboj) a citací vašich FP guruů.

Nechápu. Jasně a bez jakýchkoli vytáček jsem tady několikrát napsal, že Elixir (který jediný z FP jazyků jakžtakž znám) má hrubý výkon špatný, v testech hrubého výkonu nemá absolutně šanci a naprosto se nehodí pro number crunching. Jediný, co tady dělám, je vyvracení přegeneralizovaných tvrzení o tom, že v FP něco nejde a nejde a nejde protože prostě nejde a jestli jde, tak nejde. Kolikrát tady někdo stejně otevřeně jako já napsal, k čemu se nehodí jeho oblíbený OOP jazyk?!

Ani nevím, jakého gurua jsem citoval. Na nic si teď nevzpomínám. Opět jsem se jenom snažil trochu korigovat přehnaná tvrzení o tom, že Armstrong je pitomec, který ničemu nerozumí a OOP vůbec nepochopil. Když už pro nic jinýho, tak kvůli věku by se k němu imho místní usmrkanci měli chovat s elementární dávkou respektu

2667

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 10:44:28 »

řešení, která jsem vygooglil nejsou čistě FP.

Tak já nevím, já když do Googlu zadám "haskell dijkstra algorithm", tak to mám hned na prvních třech pozicích. Ale možná mám jinej Google.

Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

Důkaz?

2668

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 08:33:30 »

Makra se dají použít i na optimalizaci - pokud vím, že něco platí v době běhu, můžu toho využít a např. nějaký kód pomocí makra nahradit NOOPem apod.

Pardon, samozřejmě "v době překladu".

2669

Vývoj / Re:Dědičnost dnes

« kdy: 02. 02. 2017, 08:05:40 »

Makra sa vacsinou pouzivaju na to, aby programatori mohli pouzivat nie zrovna zrejme konstrukcie, ktore sa ani nemusia podobat povodnemu jazyku. Clovek neznaly, ake makra tam niekno naprplal vidi kod a ide si oci vyocit, ze ako to dofrasa moze vobec fungovat . Nebodaj, ked je este v makre chyba...  Zly koncept na urovni copy-paste programovania.

Proto jsem psal, že jsou makra nebezpečná - spousta lidí se jejich silou nechá zlákat a řeší jimi buď vůbec neexistující problémy nebo věci, které by se daly řešit jinak. Rule of thumb je, že makro by se mělo použít jenom tam, kde řešení pomocí funkcí neexistuje, nebo by bylo výrazně míň elegantní.

Ale není pravda, že makra jsou zlo. Naopak, často významně chybí. Například ve staticky typovaných jazycích, které nemají makra ani dostatečně flexibilní/efektivní/elegantní pozdní vazbu je problém s RPC. Tak se to řeší tím, že se napíše úplně standalone "generátor stubu", což je de facto ad hoc vytvořený macro processor, který se dá použít jenom na ten jeden účel. Čili výrazně horší řešení než obecná makra, použitelná i na cokoli jiného.

Makra se dají použít i na optimalizaci - pokud vím, že něco platí v době běhu, můžu toho využít a např. nějaký kód pomocí makra nahradit NOOPem apod.

Překladač Elixiru zas dělal (nevím, jestli to ještě platí) takovou srandičku, že jakousi funkci zpracovávající unicode při překladu generoval přímo z aktuální specifikace. Prostě se při překladu stáhlo nějaké specifikační XMLko nebo co a na základě něj se vytvořila funkce pattern-matchující jednotlivé znaky (skupiny znaků? detaily si nepamatuju). Čili při překladu vznikl superaktuální kód, efektivnější než kdyby se v tom XMLku vyhledávalo za běhu. A to bez jakýchkoli berliček typu "generátor unicode stubu".

...protože správně použitá makra nejsou žádné berličky, právě naopak - pokud je nemám a hodila by se mi, musím se k nějaké berličce uchýlit.

2670

Vývoj / Re:Dědičnost dnes

« kdy: 01. 02. 2017, 23:39:50 »

Stále čekám na funkcionální implementaci Dijkstry. Nemusíte navrhovat ani implementovat. Stačí poslat odkaz.

Google dneska nefunguje, nebo považuješ zboje za personální asistentku?