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 - Jiří Havel

Stran: 1 ... 12 13 [14] 15 16 ... 22
196
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 02. 04. 2020, 10:27:33 »
Takže z toho hrubého nadávání na Python, že nemá ordered dictionary nakonec vzešlo, že je vlastně nemá vůbec nic, krom toho Pythonu 3.7+. Tak teď by měl přijít naopak vychvalování Pythonu do nebes. :-)

Ehm, pan bude znalec.
Ordered map ma C++ s STL (Standard Templte Library) nekdy od sereho davnoveku 90tych let, Java dtto, akorat do verze 1.5 bez podpory generik.

Takze Python se v teto oblasti dotahl cca na uroven Javy 1.2 z roku 1998.

Mozna uz brzy uvitame python v tomto tisicileti.
Akorát že tohle jsou úplně jiné ordered mapy.

Ta c++ ordered mapa řadí prvky podle operátoru porovnání. Ve chvíli, kdy máme unordered mapu, tak už má ta ordered jen minimální využití. Vůbec bych se nedivil, pokud Pythonistům nijak zvlášť nechyběla.

Ta mapa, která PetroviK tak moc chyběla, prvky neřadí. Akorát drží pořadí, v jakém se do ní prvky vkládaly. V c++ nic takového nemáme (šlo by samozřejmě udělat) a zatím mi to nikdy nechybělo. Opět se vůbec nedivím, že se bez ní Pythonisti bez problémů obejdou.

197
Vývoj / Re:Dalsi, UZ POSLEDNI KIKS V PYTHONU
« kdy: 01. 04. 2020, 15:06:40 »
JSON zachovava poradi klicu, a proto kdyz mam knihovnu ktera deserializuje JSON, tak to MUSI TA KNIHOVNA ctit.

Kam na ty nesmysly chodíš? Co takhle si přečíst třeba JSON standard?

An object is an unordered set of name/value pairs.

No tak jsem se spletl no, my v Jave mame json odjakziva ordered, nikdo neni zvedavy na to aby se mu v logach prehazovala poradi atributu 8)
Tak jsem se schválně koukl do dokumentace. A třeba takový JsonObject je jednoznačně unordered. :D

198
Vývoj / Re:NoSql document databaze
« kdy: 29. 03. 2020, 09:57:54 »
1. Proc by mi nemel nejaka replika relacni databaze bezet? To prece neni vubec nromalni stav. Vam uz se nekdy na produkci snad stalo, ze vam z niceho nic nebezela replika Oraclu? A to jste na to nadaval, ze to tak je? Databaze ma byt schopna bezet NONSTOP. Takze tuhle vyhodu NoSql neberu, nevim co to je za usecase.
Protože spadla, indiáni vytrhali kabely, nebo nějaký jiný neplánovaný průser. Úplně normální stav, jen se děje zřídka.

A ve chvíli, kdy celý systém celý běží i ve chvíli kdy pár strojů ne, mám jako bonus i možnost ty stroje udržovat, aktualizovat a podobně bez jakéhokoliv viditelného výpadku. Tohle se u vás v korporátu nepovažuje za normální?

199
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 24. 03. 2020, 18:59:21 »
Tvl tady Pythonisti ani neznaji monady, a pritom my to v Jave pouzivame uz od verze 1.8  8)
No já jsem spíš Haskeller než Pythonista. Taže o sprostých slovech na M, A nebo i F vím svoje. Ten speciální filter nemá s monády vlastně nic až tak zásadně společného. A zrovna ten Haskell který ty monády proslavil má filter bez téhle vychytávky.

200
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 24. 03. 2020, 16:50:25 »
Nikdo se neodvazi? Jde to vubec v pythonu udelat? :D

Napis, co to ma delat, nikdo tu nema zajem lustit Tvoji pseudoseznamku v Lua.
Tak to ti nejspíš nenapíše. Vždyť to ani nedává smysl. :D Napřed získá holý seznam telefonních čísel a pak se ho snaží filtrovat jako jakýsi seznam trojic.


201
Vývoj / Re:C++ vs Rust
« kdy: 20. 03. 2020, 11:28:57 »
Rust si u mna urcite najde uplatennie, no napriek tomu nemam pocit ze by to bol ten jazyk, ktory zosadi z tronu C/C++ ale pripustam ze sa mozem mylit. Aky je vas nazor? Nahradi Rust C++? Alebo tu snami tato nehynuca klasika ostane az do konca vekov?
C++ tu zůstane stejně jako tu zůstal Cobol a Fortran. Už jen proto, že v něm máme člověko-staletí až člověko-tisíciletí existujícího kódu. Ten kód nikdo přepisovat nebude, protože to nikdo nezaplatí.

Rust si určitě uplatnění najde ale žádné sesazování z trůnu nebude. A něco z něho zpětně probublá i do nových verzí C++, které asi jako jediné mají šanci nahradit to současné C++.

202
Vývoj / Re:Interpolace bez linearni fce
« kdy: 20. 01. 2020, 13:36:18 »
Teda beru zpět to s těmi malými jmenovateli. Stačí pokud půjde ta tabulka při kompilaci doplnit o potřebné hodnoty pro násobení a shift.

203
Vývoj / Re:Interpolace bez linearni fce
« kdy: 20. 01. 2020, 13:21:11 »
Pokud jsou ty jmenovatele malé a tu tabulku by šlo při kompilaci nějak předžvýkat, tak se dělení známou konstantou dá převést na násobení.
https://gmplib.org/~tege/divcnst-pldi94.pdf

204
Odkladiště / Re:Smart home: definícia, skúsenosti
« kdy: 16. 01. 2020, 22:16:12 »
Snaha eliminovat vypinace na svetla v miestnostiach ako WC a chodba a nahradit ich detektorom pritomnosti (ci uz kombinacia so zabezpecovackou, drotove pirka largo od jablotronu napr, alebo cidla na dverach, podlahe, ci ine). Ma zmysel snazit sa riesit automatizovane zapnutie/vypnutie svetla v "jednoduchych" miestnostiach (alebo castiach). Napada ma led pasik na kuchynskej linke a vhodne nasmerovane "pir-ko".
Osobně jsem ještě nepotkal bezvypínačový záchod, kde bych furt nemusel mávat jak mažoretka. To samé chodby. Dost mě překvapilo, jak málo se někdy hýbu. Obzvlášť když dělám něco, k čemu potřebuju hodně světla.

Nejdůležitější na každé domácí automatizaci je, aby šla jednoduše vypnout a přemostit. Bez šroubováku, baterky a podobných věcí.

Nezapomeň na jednu důležitou věc. Všichni kromě tebe budou tu automatizaci vnímat jen tehdy, když se něco podělá. Nikoho nebude zajímat, jak dobře se používá když funguje. Musí se dobře používat hlavně v momentech kdy nefunguje.

205
Vývoj / Re:Naivní závislostní typ (úvaha)
« kdy: 15. 11. 2019, 12:46:09 »
...no a druhá možnost je, že to nebudou podtypy. Pak to ale bude strašná otrava používat.
Další možnost je zneškodnit reference na mutable. Pokud subtyping funguje jen s referencema na const, případně s kopírováním/slicingem, tak je to relativně ok.

Samozřejmě že zůstává problém, že inkrement Age už není Age. Takže není možné napsat ani klasický for cyklus tak, aby to prošlo typovou kontrolou. Musí se implementovat vlastní kontrolní struktury, které uvnitř ten typový systém obcházejí.

Ona je sranda i dělat výpočty s intervaly intů. Intervalová aritmetika trpí na "dependency problem". Nepříjeně často ten automaticky vypočítaný rozsah silně uletí. Tady jsem nebyl schopen dosáhnout nějaké přijatelné úrovně opruzu.

206
Vývoj / Re:Naivní závislostní typ (úvaha)
« kdy: 15. 11. 2019, 09:01:02 »
Nějakou dobu jsem s něčím podobným experimentoval. Konkrétně otagované a ohraničené integery v C++. Je trochu problém vybalancovat poměr přínos/opruz.

1) Interakce s vnějším světem se děje furt. Balení a vybalování toho intu musí být jednoduché. Tvoje typy se vyskytují jen na pár místech. Postupně se rozlézají, ale i tak je interakce s vnějším světem jedna z nejčastějších věcí.
2) Nenulové číslo nevznikne jen tak, ale obvykle nějakým testem na nulu. Takže to balení není jenom na hranici tvého světa.
3) U intů je to jednoznačné, ale s floaty přicházejí další problémy. Takové typy jako "normalizovaný vektor" nebo "ortonormální matice" jsou v praxi dost fuzzy.

207
/dev/null / Re:Těžké OOP problémy
« kdy: 13. 11. 2019, 19:22:08 »
U kvaternionů mi to nepřijde zajímavé, ale kdyby to bylo potřeba, šlo by pomocí záv. typů určit konkrétní vnoření. Toto je obecně problém restriktivní dědičnosti (na rozdíl od ampliativní).
Vůbec netuším, co má být ta restriktivní a ampliativní dědičnost. Tyhle termíny jsem ještě nepotkal a ani google mi nic užitečného nevrátil. Vztah kvaternionů a komplexních čísel rozhodně není klasické "is".

Minimálně ve 3D grafice je spousta možných konvencí, jak spasovat komplexní čísla a kvaterniony (vidím v nich primárně rotace). Ani jedna z těch konvencí není správnější než ty ostatní. Takže jazyk, typový systém ani knihovny toho nemůžou automaticky moc udělat, protože ani neví, co je správně. Obecně mi v podobných případech přijde jakákoliv automatizace nežádoucí a dobrá akorát jako zdroj zákeřných chyb.

208
/dev/null / Re:Těžké OOP problémy
« kdy: 13. 11. 2019, 15:07:46 »
Taky by se mi líbila taková jakože obecná dědičnost typů, kdy:
Number > Int > Age > Young
Přičemž by samozřejmě platilo, že jako Int mohu použít Age, ale naopak ne.

A přitom se s tím v jazycích vůbec nesetkávám.
To mám také na seznamu :) Swift to částečně má, ale protože mají dost omezenou dědičnost, špatně se to tam modeluje správně, abych měl něco jako Quaternion > Complex > Real > ...
Jinak, jaký kvaternion odpovídá komplexnímu číslu? Nemám pocit, že by to šlo úplně jednoznačně překlopit.
Neexistuje kanonické vnoření ℂ do ℍ, ale jinak by tam problém neměl být.
Já vidím podobný problém jako při automatickém převodu mezi 2D a 3D vektory. Která rovina ve 3D odpovídá té 2D? Konvencí je mračno a vnutit nějakou na úrovni jazyka mi nepřijde úplně vhodné.

209
/dev/null / Re:Těžké OOP problémy
« kdy: 13. 11. 2019, 14:37:36 »
Taky by se mi líbila taková jakože obecná dědičnost typů, kdy:
Number > Int > Age > Young
Přičemž by samozřejmě platilo, že jako Int mohu použít Age, ale naopak ne.

A přitom se s tím v jazycích vůbec nesetkávám.
To mám také na seznamu :) Swift to částečně má, ale protože mají dost omezenou dědičnost, špatně se to tam modeluje správně, abych měl něco jako Quaternion > Complex > Real > ...
Na tohle by mohly z větší části stačit implicitní konverze, ne?

Jinak, jaký kvaternion odpovídá komplexnímu číslu? Nemám pocit, že by to šlo úplně jednoznačně překlopit.

210
/dev/null / Re:Těžké OOP problémy
« kdy: 13. 11. 2019, 11:50:22 »
Hezký. Co tam v tom seznamu máš dál? :-)
Když vynechám poměrně běžné věci, který ale chybí zrovna v tom jazyku, kle to potřebuju, tak to už je poměrně specifické. Jedna věc je mít literály s jednotkami a symbolickým “usuzováním,” abych třeba mohl zapsat číslo jako 1234 kg m s-2 a abych to mohl porovnat s 1234 N, ale ne třeba s 1234 J (tam je totiž m2). To by se hodilo pro (numerické) výpočty ve fyzice. Další rozšíření syntaxe je umožnění zapisování tenzorů (nebo netenzorů, se kterými se počítá jako s tenzory, například Christoffelových symbolů) s kontrolou při překladu (opět obdoba typové kontroly), že indexy jsou správně kontra- či kovariantní. To pak souvisí - na úrovni implementace - s vektorovou implementací atd. S tím souvisí i ty jednotky, všechny komponenty vektoru/tenzoru by měly mít stejnou, takže kromě indexů chci i zajistit shodnost jednotek v (ct,x,y,z) apod. (tj. zařvat, když někdo zapomene c). Prostě věci ze symbolické a numerické matematiky na úrovni, kterou nemají ani specializované jazyky jako R.

Doufal jsem, že tyto praktiky se používají v jazycích, které nabízí možnost tvořit vlastní typy. Zkusil jsem to v Haskellu a fungovalo to bezvadně. Jen mi pak bylo vysvětleno, že se to takhle nedělá, že se to mydlí jedním typem.
Minimálně je na tohle C++ knihovna v boostu. https://www.boost.org/doc/libs/1_71_0/doc/html/boost_units.html
Šablony jsou mocné. Jen kdyby se to dalo i číst.

Stran: 1 ... 12 13 [14] 15 16 ... 22