Is this you? As a journalist, you can create a free Muck Rack account to customize your profile, list your contact preferences, and upload a portfolio of your best work.
Claim your profile
Articles by Jiří Raška
Nový český cloud od T-Mobilu je hezký start, ale na americké obry to zatím opravdu nemá
Start T-Mobile Business Cloud v tuzemském datacentru DC7 je skvělá zpráva. Máme v Česku dalšího hráče, který staví veřejný cloud s lokální datovou rezidencí, má za zády Deutsche Telekom, umí naceňovat transparentně a nespadá přímo pod americký Cloud Act ani FISA (zákony umožňující vydávat data zákazníků, a to i bez jejich vědomí). To všechno je správně a já operátorovi fandím.
Detectron2 - jak vlastně funguje
Hned na začátku se musím omluvit za poněkud zavádějící nadpis. Detectron 2 je jeho autory označován za platformu pro detekci objektů, segmentaci a další vizuální úkoly. Co si pod tím ale představit? Jedná se o sadu modelů, které byly pro tyto účely navrženy a trénovány na vybraných datových sadách. Vy si můžete tyto modely stáhnout včetně zdrojových kódů a používat v souladu s licencí.
Detectron2 – hra na špióny - Root.cz
Trénování modelu na datové sadě Satellite Small Objects Dostávám se k zásadnímu tématu tohoto článku. Vyjdu z existujícího modelu knihovny Detectron2, který byl původně trénovan na datové sadě COCO. Následně jej budu trénovat na nové datové sadě Satillite Small Objects. Cílem je dostat model, který bude umět lokalizovat objekty známé právě z této datové sady. Otázka je, proč nezačít z čistého modelu (model s váhami náhodně generovanými) a netrénovat jej pouze na nové datové sadě.
Mravenčí kolonií na Nurikabe
Do konstruktoru třídy se předávají dva parametry: shape – rozměry hrací desky islands – vodítka umístění ostrovů, tedy souřadnice a jejich velikosti Dále se v rámci konstruktoru inicializuje globální feromonová stopa pheromone_matrix. Jedná se o pole ve stejném rozměru jako je hrací deska. Na počátku je hodnota feromonu pro každou dlaždici nastavena na hodnotu tau0. metoda solve() Jedná se o hlavní výkonnou metodu třídy. Opakovaně vytváří generace mravenců voláním metody generation().
Variational AutoEncoder na ořechy
Variational AutoEncoder (dále také VAE) je dost zajímavý model, který se obvykle řadí k těm generativním. Svou strukturou vychází z běžného AutoEncoder modelu (dále také AE), rozdíly najdete především ve struktuře jeho vnitřní reprezentace. Zatímco AE má vnitřní reprezentaci obrázku tvořenou n-rozměrným vektorem čísel, VAE tuto vnitřní reprezentaci vytváří ve formě pravděpodobnostního rozložení pro každou vlastnost. Trochu blíže se k modelu dostanu v průběhu článku.
AutoEncoder na ořechy
Ony ty AutoEncoder modely jsou na první pohled sice jednoduché, ale jejich využití je dost zajímavé. Jednou z oblastí využití je tzv. Anomaly Detection (někdy také Outlier Detection). Už jsem se této oblasti dříve dotkl, ale dnes se pokusím na ně podívat poněkud důkladněji. Jen pro připomenutí, každý takový AutoEncoder model má dvě části. První je tzv. Encoder, jehož vstupem je zdrojový obrázek.
Lokalizace infekce malárie - AutoEncoder
V článku Lokalizace infekce malárie – klasifikační model a heatmap jsem se pokusil rozšířit výstup klasifikačního modelu o lokalizaci místa v obrázku, na základě kterého model došel ke svému závěru. Stále jsem ale vycházel z toho, že mám připravena vzorová data (obrázky) a jim odpovídající klasifikaci (metoda z kategorie Supervised learning). A v tom může být někdy zádrhel.
Lokalizace infekce malárie - klasifikační model a heatmap
Tímto příspěvkem bych chtěl volně navázat na předchozí články zabývající se klasifikací obrázků do několika tříd. V těch dřívějších článcích se jednalo o rozpoznání zápalu plic na základě RTG snímků. Pokud bych měl rychle shrnout jejich obsah, pak se jednalo o to, že jsem měl k dispozici snímky zdravých plic a snímky se zápalem. Úkolem hledaných modelů bylo najím způsob, jak rozlišit jedny od druhých.
Segmentace MRI mozku - knihovna TASM
Dnes to bude taková rychlá akce. Mým cílem je vytvořit nástroj na sémantickou segmentaci obrázků (jak jsem již několikrát dělal v předchozích článcích), ale s co možná nejmenším programátorským úsilím. Doposud jsem si vždy nějakou část modelu skládal vlastníma rukama z různých typů konvolučních bloků. Ale ono to může jít i jednodušeji. Prvním ulehčením práce je tzv. „transfer learning“, kdy jsem kontrakční fázi modelu postavil na existujícím klasifikačním modelu. To bylo v předchozím dílu.
Segmentace MRI mozku - Transfer Learning
V předchozích dvou článcích jsem vytvářel modely pro sémantickou segmentaci obrázků takzvaně „z čistého stolu“. Dělal jsem to proto, abych si lépe ověřil, jak modely fungují. Popravdě řečeno, takto se to dnes asi běžně nedělá. Obvykle autoři vychází z již existujících modelů, které pak přizpůsobují konkrétnímu úkolu. A to tom bude můj dnešní příspěvek. Základem každého segmentačního modelu založeného na konvolučních vrstvách je klasický klasifikační model.
Segmentace MRI mozku - DeepLabV3 model
Dnes bych se rád podíval na další typ modelu pro sémantickou segmentaci obrázků, a tím je DeepLabV3. Důvodem, proč jsem si vybral právě tento, je použití bloku Spatial Pyramid Pooling a s ním spojené Atrous Convolution. K tomu se dostanu ale až u návrhu samotného modelu. Pro své pokusy opět využiji datovou sadu Brain MRI segmentation stejným způsobem, jako tomu bylo v předchozím článku Segmentace MRI mozku – U-Net mode.
Segmentace MRI mozku - U-Net model
V předchozích několika článcích jsem se zabýval problémem klasifikace RTG snímků. Ve své podstatě jsem hledal odpověď na otázku, zda je na konkrétním RTG snímku možné rozpoznat zápal plic pacienta nebo nikoliv (jednalo se tedy o binární klasifikaci s odpovědí ano/ne). Co kdyby mne zajímala odpověď na otázku, ve kterém konkrétním místě ten problém je. Chtěl bych vidět místo na obrázku, které vede k závěru, že pacient danou nemoc má.
Rozpoznání zápalu plic z RTG snímků - ViT model
Po nástupu GPT modelů se stala architektura transformerů velice oblíbenou i v jiných oblastech. Najednou vidíte tyhle modely založené na Attention všude. Nabízí se tedy vyzkoušet si je na vlastní kůži. A o tom bude tento článek. Opět vycházím z datové sady Chest X-Ray Images (Pneumonia) stejně jako tomu bylo v předchozích článcích zabývajících se rozpoznáním zápalu plic z RTG snímků s využitím především konvolučních vrstev.
Rozpoznání zápalu plic z RTG snímků - díl třetí
Navazuji na předchozí dva články: Rozpoznání zápalu plic z RTG snímků – díl první a Rozpoznání zápalu plic z RTG snímků – díl druhý . Jedná se o jeden z nejúspěšnějších a také nejoblíbenějších modelů pro klasifikaci postavených na konvolučních vrstvách. Jeho autorům se podařilo vyřešit problém s degradací gradientu u modelů s hodně vrstvami. Jejich řešením je doplnění „zkratky“ pro data postupující sítí.
Rozpoznání zápalu plic z RTG snímků - díl druhý
Tímto článkem navazuji na předchozí: Rozpoznání zápalu plic z RTG snímků – díl první . Jedná se o jeden ze základních modelů pro klasifikaci obrázků založených na konvolučních vrstvách. Principem je postupné zmenšování plošných dimenzí a naopak rozšiřování velikosti vlastností.
Rozpoznání zápalu plic z RTG snímků - díl první
V tomto článku a několika následujících bych se rád podíval na problematiku klasifikace obrázků. Posouvám se tedy od jednorozměrných signálů, jak tomu bylo u EKG křivek, ke dvěma rozměrům v případně snímků. Jako téma jsem si vybral opět něco z oblasti zdravotnictví, a tím je rozpoznávání zápalu plic z rentgenových snímků. Důvodem je opět dostupnost vhodných dat pro experimentování. Zvolil jsem si velice oblíbenou datovou sadu poskytovanou na serveru Kaggle: Chest X-Ray Images (Pneumonia).
Posílení klasifikace EKG
Název článku vypadá zvláštně, ale jeho cíl bude po krátkém vysvětlení asi zřejmý. V několika předchozích dílech povídání jsem se zabýval modely pro klasifikací elektrokardiografu (EKG) s využitím 1D a 2D konvolučních sítí. V tomto volně navazujícím článku si vyberu jeden z těchto modelů a pokusím se jeho výsledky vylepšit pomocí tzv. Ensemble Learning Methods. Všechny kroky budu provádět na stejné datové sadě, tedy PTB-XL ECG dataset.
Klasifikace Elektrokardiogramu (EKG) jako služba
Root.cz » Blogy » Trpaslíkův blog » Klasifikace Elektrokardiogramu (EKG) jako služba V tomto článku bych rád navázal na předchozí zabývající se klasifikací EKG signálů s využitím konvolučních neuronových sítí. Na problematiku bych se chtěl ale podívat poněkud z jiného úhlu. Dejme tomu, že již jsem spokojen s výsledky nějakého modelu a chtěl bych jej začít aktivně používat.
Klasifikace Elektrokardiogramu (EKG) - díl třetí a poslední
Tento článek navazuje na předchozí: Klasifikace Elektrokardiogramu (EKG) – díl druhý. Další oblastí, kterou bych chtěl ověřit, je kombinace výše vytvořených modelů pro samostatné vstupní datové sady do jednoho modelu.
Klasifikace Elektrokardiogramu (EKG) - díl druhý
Tento článek navazuje na předchozí: Klasifikace Elektrokardiogramu (EKG) – díl první. Co ode mně můžete v této kapitole očekávat? Nejdříve se budu zabývat modely pro každou vstupní sadu (X, Y a S) samostatně. V případě datové sady X to budou plně propojené neuronové vrstvy. U datové sady Y, jak již vyplývá z podstaty EKG křivek, to budou 1D konvoluční sítě. No a v případě datové sady S pak oddělené 2D konvoluční vrstvy pro každý svod zvláště.
Klasifikace Elektrokardiogramu (EKG) - díl první
Jedním z prvních problémů, na které člověk narazí při vytváření modelu je, kde vzít nějaká rozumná data. Modely budu vytvářet v prostředí Kaggle, proto jsem nejdříve zamířil do dat poskytovaných na tomto serveru. Pro své pokusy jsem si vybral datovou sadu PTB-XL ECG dataset.
Klasifikace EKG křivek - výlet do světa neuronových sítí
Úprava zdrojových dat pro trénování neuronové sítě Na tomto místě je dobré si uvědomit, jak vzorky dat vznikly. EKG křivky každého pacienta byly rozsekány na jednotlivé segmenty podle srdečního úderu a zařazeny do dat jako samostatné vzorky. Z toho vyplývá, že v datech mám hodně křivek od jednoho pacienta, takže mezi nimi bude jistě úzký vztah. Z toho vyplývá, že mezi daty v trénovací a validační sadě bude nějaký vztah. Udělat s tím moc nemůžu, jen je potřeba si být toho vědom.
Detekce anomálií v auditních záznamech - časové řady
<class 'pandas.core.frame.DataFrame'> Index: 370176 entries, 1ee1cac9-c84b-4b2d-a8f3-db6b7eed59fd to e31d4699-a65b-4f2b-84ff-bc2194396cf7 Data columns (total 7 columns): # Column Non-Null Count Dtype --- ------ -------------- ----- 0 ts 370176 non-null datetime64[ns] 1 event 370176 non-null object 2 org 370176 non-null object 3 usr1 21213 non-null object 4 usr2 40299 non-null object 5 usr3 1022 non-null object 6 peer 314766 non-null object dtypes: datetime64[ns](1), object(6) memory usage:...
Detekce anomálií v auditních záznamech
Ve třetím pokračování svého povídání o sledování událostí v aplikaci jsem vytvářel auditní záznamy a ty pak zapisoval do SQL databáze. Je to asi jeden z obvyklých způsobů, jak s nimi nakládat. Vzniká tak docela velká databáze auditních záznamů, které mohou velice rychle dosáhnout stovek tisíc či miliónů řádků. Databázi ale nedělám, abych data pouze sbíral. Potřebuji s nimi i následně pracovat.
Spring Boot Actuator - metriky a aplikační koncové body
Článek je pokračováním Spring Boot Actuator – sledování stavu aplikace. Metriky provozu aplikace Detailní popis vlastností Spring Boot Actuator pro tuto oblast najdete v kapitole: 6. Metrics. Příklady pro tuto kapitolu najdete v jraska1/jv-actuator-examples/example-03. Nyní již máme představu z čeho je aplikace poskládaná, v jakém prostředí běží, a nakonec také o tom, jak fungují její části a aplikace jako celek. Nemáme zatím ale úplně představu, jak je naše aplikace využívaná.
Shikaku - hrátky s obdélníčky
Shikaku je jedna z japonských logických her, kterou publikoval časopis Nikoli. Jako obvykle se jedná o deskovou hru, kterou je možné hrát na čtvercové nebo obdélníkové desce. Úkolem je rozdělit desku na obdélníky, které jí plně pokrývají a vzájemně se nepřekrývají. Každý obdélník je určen jednou pozicí na desce s číslem udávajícím jeho plochu ve čtvercích. V zadání úlohy je tedy na desce tolik čísel, kolik je požadovaných obdélníků. Součet čísel pak představuje plochu celé desky.
Události v aplikaci - II
Tento článek navazuje na předchozí příspěvek Události v aplikaci – I. Události Pokud jste někdy přišli do styku s komunikací přes message broker s využitím vzoru publish-subscribe, pak vám systém aplikačních událostí ve Spring bude jistě hodně blízký. V podstatě úlohu message brokeru v tomto případě plní Spring kontext. Témata se nespecifikují explicitně. Tématem a událostí zároveň může být instance třídy odvozená od společného předka ApplicationEvent.
Futoshiki - geneticky
Dříve jsem v reprezentaci řešení napsal, že každý gen může nabývat hodnot z rozmezí 1..N. Ono to ale není tak úplně pravda. V případě, že mám v zadání specifikovánu hodnotu konkrétního políčka (genu), pak chci, aby gen nabýval pouze této hodnoty.
Futoshiki - constraint programming
Hlavní navigace Dnes 0:00 Jiří Raška V předchozím příspěvku jsem se pokusil naprogramovat řešení hry Futoshiki s využitím backtracking. To bylo to první, co mne napadlo. Nicméně jsem se dále pokusil vyzkoušet i jiné přístupy, které by mohly vést k vyřešení takové hry. Jako alternativní způsob jsem vyzkoušel tzv. Constraint Programming. No, ono to zase až takové programování není. Podstatou je vytvoření nějakého modelu, na který se pak pošle solver.
Futoshiki - klasicky
Vytvořil jsem si třídu GameBoard, do které při vytvoření instance zadám hodnoty políček jako dvourozměrný seznam, a seznam omezení pro vybraná políčka (to jsou ty dvě posledním metody ze zdroje testovacích dat). Aby se mně s čtvercovou maticí hodnot lépe pracovalo, udělal jsem si z něj pole v numpy.
Služby v distribuovaných systémech – konfigurace sítě - Root.cz
Služby v distribuovaných systémech – konfigurace sítě Vrátím se k úvodnímu článku série, kde jsem také napsal: Jen pro připomenutí, pokud mluvím o distribuovaných systémech, pak se mně jedná především o nezávisle běžící informační systémy. Těch mohou být desítky nebo stovky, provozované různými subjekty ve vlastních provozních prostředích. Bude se tedy primárně jednat o spolupráci mezi systémy, která by měla být výhodná pro všechny zúčastněné.
Služby v distribuovaných systémech – vzdálené úložiště dat - Root.cz
Obdobnou problematikou jsem se zabýval dva články nazpět. Tehdy šlo o centrální sběr dat od komunikačních uzlů a jejich případné další zpracování. V tomto případě nejde ani tak o to, abych dostal nějaká data na jednu hromadu. Jde o to, aby každý uzel měl možnost odložit nějaká svá data na externí úložiště a následně si je vyzvednout a dále s nimi pracovat. K čemu by to mohlo být dobré? Zkusím to naznačit na příkladu sítě automatizovaných meteorologických stanic, který jsem používal již dříve.
Služby v distribuovaných systémech – centrální sběr dat - Root.cz
Námětem následujících tří článků budou centrální služby v distribuovaných systémech. Že je to protimluv? Myslím, že to tak působí jen zdánlivě. V případě centrálních služeb každý účastník ví, na jakém místě, kdo a jakou službu poskytuje. Je to obvykle zadáno v rámci konfigurace každého uzlu zapojeného do sítě. Na druhou stranu ten, kdo poskytuje nějakou centrální službu, nemusí vědět, kdo a z jakého místa jeho službu využívá. Pro pochopení asi budou lepší příklady.
Služby v distribuovaných systémech: proč vlastně komunikovat - Root.cz
Navazuji na předchozí sérii článků Komunikace v distribuovaných systémech, ve které jsem se primárně zaměřoval na možnosti komunikace mezi různými systémy s využitím centrálního message brokeru. Zatímco v předchozí sérii článků jsem ukazoval možnosti komunikace, tedy „jak“ se dá komunikovat mezi nezávislými systémy, v této sérii bych se rád zaměřil na otázku „proč“ komunikovat.
Komunikace v distribuovaných systémech: směrování dle obsahu - Root.cz
Jeho použití ukážu na příkladu uzlů poskytujících několik služeb najednou. Bližší informace najdete také v Content Based Router. Doposud jsem měl vždy vytvořeno několik poskytovatelů služeb. Každý z nich poslouchal na jedné frontě a poskytoval implementaci jedné služby. Jsou to ale takové ty školní příklady. V reálném životě budu mít uzlů, rozuměj také poskytovatelů služeb, desítky nebo stovky. Navíc budou obvykle poskytovat více služeb. Opět to mohou být desítky služeb na jeden uzel.
Komunikace v distribuovaných systémech: digitální podpisy zpráv - Root.cz
Ve stejné pozici jste, pokud požádáte jiný uzel o službu. Jak si můžete být jisti, že vám odpověděl právě tento uzel? To jsou velice důležité otázky, pokud operujete v síti strojů, které nejsou ve správě jednoho subjektu. V tomto článku vám neodpovím na všechny otázky s tímto fenoménem spojených. Podívám se na jeden dílčí problém, a sice jak si ověřit, od koho jsem zprávu dostal. Jednou z možností jsou digitální podpisy každé právy pomocí dvojice asymetrických klíčů.
Komunikace v distribuovaných systémech: komprese zpráv - Root.cz
V mém případě malých testovacích zpráv tomu tak není, ale pokud by součástí požadavku nebo odpovědi na službu byl nějaký velký objekt, např. obrázek, pak by situace byla výrazně jinačí. Co tedy s tím? Asi máme dvě možné cesty, kam se vydat. První možností je zvolit nějaký vhodnější formát, asi binární, pro výměnu zpráv mezi komunikujícími uzly. Možností je opět více, např. BSON, když už jsem se dříve přihlásil k jeho strýci JSONovi. Tím se ale dnes zabývat nebudu.
Komunikace v distribuovaných systémech: serializace zpráv - Root.cz
Naco serializace, když jsme jí doposud nepotřebovali a fungovalo to? Popravdě řečeno, my jsme jí dělali, ale implicitně. Camel před odesláním zpráv do message brokeru sám provedl serializaci Java bean do proudu bytů, které předal dále jako obsah zprávy. Ověřit si to můžete tak, že u předka všech posílaných zpráv, tedy u třídy Token, vyhodíte implementaci rozhraní Serializable. Pokud se pokusíte vyvolat nějakou službu, skončí to na výjimce java.lang.NullPointerException.
Komunikace v distribuovaných systémech: dynamické směrování - Root.cz
To může být pro některé služby postačující řešení. Pokud ovšem začneme pracovat se sítěmi, kde jsou zapojeny desítky nebo stovky uzlů, pak již toto řešení postačovat nebude. Dnes vám ukážu, jak je možné zadat do volání služby, koho chceme oslovit. Cíle již nebudou natvrdo zadané v definicích cest, ale budou se sestavovat dynamicky při volání. V dnešním článku si vystačím s jedinou službou typu požadavek/odpověď.
Komunikace v distribuovaných systémech: časové limity služeb - Root.cz
Představte si, že máte síť desítek nebo stovek uzlů, které jsou rozprostřeny po celé republice. Jediné jejich pojítko je centrální message broker, přes který si vyměňují zprávy. Je naprosto běžné, že síťová spojení jsou pomalá a nestabilní. Komunikační uzly se obvykle baví s jinými aplikacemi, od kterých získávají data. No a ty mohou opět vypadávat nebo být pomalé. A navíc se k tomu přidává provoz v různých datových centrech v kombinaci s lidským faktorem.
Nezávazné bádání nad časovou náročností programu - II
X = 100 MAX_A, MAX_Y = 10, 1000 SAMPLE_FUNCTIONS = { 'O(1)': (lambda x, a, b: a + b * np.ones(x.shape), MAX_Y / 2), 'O(log n)': (lambda x, a, b: a + b * np.log2(x), MAX_Y / np.log2(X)), 'O(n)': (lambda x, a, b: a + b * x, MAX_Y / X), 'O(n^2)': (lambda x, a, b: a + b * np.power(x, 2, dtype=float), MAX_Y / np.power(X, 2, dtype=float)), 'O(n^4)': (lambda x, a, b: a + b * np.power(x, 4, dtype=float), MAX_Y / np.power(X, 4, dtype=float)), 'O(2^n)': (lambda x, a, b: a + b * np.power(2, x,...
Nezávazné bádání nad časovou náročností programu - I
Počátečním impulzem pro následující nezávazné pojednání byla hra BENDER – Episode 3. Podstatou úkolu bylo zjištění z naměřených dat, jaké asi komplexnosti je program v závislosti na velikosti testovacích vzorků dat. Zadání úkolu je dosti návodné, takže vás nebudu obtěžovat popisem svého řešení. Jistě vymyslíte vlastní řešení, pokud vás to bude zajímat. Na druhou stranu je to problematika, která mne zaujala a řekl jsem si, že bych se na ní rád něco přiučil.
Komunikace v distribuovaných systémech: volání cest z aplikace - Root.cz
Daleko častěji potřebuji volat cestu z prostředí vlastní Java aplikace. Jedná se především o Camel cesty v roli žadatel. V případě komunikace typu zaslání zprávy nás nezajímá výsledek služby. Naopak v případě komunikace typu požadavek/odpověď nás výsledek zajímat bude. Rádi bychom jej dostali zpět do aplikace a nějak s ním dále pracovali. V případě Camel cest, které plní roli poskytovatele, je tomu trochu jinak. Ty jsou iniciovány požadavkem, který přišel do jejich QUEUE nebo TOPIC.
Za DASTA zprávy validní
Vzhledem k mé pracovní náplni se opakovaně setkávám se zprávami ve formátu DASTA, a to od různých výrobců informačních systémů ve zdravotnictví. Jedná se o XML zprávy, které mají standardizovaný obsah a strukturu. Postupem času vzniklo více verzí tohoto národního standardu, nicméně v posledních letech se setkávám se zprávami v DASTA ver.3 (tahle větev se již nerozvíjí) a DASTA ver.4. Struktura zpráv ve formátu DASTA ver.3 se řídí dle DTD specifikovaného tímto standardem.
Komunikace v distribuovaných systémech: synchronní komunikace typu požadavek a odpověď - Root.cz
Příklady k tomuto článku je možné najít v balíčku example02. Předávané zprávy Stejně jako tomu bylo v případě předávání zpráv, potřebuji mít vydefinované typy zpráv. V mém případě se bude jednat o Java Bean, které budou představovat požadavek na službu a její výsledek. Jejich definice je v balíčku entity. Je tam abstraktní třída Token, kterou budu používat jako předchůdce pro všechny vyměňované zprávy.
Sudoku - genetický algoritmus
V posledních dnech všichni čekají na novou mutaci koronáče, britského, jihoafrického, či z jiného koutu světa. Rozhodl jsem se, že už čekat nebudu, a zamutuji si sám. Navíc jsem si u toho i něco pokřížil … V rámci dřívějšího řešení Sudoku pomocí hrubé síly mne napadlo, zda by nešly použít pro řešení také genetické algoritmy. Ty se používají pro hledání optimálních řešení u složitých úloh. Nejsou mně schopny zajistit to nejlepší řešení, ale mohly by najít alespoň nějaké.
Sudoku - řešení silou - Root.cz
Jak říkal můj kolega Kadlčík: když máš v ruce kladivo, tak ti všechno připadá jako hřebík. Opět se vracím k řešení nějaké hry, a sice Sudoku. Nejdříve zkusím řešení s využitím síly Depth-first search (DFS). V případě Sudoku se jedná o hru s čísly ve dvourozměrné matici 9×9 kostek s čísly v rozsahnu <1..9>. Mohl bych pracovat přímo s dvourozměrnou matící, třeba s využitím numpy, nicméně v prvním kole si zkusím vystačit s normálními řetězci.
Komunikace v distribuovaných systémech: asynchronní předávání zpráv - Root.cz
Všeobecný úvod k sérii článků Zabývám se návrhem a vývojem distribuovaných komunikačních systémů již řadu let. Tak jsem si řekl, že by nebylo špatné shrnout některé své zkušenosti a nabídnout je k širší diskuzi a použití. Moje představa je taková, že postupně vytvořím sérii článků, ve které ukážu návrh a postup realizace některých základních funkcí distribuovaného informačního systému. O jaký systém se bude tedy jednat?
Show More
loading
Actions
Is this you?
As a journalist, you can create a free Muck Rack account to customize your profile, list your contact preferences, and upload a portfolio of your best work.Get in touch with Jiří
Contact Jiří, search articles and posts on X, monitor coverage, and track replies from one place.
Learn more about Muck Rack