Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
"user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user4";"3";"4" "user5";"4";"3" "user6";"4";"2" "user7";"4";"1"Pokud chci 3 záznamy řazené podle 2. sloupce a potom 3. sloupce, tak to musí vrátit user1, user2, user4. Nepřišel jsem na optimální algoritmus jak dostat 3 záznamy aniž bych musel přečíst celý 1. soubor, celý 2. soubor a pak to limitovat až ve výsledku, což je ale velice datově a výpočetně náročné pro větší množství dat. Určitě už někdo podobný problém řešil. Prosím o pomoc/popis algoritmu pro toto řazení.
sloupec1+sloupec2 = soubor1, řazený vzestupně podle 2. sloupce sloupec1+sloupec3 = soubor2, řazený vzestupně podle 3. sloupce "user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user4";"3";"4" "user5";"4";"3" "user6";"4";"2" "user7";"4";"1" 1. z prvního souboru vyberu první 3 => user1, user2, user3 2. z druhého souboru vyberu první 3 => user7, user6, user5 3. spojím a zobrazím všechna data "user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user7";"4";"1" "user6";"4";"2" "user5";"4";"3" 4. omezím na první 3 => user1, user2, user3 = CHYBANeboť primárně řadím podle 2. sloupce, tak user3 a user4 jsou nerozhodně (oba = 3), pomocí druhého sloupce ale zjistím, že user4 je před user3, což se ale při tomto algoritmu neprojeví.
n
plus všechny, co mají stejný druhý sloupec jak n
-tý
což je ale velice datově a výpočetně náročné pro větší množství datProto je dobré mít ta data v dobře zpracovatelném formátu a udržovat další informace pro jejich rychlé prohledávání a propojování. A tak vznikly databáze.
1. vyberu n řádků ze zdroje 1 .. - zjistím že m z n řádků nemají jednoznačné pořadí, tak prohledám zdroj 1 znovu a vyberu z n řádky které nemají jednoznačné pořadí + řádky s tímto "indexem", ale za limitem dotazu a postoupím dalšímu zdroji 2. to samé .......
sloupec1+sloupec2 = soubor1, řazený vzestupně podle 2. sloupcetzn. ze vuci sobe nejsou serazeny vubec (teda ano 1. sloupcem) -> to musis imho projit vsechny zaznamy ...
sloupec1+sloupec3 = soubor2, řazený vzestupně podle 3. sloupce
jmeno; cislo; cislo2 ----------------------- "user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user4";"3";"4" "user5";"4";"3" "user6";"4";"2" "user7";"4";"1" order by cislo, cislo2 limit 3 = user1, user2, user4 teď ten algoritmus: - select cislo ... order by cislo limit 3 1 2 3 - select jmeno ... where cislo in (1,2,3) => user1, user2, user3, user4 - pak zjistim ze sporne cislo je u user3 a user4 - select jmeno ... where jmeno in ("user3", "user4") order by cislo2 limit3 => user4, user3 => prerovnam puvodni vyber "user1, user2, user3, user4" na "user1, user2, user4, user3" a omezim na 3 => "user1, user2, user4"Zásadní vada na kráse je ale ta že tento algoritmus je docela složitý.
Většinou se bude jednat o různé typy relačních databází.Tak pri dotaze z kazdej databazy treba prvych n riadkov utriedenych podla vyslednych ziadanych stlpcov. A nasledne utriedit vsetky takto ziskane riadky (pri 3 databazach teda 3*n riadkov). To je algoritmus uvedeny uz v otazke (a takisto posledny sposob uvedeny v 1. komentari). Ale to utriedenie musi byt vsade rovnake ako vysledne ziadane.
Tiskni
Sdílej: