Co si myslíte o OOP?

[operator]

...A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...

Jak může C chybět OOP, když není konstruované pro daný typ úloh, pro danou úroveň abstrakce? To byste mohl pak říci o každém jazyku, že mu chybí OOP.

a) Nemohl, protoze ne vsem jazykum chybi.
b) Jazyku C chybi proto, ze pro nej vznikaji veci jako gtk, kde by se - byt treba primitivni a jednoduche - OOP zatracene hodilo.

[Reklama]

[operator]

Svet musis digitalizovat, ale nemusis mit staticka data.

Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.

V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.

Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?

Ano, data musim zjednodusit,  ale z toho nevyplyva, ze datovy model musi byt staticky a nemuze se prubezne menit.

Int je v Pythonu objekt, jeho interni reprezentace je interni, o tu se nestaras a ani nemas starat, nema zadnou nativni binarni reprezentaci, jeho  nativni  repr()  reprezentace je textova, ktera funguje napric vsemi platformami. Jak si ho ulozis do binarního souboru pomoci struct je na tobe a stejnym zpusobem ho pak musis nacist, coz funguje spolehlive napric platformami. Za vyjimku by slo povazovat pickle, ktere ma i binarni format, opet kompatibilni napric platformami, pokud obe strany podporuji stejnou verzi protokolu.

[PetrM]

Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... 

[Kadet]

Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... 

Vzorky:
1. Muzu tu zpravu o novym vzorku poslat dal a ve svym systemu nic neukladat.
2. muzu s tim rovnou pracovat aniz bych to ukladal

python a inty:
pripada mi, ze jsi zamrznul cca tri desetileti nazpet a porad se snazis optimalizovat driv nez vyresis problem. Ztracis se tak v ruznych loopech, bitech, bajtech a podobnych low level srackach. Mezitim se svet posunul a zacal pouzivat abstrakce aby tenhle prasecak nemusel resit.

Pokud porad programujes na ENIACu, tak te chapu.

[gll]

Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... 

Něco si k tomu vygooglete. Začněte tutoriálem. Tady vám to nikdo do podrobna nevysvětlí, zbytečně o bychom přepisovali dokumentaci.

pro úspornou reprezentaci pole čísel můžete použít třeba array.array nebo numpy.array

https://docs.python.org/3/library/array.html

[Reklama]

[operator]

Svet musis digitalizovat, ale nemusis mit staticka data.

Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.

Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.

Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Koukam zes to odpovedel za me.

[operator]

Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Ale to nikdo nerozporuje, jen jde o to, ze struktura ulozeni dat muze byt samopopisna a dynamicka, nemusi byt staticka a nemenna.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... 

Ano, je to super, pohodlne se s tim pracuje, je vyloucena rada chyb s kterymi senty potykas, takze vyvoj je rychly, bezproblemovy a levny. Stoji to jen trochu pameti a vykonu navic, coz v dnesni dobe na vetsinu uloh neni zadny problem a optimalizuje se to nanvykon teprve tehdy, kdyz to ma smysl. Neni problem v pythonu programovat na raspberry pi, takze bezne uzivatelske stroje, o nekolik rwdu vykonnejsi jsou hodne za vodou. A optimalizovat kriticka mista v Python kodu a prepsat je do C je dnes hracka, protoze Cython.

[operator]

Jsem rad, ze tu PetrM ma sarkasticke pripominky. Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru, jejich mimoradne hlubokou brazdu statickeho mysleni, ze ktere nejen ze neumi vyjet, oni z ni uz ani nevidi ven. Ukazuje to, ze dokazi veci nazirat jen jednim zazitym zpusobem a tim jsou svazani. A vysvetluje to, proc nemaji radi dynamicke jazyky. Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti, snazi se je pouzivat staticky, coz samozrejme nefunguje dobre a oni jsou tim frustrovani.

[Kit]

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.

Zase ho nezaskočí výpočet 500**8 jako třeba v C. Podobně nebudeš mít problémy s poli, které jsou v C běžné. Nativní výpočty s komplexními čísly jsou určitě výhodnější než přes nějaké knihovny.

Jazyk C je prostě zastaralý a drží se jen díky tomu, že pro vývoj nízkoúrovňových komponent operačního systému není nic lepšího. Na aplikace se však nehodí.

[Mirek Prýmek]

Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru

Mno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C?

[gll]

Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru

Mno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C?

Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.

[Mirek Prýmek]

Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.

Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.

[gll]

Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.

Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.

je to implementováno stejně jako všechny vestavěné typy cpythonu.

[Mirek Prýmek]

je to implementováno stejně jako všechny vestavěné typy cpythonu.

Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c

[gll]

je to implementováno stejně jako všechny vestavěné typy cpythonu.

Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c

to jsou jen pomocné funkce, které přímo z pythonu volat nelze.

ndarray je implementováno tady

https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c

všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.

https://docs.python.org/3/extending/newtypes_tutorial.html