Node.js a multiplexed IO obecně

[gll]

obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.

Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.

Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.

Tento generáror

Kód: [Vybrat]

func generateRandomNumbers (n int) {
    ch := make (chan float)
    sem := make (semaphore, n)

    for i := 0; i < n; i++ {
        go func () {
            ch <- rand.Float()
            close(ch)
        } ()
    }

    // launch extra goroutine to eventually close ch
    go func () {
        sem.Wait(n)
        close(ch)
    }
   
    return ch
}

vypadá v pythonu takto:

Kód: [Vybrat]

@parallel
def rand():
    while True:
        yield random()

použitím takového wrapperu:

Kód: [Vybrat]

from multiprocessing import Process, Queue
from multiprocessing.queues import Empty
from random import random
import itertools
import functools

def run_parallel(gen, *args, **kwargs):
    def task_wrapper(q, gen, *args, **kwargs):
        for val in gen(*args, **kwargs):
            q.put(val)
        q.close()

    try:
        q = Queue(5)
        p = Process(
            target=task_wrapper, args=(q, gen) + args, kwargs=kwargs)
        p.start()
        while True:
            yield q.get(timeout=1)
    except Empty:
        pass
    finally:
        p.terminate()


def parallel(gen):
    @functools.wraps(gen)
    def wrapper(*args, **kwargs):
        yield from run_parallel(gen, *args, **kwargs)
    return wrapper

mohu wrapovat i vestavěné funkce:

Kód: [Vybrat]

pmap = parallel(map)
pislice = parallel(itertools.islice)
pislice(pmap(str, rand())) # "pipe" běžící ve třech procesech

takovou abstrakci Go moc nezvládá. Neručím, že je to správně, je to napsané narychlo a nechci se tím zbytečným problémem více zabývat.

Mnohem užitečnější mohou být asynchronní generátory. To je novinka v Pythonu 3.6.

https://www.python.org/dev/peps/pep-0525/

[Reklama]

[Cikáda]

Ne, snažím se vám vysvětlit, že plácáte páté přes deváté. Neúspěšně.

Nesnažíte se nic vysvětlit. Snažíte se obhájit neobhajitelné pomocí matení pojmů (v lepším případě) nebo neznalosti pojmu "relace" (v horším případě). Relace je definovaná na nějaké množině. Pro operátor == je tou množinou množina všech hodnot daného jazyka. Neexistuje žádný speciální operátor pro porovnání stringů a speciální pro porovnání čísel.

A pokud má být == použitelný, musí být tranzitivní na celé této množině. Tranzitivita na podmnožině je k ničemu a vůbec nemá smysl o ní mluvit.

Zkusím to naposledy. Zjednodušeně. Krátce.

Jenže ta "množina všech hodnot daného jazyka" *vznikne* tak, že se je == snaží přetypovat na stejný typ.

Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.

------------

Dál už se s vámi odmítám hádat. Mám na práci důležitější věci, než čtení argumentů "v jiných jazycích je to tak, tak to tak chci i tady!".

[zboj]

obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.

Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.

Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.

Tento generáror

Kód: [Vybrat]

func generateRandomNumbers (n int) {
    ch := make (chan float)
    sem := make (semaphore, n)

    for i := 0; i < n; i++ {
        go func () {
            ch <- rand.Float()
            close(ch)
        } ()
    }

    // launch extra goroutine to eventually close ch
    go func () {
        sem.Wait(n)
        close(ch)
    }
   
    return ch
}


Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.

[gll]

obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.

Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.

Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.

Tento generáror

Kód: [Vybrat]

func generateRandomNumbers (n int) {
    ch := make (chan float)
    sem := make (semaphore, n)

    for i := 0; i < n; i++ {
        go func () {
            ch <- rand.Float()
            close(ch)
        } ()
    }

    // launch extra goroutine to eventually close ch
    go func () {
        sem.Wait(n)
        close(ch)
    }
   
    return ch
}


Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.

http://www.golangpatterns.info/concurrency/generators

[zboj]

obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.

Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.

Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.

Tento generáror

Kód: [Vybrat]

func generateRandomNumbers (n int) {
    ch := make (chan float)
    sem := make (semaphore, n)

    for i := 0; i < n; i++ {
        go func () {
            ch <- rand.Float()
            close(ch)
        } ()
    }

    // launch extra goroutine to eventually close ch
    go func () {
        sem.Wait(n)
        close(ch)
    }
   
    return ch
}


Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.

http://www.golangpatterns.info/concurrency/generators

Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.

[Reklama]

[gll]

Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.

napiš lepší.

[zboj]

Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.

napiš lepší.

Napiš si to sám, jsou to 3 řádky kódu. Když se to tentokrát aspoň přeloží, můžu ti pak říct, jestli to je dobrý kód nebo kravina.

[Mirek Prýmek]

Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.

Aha, takže opravdu byl problém v tom, že máte zmatek v pojmu relace na množině.

Krátká odpověď: === je definováno správně, == je definováno špatně. Oba dva operátory jsou definovány pro libovolné typy. Tohle úplně stačí jako důkaz, že vaše argumentace je nesmyslná, typy tady vůbec nehrají roli.

Delší odpověď: aspoň neformálně:

1. To, že je relace R "definovaná na množině" M znamená něco podobného jako definiční obor funkce. Díky tomu vím, že jestliže relace nějaké dva prvky z M "spojuje", tak ty prvky "jsou v relaci", něco pro ně platí, zatímco když v relaci nejsou (a jsou z M), tak to pro ně neplatí, a pokud něco není z M, tak o tom prostě R nic neříká. Například relace "být celočíselně dělitelný" je definovaná třeba pro celá čísla a neříká nic o vztahu mezi prvky množiny savců (netvrdí, že žirafa je dělitelná hrochem, ani že jím dělitelná není, prostě vztah "být dělitelný" nedává pro savce smysl, není pro ně rozumně definovatelný).

2. Relaci nazýváme ekvivalencí právě když je reflexivní, symetrická a tranzitivní. Z toho pak plynou různé praktické důsledky. Například to, že existuje jednoznačný rozklad množiny pomocí relace RE na "třídy ekvivalence" - tj. každému prvku z množiny M (tady vidíme, jak je M důležitá - nemluvíme o hroších, ale o prvcích z M) můžeme jednoznačně přířadit "třídu" - tj. podmnožinu M.

Abysme si znovu ověřili, že o typy vůbec nejde: můžu mít relaci isSameType(x,y), která spojuje hodnoty stejného typu - tj. rozděluje množinu všech hodnot daného jazyka na podmnožiny podle jejich typu. V jedné třídě rozkladu podle takové ekvivalence jsou pak integery, v jiné stringy.

3. Ano, skutečně 1 a "1" můžou být v relaci i když ta relace je ekvivalencí. Triviálně např relace implementovaná funkcí

Kód: [Vybrat]

function isAnything(x) { return true; }
QED. Tahle funkce sice neimplementuje "operátor ekvivalence" (programátorštinou), ale je to "ekvivalence" (matematicky). Chtít po operátoru ekvivalence, aby byl ekvivalencí, je velmi rozumný požadavek. Viz 2

SHRNUTO: 1. operátor ekvivalence je možné definovat nad různými typy a pořád to může být ekvivalence v matematickém smyslu (důkazem je ===). 2. pokud relace ekvivalencí není, ztrácím různé jistoty, nemůžu o ní tvrdit to, co bych mohl, kdyby ekvivalencí byla. 3. Čili bych měl mít setsakramentsky dobrý důvod, proč se o tyto jistoty připravit. Neměl bych je zahodit (a programátora uvést ve zmatek) jenom proto, aby mohli lidi v mém jazyce patlat páte přes deváte a nedejmatkopřírodo jim to nevyhodilo runtime error.

[Mirek Prýmek]

tj. každému prvku z množiny M (tady vidíme, jak je M důležitá - nemluvíme o hroších, ale o prvcích z M) můžeme jednoznačně přířadit "třídu" - tj. podmnožinu M.

Pokud je tohle potřeba opravdu polopaticky "programátorsky", tak: pokud je relace ekvivalencí, tak vím přesně, kolik má M tříd rozkladu a každou třídu můžu reprezentovat jedním prvkem. Když mám skutečnou ekvivalenci (s N třídami rozkladu), tak pak můžu třeba všechny hodnoty z M (klidně všechny hodnoty daného jazyka) roztřídit do N podmnožin jenom pomocí toho, že každou podmnožinu reprezentuju jedním prvkem a x, které chci zařadit, s každým z N "reprezentantů" porovnám. Díky tomu, že je relace ekvivalencí, vím jenom na základě těhle N porovnání, že prvek "si bude rovný" se všemi ostatními prvky v podmnožině. Už ho s nimi nemusím porovnávat.

U == z JS tohle udělat nejde, protože nevím, jestli 1 patří mezi "jedničky", protože 1==1 nebo mezi "stringy 1", protože 1=='1'.

[Cikáda]

Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.

Aha, takže opravdu byl problém v tom, že máte zmatek v pojmu relace na množině.

Krátká odpověď: === je definováno správně, == je definováno špatně. Oba dva operátory jsou definovány pro libovolné typy. Tohle úplně stačí jako důkaz, že vaše argumentace je nesmyslná, typy tady vůbec nehrají roli.

Delší odpověď: aspoň neformálně:

1. To, že je relace R "definovaná na množině" M znamená něco podobného jako definiční obor funkce. Díky tomu vím, že jestliže relace nějaké dva prvky z M "spojuje", tak ty prvky "jsou v relaci", něco pro ně platí, zatímco když v relaci nejsou (a jsou z M), tak to pro ně neplatí, a pokud něco není z M, tak o tom prostě R nic neříká. Například relace "být celočíselně dělitelný" je definovaná třeba pro celá čísla a neříká nic o vztahu mezi prvky množiny savců (netvrdí, že žirafa je dělitelná hrochem, ani že jím dělitelná není, prostě vztah "být dělitelný" nedává pro savce smysl, není pro ně rozumně definovatelný).

2. Relaci nazýváme ekvivalencí právě když je reflexivní, symetrická a tranzitivní. Z toho pak plynou různé praktické důsledky. Například to, že existuje jednoznačný rozklad množiny pomocí relace RE na "třídy ekvivalence" - tj. každému prvku z množiny M (tady vidíme, jak je M důležitá - nemluvíme o hroších, ale o prvcích z M) můžeme jednoznačně přířadit "třídu" - tj. podmnožinu M.

Abysme si znovu ověřili, že o typy vůbec nejde: můžu mít relaci isSameType(x,y), která spojuje hodnoty stejného typu - tj. rozděluje množinu všech hodnot daného jazyka na podmnožiny podle jejich typu. V jedné třídě rozkladu podle takové ekvivalence jsou pak integery, v jiné stringy.

3. Ano, skutečně 1 a "1" můžou být v relaci i když ta relace je ekvivalencí. Triviálně např relace implementovaná funkcí

Kód: [Vybrat]

function isAnything(x) { return true; }
QED. Tahle funkce sice neimplementuje "operátor ekvivalence" (programátorštinou), ale je to "ekvivalence" (matematicky). Chtít po operátoru ekvivalence, aby byl ekvivalencí, je velmi rozumný požadavek. Viz 2

SHRNUTO: 1. operátor ekvivalence je možné definovat nad různými typy a pořád to může být ekvivalence v matematickém smyslu (důkazem je ===). 2. pokud relace ekvivalencí není, ztrácím různé jistoty, nemůžu o ní tvrdit to, co bych mohl, kdyby ekvivalencí byla. 3. Čili bych měl mít setsakramentsky dobrý důvod, proč se o tyto jistoty připravit. Neměl bych je zahodit (a programátora uvést ve zmatek) jenom proto, aby mohli lidi v mém jazyce patlat páte přes deváte a nedejmatkopřírodo jim to nevyhodilo runtime error.

Opravdu nepotřebuju oprašovat znalosti relací.

Shrnuto: Takže jste vlastně řekl to, co tvrdím celou dobu. === je ekvivalencí, == ekvivalencí není, tudíž je nesmyslné chtít, aby == ekvivalencí bylo a máte použít ===.

[Mirek Prýmek]

A: == ekvivalencí není [=>] B: je nesmyslné chtít, aby == ekvivalencí bylo

Jak z A plyne B?

[ava]

Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.

Aha, takže opravdu byl problém v tom, že máte zmatek v pojmu relace na množině.

Krátká odpověď: === je definováno správně, == je definováno špatně. Oba dva operátory jsou definovány pro libovolné typy. Tohle úplně stačí jako důkaz, že vaše argumentace je nesmyslná, typy tady vůbec nehrají roli.
.....

Proboha, vždyť cikáda už dávno psal že

Kritizujete, že == není tranzitivní. Překvapivé to je, pokud JS neznáte. Kde je řečeno, že == má být tranzitivní? A váš pseudo argument s ekvivalencí je sice pěkný, ale == ekvivalencí být nemá.

...

Operátor ekvivalence, resp. toho, co jste chtěl, se v JS značí ===.

Tak nevím proč tu dalekosáhle vysvětluješ, že operátor == (který není ekvivalence), nemá vlastnosti ekvivalence.

Tím nechci obhajovat JS, ale tahle debata byla fakt zbytečná.

[Mirek Prýmek]

Tak nevím proč tu dalekosáhle vysvětluješ, že operátor == (který není ekvivalence), nemá vlastnosti ekvivalence.

Ne. Vysvětluju, že mít vlastnosti ekvivalence je velmi důležité a jenom tak pro prd je zahodit je příklad jedné z milionu zpraseností JS.

Tím nechci obhajovat JS, ale tahle debata byla fakt zbytečná.

Ne. Pro mě je hodně poučné vidět, do jakých absurdit je někdo schopný se dostat jenom aby nemusel:

Nestačilo by místo těch urážek a vymýšlení nesmyslných rádobyobhajob říct prostě "jo, tohle je sprasený, ale dá se s tím žít"?

...čímž by ta zbytečná debata okamžitě skončila a neřekl bych už ani popel.

[Cikáda]

@ava - děkuju

Tak nevím proč tu dalekosáhle vysvětluješ, že operátor == (který není ekvivalence), nemá vlastnosti ekvivalence.

Ne. Vysvětluju, že mít vlastnosti ekvivalence je velmi důležité a jenom tak pro prd je zahodit je příklad jedné z milionu zpraseností JS.

Tím nechci obhajovat JS, ale tahle debata byla fakt zbytečná.

Ne. Pro mě je hodně poučné vidět, do jakých absurdit je někdo schopný se dostat jenom aby nemusel:

Nestačilo by místo těch urážek a vymýšlení nesmyslných rádobyobhajob říct prostě "jo, tohle je sprasený, ale dá se s tím žít"?

...čímž by ta zbytečná debata okamžitě skončila a neřekl bych už ani popel.

Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===.  Dál už je diskuse opravdu zbytečná.

Hezký den

[andy]

Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===.  Dál už je diskuse opravdu zbytečná.

Já tomu asi nerozumím - argument je, že JS je stupidní jazyk, protože (a je to jeden příklad z mnoha) '==' není ekvivalence, zatímco v drtivé většině jazyků je. Takže je to neintuitivní a nestandardní a není pro to rozumný důvod. Dá se to brát jako jeden z historických hříchů, ale nějak nechápu logiku za tím tvářit se, že tohle není negativum toho jazyka, protože to programátor má vědět.