Rychlost Haskell vs. C++

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #225 kdy: 31. 08. 2018, 08:50:14 »
Ten důkaz 0=1 nesplňuje základní podmínku: Není korektní podle MĚ. Fakt?
Ten tvůj “důkaz" je úplná blbost a nijak nesouvisí s chytání výjimky při dělení nulou v Haskellu. Nechápu, proč takové nesmysly píšeš?

Citace
A jen pro inspiraci, abys nežil v představě, že řešíme nějaké silně nepravděpodobné a okrajové případy a v Haskellu se to "tak prostě nedělá a nikoho by to ani nenapadlo": https://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function
A odpověd:
Citace
error is supposed to be as observable as an infinite loop. You can only catch error in IO, which is like saying "yeah you can if you know magic". But from the really nice part of Haskell, pure code, it is unrecoverable, and thus it is strongly advised not to use in your code, only as much as you would ever use an infinite loop as an error code
U chytání error je to diskutabilní, ale u chytání aritmetické výjimky z div ne. To je prostě legitimní řešení problému. Možná to není best practice, ale je to korektní řešení. Nicméně to není pointa. Pointa je, že lidi takové věci v Haskellu dělají a dělat budou. Můžeš s tím nesouhlasit, můžeš proti tomu protestovat, ale to je asi tak jediné, co s tím můžeš dělat.


andy

Re:Rychlost Haskell vs. C++
« Odpověď #226 kdy: 31. 08. 2018, 09:30:58 »
Ten důkaz 0=1 nesplňuje základní podmínku: Není korektní podle MĚ. Fakt?
Ten tvůj “důkaz" je úplná blbost a nijak nesouvisí s chytání výjimky při dělení nulou v Haskellu. Nechápu, proč takové nesmysly píšeš?
Protože interpretace haskellového kódu je postavena na denotační sémantice, aneb očekává se, že to bude mít nějaký matematický smysl. Curry-howard isomorfismus je v haskell světě skloňováno docela často. Ne, že aplikace nějakých operačních pravidel k něčemu vede, a pokud ta pravidla byla aplikována správně, tak je výsledek korektní. Něco jako ten důkaz - slepě aplikuješ pravidla a ono to k něčemu vede. A ty se snažíš v podstatě říct, že pokud je výsledek správně, tak je ten předchozí postup správně.

Špatný důkaz neznamená, že závěr neplatí.  Klidně může, ale to neznamená, že ten důkaz je správně. Ano, haskellový program může vracet správné výsledky, protože se chová deterministicky. To neznamená, že ten kód dává nějaký smysl.


Citace
Citace
A jen pro inspiraci, abys nežil v představě, že řešíme nějaké silně nepravděpodobné a okrajové případy a v Haskellu se to "tak prostě nedělá a nikoho by to ani nenapadlo": https://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function
A odpověd:
Citace
error is supposed to be as observable as an infinite loop. You can only catch error in IO, which is like saying "yeah you can if you know magic". But from the really nice part of Haskell, pure code, it is unrecoverable, and thus it is strongly advised not to use in your code, only as much as you would ever use an infinite loop as an error code
U chytání error je to diskutabilní, ale u chytání aritmetické výjimky z div ne. To je prostě legitimní řešení problému.
V Haskellu není. Je to bottom, to je stejné jako error.

Citace
Možná to není best practice, ale je to korektní řešení. Nicméně to není pointa. Pointa je, že lidi takové věci v Haskellu dělají a dělat budou. Můžeš s tím nesouhlasit, můžeš proti tomu protestovat, ale to je asi tak jediné, co s tím můžeš dělat.
Vůbec netuším, co tím chceš říct. Že lidi budou psát zabugovaný kód? Který z nějakých důvodů dává správné výsledky, dokud se překladač nebo jiný programátor nerozhodne provést nějakou transformaci, která ten kód rozbije? No jasně...a?

Re:Rychlost Haskell vs. C++
« Odpověď #227 kdy: 31. 08. 2018, 10:23:03 »
Ten důkaz 0=1 nesplňuje základní podmínku: Není korektní podle MĚ. Fakt?
Ten tvůj “důkaz" je úplná blbost a nijak nesouvisí s chytání výjimky při dělení nulou v Haskellu. Nechápu, proč takové nesmysly píšeš?

Právě že souvisí :) A až to pochopíš, tak taky pochopíš, proč celé vlákno píšeš kraviny. :)

Bacsa

Re:Rychlost Haskell vs. C++
« Odpověď #228 kdy: 31. 08. 2018, 12:24:08 »
Ten důkaz 0=1 nesplňuje základní podmínku: Není korektní podle MĚ. Fakt?
Ten tvůj “důkaz" je úplná blbost a nijak nesouvisí s chytání výjimky při dělení nulou v Haskellu. Nechápu, proč takové nesmysly píšeš?
Právě že souvisí :) A až to pochopíš, tak taky pochopíš, proč celé vlákno píšeš kraviny. :)
Když to nepochopil doteď, už to nepochopí nikdy.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #229 kdy: 31. 08. 2018, 13:16:31 »
Já to zkusím ještě jinak.

Představ si třeba Javu. Je následující korektní kód?
Kód: [Vybrat]
int a = 3 + "test";Není. Proč? Protože ti nesedí typy. Teď si představ, že Java by měla switch, který vypne typovou konverzi, tohle se normálně zkompiluje a při běhu to vyhodí přesně specifikovanou výjimku. Stane se z toho korektní kód? Já bych řekl, že ne. Jenom prostě překladač v daném momentě není schopen/ochoten zkontrolovat, že ten kód, co jsi mu dal, je korektní a že je to blbě zjistí až při běhu.

Podobně máš třeba null pointer exception.
Kód: [Vybrat]
Object x = null; x.equals(x);Tohle taky není korektní kód, ale typovou kontrolou ti projde, protože typový systém Javy tohle není schopen při kompilaci odhalit. V kotlinu už ty typy postavili trošku jinak, a najednou to ten typový systém odhalí.

A teď k Haskellu: je to lazy jazyk, takže všechny typy obsahují bottom. -XStrict to de-fakto v rámci toho modulu přepneš do strikt sémantiky; takže v rámci toho modulu typy přestanou obsahovat bottom. Když pak uděláš nějakou funkci ve stylu:
Kód: [Vybrat]
f :: Int -> Int
f 0 = error "Chyba"
f x = x
Tak to je nekorektní kód, protože z funkce, která by měla vracet Int vracíš bottom (resp. do následující funkce, která očekává Int bez bottomu to dopluje). To je typová chyba, akorát to překladač není schopen to zkontrolovat (mimo jiné, protože to je obecně nerozhodnutelný problém), takže se spoléhá na to, že uživatel v tomhle nelže. Jsou jazyky, které jsou schopny v typovém systému řešit, jestli typ obsahuje bottom nebo ne, haskell to neumí.

Pokud jde o souvislost s důkazem: to je takový pěkný poznatek, že typový signature je "tvrzení" a implementace funcke je "důkaz". (https://wiki.haskell.org/Curry-Howard-Lambek_correspondence). Pokud ti z implementace nic nevypadne (což je bottom - nekonečné zacyklení), tak jsi nic nedokázal. No a speciálně v tom Strict režimu je to úplně přesně jako to dělení 0 v tom důkazu 0=1. Ty mechanicky klidně můžeš pokračovat dál, interpret klidně mechanicky bude vykonávat ten kód podle nějakých pravidel, možná to i povede k nějakému korektnímu výsledku, ale to nic nemění na tom, že ten důkaz je blbě.


andy

Re:Rychlost Haskell vs. C++
« Odpověď #230 kdy: 31. 08. 2018, 13:17:37 »
Citace
Není. Proč? Protože ti nesedí typy. Teď si představ, že Java by měla switch, který vypne typovou konverzi kontrolu

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #231 kdy: 01. 09. 2018, 09:15:23 »
Citace
Možná to není best practice, ale je to korektní řešení. Nicméně to není pointa. Pointa je, že lidi takové věci v Haskellu dělají a dělat budou. Můžeš s tím nesouhlasit, můžeš proti tomu protestovat, ale to je asi tak jediné, co s tím můžeš dělat.
Vůbec netuším, co tím chceš říct. Že lidi budou psát zabugovaný kód? Který z nějakých důvodů dává správné výsledky, dokud se překladač nebo jiný programátor nerozhodne provést nějakou transformaci, která ten kód rozbije? No jasně...a?

Pořád jsi to nepochopil, takže si dáme další kolečko.Ten kód:
Kód: [Vybrat]
{-# LANGUAGE ScopedTypeVariables #-}

import Control.Exception

main = catch
        (do
            putStrLn "Tento program zjišťuje, zda lze zadaným číslem dělit. Zadejte číslo"
            input <- getLine
            let n = (read input :: Int)
            let a = div 1 n
            putStrLn "Tímto číslem lze dělit"
        )
        (\(err :: ArithException) -> putStrLn "Tímto číslem nelze dělit")

NENÍ zabugovaný. Je GARANTOVÁNO, že bude při strict vyhodnocení fungovat správně. Pokud si myslíš opak, tak prosím exaktně řekni, co z Haskell language report porušuje. Nestačí říct, že se ti nelíbí. Chtěl jsi kód, který v Haskellu bude dávat jiné výsledky při strict a lazy vyhodnocení. Dostal jsi ho. A znovu opakuji, žádná chyba v něm není, při strict vyhodnocení má GARANTOVANÉ chování a dává správné výsledky.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #232 kdy: 01. 09. 2018, 09:26:12 »
NENÍ zabugovaný. Je GARANTOVÁNO, že bude při strict vyhodnocení fungovat správně. Pokud si myslíš opak, tak prosím exaktně řekni, co z Haskell language report porušuje. Nestačí říct, že se ti nelíbí. Chtěl jsi kód, který v Haskellu bude dávat jiné výsledky při strict a lazy vyhodnocení. Dostal jsi ho. A znovu opakuji, žádná chyba v něm není, při strict vyhodnocení má GARANTOVANÉ chování a dává správné výsledky.
No Haskell report je z 2010, XStrict je tak rok starý...

Je v něm typová chyba: vrací se bottom tam, kde se očekává typ, který bottom neobsahuje. Haskell tento typ chyby není schopen odhalit při překladu, slítne to v runtimu.

Mně totiž připadá, že ty se snažíš tvrdit, že pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů, tak žádné nekorektní programy vlastně nejsou...?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #233 kdy: 01. 09. 2018, 09:41:46 »
NENÍ zabugovaný. Je GARANTOVÁNO, že bude při strict vyhodnocení fungovat správně. Pokud si myslíš opak, tak prosím exaktně řekni, co z Haskell language report porušuje. Nestačí říct, že se ti nelíbí. Chtěl jsi kód, který v Haskellu bude dávat jiné výsledky při strict a lazy vyhodnocení. Dostal jsi ho. A znovu opakuji, žádná chyba v něm není, při strict vyhodnocení má GARANTOVANÉ chování a dává správné výsledky.
No Haskell report je z 2010, XStrict je tak rok starý...
To ale není můj problém...

Je v něm typová chyba: vrací se bottom tam, kde se očekává typ, který bottom neobsahuje. Haskell tento typ chyby není schopen odhalit při překladu, slítne to v runtimu.
Neslítne to. Haskell language report někde říká, že když se vrátí bottom, je to nedefinované chování? Neříká. Vyhodí to ArithException, která se dá chytit. Haskell to umožňuje a je to definované chování. Já chápu, že se ti nelíbí, jak je to udělané a že tu výjimku chytám. Mně se to taky nelíbí, dělám to z toho důvodu, protože jsi tvrdil, že v Haskellu nemůže existovat program, který závisí na strict vyhodnocení. Může.

Mně totiž připadá, že ty se snažíš tvrdit, že pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů, tak žádné nekorektní programy vlastně nejsou...?
To netvrdím. Nekorektní program je takový, který dává nedeterministické výsledky (ve smyslu, že závisí na undefined behavior a pak se může stát cokoliv) nebo program, který dává jiné než očekávané výsledky.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #234 kdy: 01. 09. 2018, 09:53:09 »
Pokud si myslíš opak, tak prosím exaktně řekni, co z Haskell language report porušuje..
No Haskell report je z 2010, XStrict je tak rok starý...
To ale není můj problém...
No comment.

Citace
Je v něm typová chyba: vrací se bottom tam, kde se očekává typ, který bottom neobsahuje. Haskell tento typ chyby není schopen odhalit při překladu, slítne to v runtimu.
Neslítne to.
Slítne vyhodnocování výrazu, abych se vyjádřil úplně přesně. Je v něm v podstatě typová chyba, ale typový systém Haskellu není dostatečně silný, aby tohle byl schopen zachytit. Máš k tomu nějaký komentář?

Citace
Haskell language report někde říká, že když se vrátí bottom, je to nedefinované chování? Neříká.
Říká, že to je nedefinovaná hodnota. Haskell je funkcionální jazyk, pracujeme převážně s hodnotami. Pokus o vyhodnocení nedefinované hodnoty je nekorektní stav programu.

Citace
Vyhodí to ArithException, která se dá chytit. Haskell to umožňuje a je to definované chování. Já chápu, že se ti nelíbí, jak je to udělané a že tu výjimku chytám. Mně se to taky nelíbí, dělám to z toho důvodu, protože jsi tvrdil, že v Haskellu nemůže existovat program, který závisí na strict vyhodnocení. Může.
Je to nekorektní stav programu, který jsi schopen zachytit a zpracovat.

Citace
Mně totiž připadá, že ty se snažíš tvrdit, že pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů, tak žádné nekorektní programy vlastně nejsou...?
To netvrdím. Nekorektní program je takový, který dává nedeterministické výsledky (ve smyslu, že závisí na undefined behavior a pak se může stát cokoliv) nebo program, který dává jiné než očekávané výsledky.
Takže přesněji:

Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů a neobsahuje konstrukce s nedefinovaným chováním, pak v něm nelze napsat nekorektní program.

Souhlasíš s tím?

andy

Re:Rychlost Haskell vs. C++
« Odpověď #235 kdy: 01. 09. 2018, 09:59:27 »
Citace
dělám to z toho důvodu, protože jsi tvrdil, že v Haskellu nemůže existovat program, který závisí na strict vyhodnocení
A tak nějak už tady několik stránek řešíme, že v Haskellu nemůže existovat korektní program, který závisí na strict vyhodnocení. Zabugovaný program, který závisí na Strict vyhodnocení samozřejmě existovat může.... člověk by čekal, že těch pár stránek stačilo k tomu, abys to pochopil?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #236 kdy: 01. 09. 2018, 10:46:04 »
Pokud si myslíš opak, tak prosím exaktně řekni, co z Haskell language report porušuje..
No Haskell report je z 2010, XStrict je tak rok starý...
To ale není můj problém...
No comment.
Mně by se taky líbilo, kdyby pro Haskell existovalo něco tak podrobného, jako ISO standard pro C, ale bohužel neexistuje.

Říká, že to je nedefinovaná hodnota. Haskell je funkcionální jazyk, pracujeme převážně s hodnotami. Pokus o vyhodnocení nedefinované hodnoty je nekorektní stav programu.
Výsledek operace div není pro některé hodnoty definován, v takovém případě funkce div vrací bottom type, v Haskellu konkrétně aritmetickou výjimku. Není to nekorektní stav programu, vrací se bottom type v případě, kdy se má vracet. Je naprosto v pořádku, že se vyhodí aritmetická výjimka. Ta výjimka se zachytí, zpracuje a výsledek operace dělení se prohlásí za neplatný. Nehledej v tom žádnou vědu. Nic nekorektního tam není, žádný nekorektní stav nenastává a výsledek všech operací je definovaný a garantovaný.

Takže přesněji:
Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů a neobsahuje konstrukce s nedefinovaným chováním, pak v něm nelze napsat nekorektní program.

Souhlasíš s tím?
Nevymýšlej nesmysly. Jasně jsem napsal, že korektní program je jen takový, který dává očekávaný (ve smyslu správný) výstup.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #237 kdy: 01. 09. 2018, 10:57:07 »
Citace
Říká, že to je nedefinovaná hodnota. Haskell je funkcionální jazyk, pracujeme převážně s hodnotami. Pokus o vyhodnocení nedefinované hodnoty je nekorektní stav programu.
Výsledek operace div není pro některé hodnoty definován, v takovém případě funkce div vrací bottom type, v Haskellu konkrétně aritmetickou výjimku.
Nevrací.

Citace
Není to nekorektní stav programu
Citace
Errors during expression evaluation, denoted by ⊥ (“bottom”),
Bottom je CHYBA. Nekorektní stav programu.

Citace
vrací se bottom type v případě, kdy se má vracet.
Bottom nejde vrátit. Bottom je chyba. Viz výše haskell report.

Citace
Je naprosto v pořádku, že se vyhodí aritmetická výjimka. Ta výjimka se zachytí, zpracuje a výsledek operace dělení se prohlásí za neplatný. Nehledej v tom žádnou vědu. Nic nekorektního tam není, žádný nekorektní stav nenastává a výsledek všech operací je definovaný a garantovaný.
Jak bys nazval "stuck" stav v expression evaluation? Nekorektní, chybný stav programu?

Citace
Takže přesněji:
Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů a neobsahuje konstrukce s nedefinovaným chováním, pak v něm nelze napsat nekorektní program.
Souhlasíš s tím?
Nevymýšlej nesmysly. Jasně jsem napsal, že korektní program je jen takový, který dává očekávaný (ve smyslu správný) výstup.
Dobře, tak ještě jinak:

Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů, pak každý program, který neobsahuje konstrukce s nedefinovaným chováním a vrací požadované výsledky na požadované vstupy, je korektní?

Takhle s tím souhlasíš?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #238 kdy: 01. 09. 2018, 11:06:09 »
Ale já se nebavím o bottom v Haskellu, já se bavím o bottom type: https://en.m.wikipedia.org/wiki/Bottom_type

V Haskellu je garantováno, že div vyhodí aritmetickou výjimku. Není to nekorektní stav. Výsledek operace není definovaný, proto to vyhazuje výjimku. Znovu opakuji, nehledej v tom žádnou vědu, výsledek toho programu je definovaný a garantovaný.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #239 kdy: 01. 09. 2018, 11:15:19 »
Ale já se nebavím o bottom v Haskellu, já se bavím o bottom type: https://en.m.wikipedia.org/wiki/Bottom_type
Jak se vrací typ? Když už se něco vrací, tak je to hodnota, a podíváš-li se na první větu toho, co odkazuješ, tak je tam napsáno:
Citace
In type theory, a theory within mathematical logic, the bottom type is the type that has no values
Hodnotu typu bottom vrátit nejde, protože žádná taková neexistuje.

Citace
V Haskellu je garantováno, že div vyhodí aritmetickou výjimku. Není to nekorektní stav. Výsledek operace není definovaný, proto to vyhazuje výjimku. Znovu opakuji, nehledej v tom žádnou vědu, výsledek toho programu je definovaný a garantovaný.
V Haskellu je definované, že některé chybové stavy, pokud budou spuštěny v "sandboxu" jménem "catch" způsobí, že nespadne celý program, ale místo toho se spustí druhý parametr toho catche.

Ale pořád jsme se nedostali k tomu, co TY považuješ za korektní. Je to tohle?

Citace
Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů, pak každý program, který neobsahuje konstrukce s nedefinovaným chováním a vrací požadované výsledky na požadované vstupy, je korektní.