V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Možná tuto hádanku už znáte, ale každopádně je to hezká ukázka toho, jak může být matematika v programování někdy matoucí. Narazil jsem na ni kdesi před několika lety.
Následující funkce má fungovat jako knihovní funkce na spočítání průměru ze dvou čísel. Použití je jednoduché - jako parametry očekává dvě čísla a vrací číslo, které je jejich průměrem. Pokud je výsledek neceločíselný, vrátí funkce nejbližší hodnotu směrem k nule.
int SpocitejPrumer(int cislo1, int cislo2) { int vysledek; vysledek = (cislo1 + cislo2) / 2; return vysledek; }
Uvedená funkce nevrací výsledek podle zadání. Poznáte, kde je chyba?
Aktualizace: Jako první na chybu přišel Petr Tomášek, na řešení pak uživatel L. Důvodem je to, že ačkoli matematicky platí, že průměr samozřejmě je (číslo+číslo...)/počet_čísel, v programu může dojít k přetečení rozsahu proměnné a po vydělení už nedostaneme správný výsledek. Přetypování na větší typ není obecné řešení (takový typ nemusí existovat nebo chceme udělat funkci jako šablonu, což by bylo v tomto případě nejvhodnější).
Tato chyba se údajně vyskytovala ve starých verzích Javy. Definici chování při neceločíselném výsledku jsem si ale vymyslel jen já pro zmatení nicméně podle reakcí byl příklad i tak celkem lehký. Všem úspěšně řešícím gratuluji
Tiskni
Sdílej:
To je zbytečné, průměr dvou intů se totiž do intu vždy vleze ;)
hehe, už rozumím, já četl „výsledek“ jako „návratová hodnota funkce“. A ona to měla být proměnná vysledek :-o
Funkce nebude fungovat (hehe), pokud součtem obou intů dojde k přetečení intu... Řešení je triviální: proměnnou vysledek deklarovat jako long a pak jej přetypovat zpět na int.
i1 = 3
a i2 = 5
? Imho 5, což se mi nezdá...vysledek
na float
Prečo by to mali byť floaty? A prečo by to malo súvisieť s premennou vysledek
? Kompilátor (obvykle) funguje tak, že vo výraze "var = expr" najprv vyhodnotí typ expr a až potom sa stará o nejaké pretypovania. Samozrejme, mohol by postupovať aj naopak (najprv analyzuje var a potom to berie do úvahy pri analýze expr), ale toto AFAIK žiadny kompilátor nerobí a mne osobne takýto postup dokonca pripadá dosť čudný.
promena/2
je vždy float
. Už je to jasné...
Aha. Tak toto si takmer žiadny jazyk nestráži, C-like jazyk AFAIK žiadny, v Pythone to tiež nefunguje, ale napríklad v Lispe áno (/ 1 2) = 1/2 (Lisp má podporu racionálnych čísel) a na celočíselné delenie treba používať zvlášť funkciu div. Vlastne ma napadá, že Pascal mal tiež div, takže / v ňom produkoval REAL alebo chybu? Hm, už je to kopa rokov. Niekto by to mohol otestovať
> Řešení je triviální: proměnnou vysledek deklarovat jako long a pak jej přetypovat zpět na int.
Coz nepomuze, protoze casto (napr. na 32bit Linuxu) ma long stejny rozsah jako int.
Řešení je triviální: proměnnou vysledek deklarovat jako long a pak jej přetypovat zpět na intTo je možná triviální, ale není to řešení. Přetypovat na long se musí sčítaná čísla (stačí jedno, druhé se pak přetypuje implicitně).
int vysledek = (int) ( ( (long)cislo1 + (long)cislo2 ) / 2 )
Lenže long je na 32 bitových architektúrach obvykle úplne rovnako veľký ako int, takže toto tiež nie je riešenie (nehovoriac o tom, že aj keby to fungovalo, napríklad pomocou long long, alebo ešte lepšie explicitného int64_t, tak to stále nie je moc dobré riešenie). A zjavne o tom ani ľudia poriadne netušia, čo som zistel pri bugu, na ktorý som včera narazil.
To nevadí. Ako si to s tým C++ myslel? Neviem aký je štandard a pokiaľ viem, tak tieto veci sa ani nijak extra presne nešpecifikujú, ale ja som mal zatiaľ v C++ vždy a všade na 32bitovej architektúre (windows/linux, rôzne kompilátory) long = 32bit, long long = 64bit.
Ono to s tými kompilátormi nie je IMHO až tak zlé. Väčšinou podporujú štandard kompletne a len pridávajú veci naviac. Tak či tak je naivná kompilácia relatívne jednoduchá (C++ je v tomto výnimka) a najviac roboty je v optimalizácii, nie v dodržiavaní špecifikácie. Málokedy niečo zo štandardu chýba, alebo je implementované inak. Hoci si spomínam, že v nejakej starej verzii MSVC zopár vecí skutočne nefungovalo. Možno deklarácia premenných vo for cykle? Je to dávno. A hlavne je to fuk
Aha, tak už som zistil, prečo mi to fungovalo aj pod windowsom. Lebo tam som používal DevCpp a ten používa gcc cez mingw. Záhada vyriešená Ale už to bolo dávno, takže ospravedlň moju pamäť. A v MSVC som long long tuším nikdy nepoužil (zasa je to ale dávno), tam to teda nefunguje?
Na to som sa ale nepýtal. Pýtal som sa na to, či tam nefunguje long long. A teraz neviem, či mám tvoju odpoveď brať ako implicitné ÁNO, alebo si len stratil niť
Nehádame sa, ja sa celkom regulárne pýtam, lebo o tom nič neviem (resp., zabudol som, čo je vo výsledku to isté) Dík.
Môj primitívny parser rozoznáva takéto veci len za pomoci smajlíkov
Nom, tak PNG je bezstrátové, takže to odráža informačnú hodnotu tohoto vlákna
ehm, mě ten kód funguje docela dobře. a co se týče přetýkání intu a nahrazování ho jiným typem, to přeci neni matematická nesrovnalost, nýbrž to je problém kódu...
Taky s programováním začínám.
Tady vůbec nejde o matematiku, jak naznačuje autor blogpostu, ale jen o rozsah integeru. unsigned int pojme 0 až 65535, tzn. když zadáte funkci obě čísla dost veliká na to, aby jejich součet byl větší než 65535, tak funkce přestává fungovat správně. To se týká jen datových typů v C, mohlo by to být napsané v jiném jazyce a rozsah by se mohl posunout nebo prostě jen změnit typ třeba na long double. Stejně pak ale narazíte na hranice...
long long
).
Spôsob počítania medzivýsledku myslíš niečo ako a/2 + b/2 a potom ešte ošetrovať ošetrovať sčítanie nepárnych čísel (kde sa stratia dve polovice)? To je dosť hnusné riešenie. Ale každopádne lepšie ako použivať 64 bitový typ (ktorý ani nemusí existovať), keď stačí 33 bitový Tak či onak to poukazuje na to, že v jazykoch ako C človek strávi 90% času riešením blbostí a tak 10% skutočným programovaním
IMHO má saturácia význam len keď sa jedná už o skutočnú výstupnú veličinu (napríklad v tom audiu ale tiež farba pixelu a podobne). Ak sa jedná len o medzivýsledok, tak je to úplne rovnako na nič ako pretečenie, lebo v priebehu ďalších výpočtov sa tá chyba môže nepredvídateľne rozrásť.
hlavně v audiu, kde většinou přetečení==clipping==zlo
V tomto případě to řeší tzv. limiter.
Tak či onak to poukazuje na to, že v jazykoch ako C človek strávi 90% času riešením blbostí a tak 10% skutočným programovaním
Ale když to má běžet na topinkovači, tak většinou není na výběr. (Sorry, ale nenašel jsem odkaz na příslušný díl seriálu Red Dwarf.)
Protoze to rika standard C99 (sekce 6.5.7). Tohle s endianitou nema nic spolecneho.
Tato chyba se údajně vyskytovala ve starých verzích Javy.http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
Čo sem furt ťaháš tú 64 bitovú šmejďárnu? Kým to nemá aspoň 128 bitov, tak je to nepoužiteľné.
Možno je to hlúpa otázka, ale povieš mi, prečo ho potrebuješ v pamäti celý naraz?
Pretože nenávidím programy, ktoré si alokujú viac pamäte, než potrebujú. Obvykle úplne stačí buffering (lebo na spracovanie dát obvykle stačí pracovať s presne jedným znakom, maximálne pár ďalšími, ak sa jedná o zložitejšie parsovanie). Dobrým (teda skôr zlým) príkladom je vim, v ktorom keď otvoríš film, tak sa môžeš rovno so systémom rozlúčiť, lebo sa ten súbor snaží celý natiahnuť do pamäte. Keby bol bufferovaný, tak sa to dá používať.
Takže ešte raz: prečo to chceš (napriek spomínaným obrovským nevýhodám)?
A čo mmap je jediný spôsob využívania pamäte? Nehovoriac o tom, že ešte pred chvíľou sme sa bavili o Jave. Tak či onak, ten vim proste na veľkých súboroch nefunguje.
A čo mmap je jediný spôsob využívania pamäteNe. Ale pro namapování souboru do paměti vám na POSIX systémech nic jiného nezbývá. Ve Windows máte třeba CreateFileMapping().
vim proste na veľkých súboroch nefungujeJenže to bude proto, že vim neudělá mmap(), ale buffer = malloc(velikost_souboru), read(soubor, buffer, velikost_souboru).
Samozrejme, z nejakého dôvodu som intepretoval mapovanie ako ľubovoľné naťahovanie do pamäte. Ešte raz sa ospravedlňujem.
Wtf? Hovoril som o tom, že programy si alokujú viac než potrebujú, nejde o žiadny mmap. Pokojne si ten vim skús a sleduj jeho spotrebu pamäte. Zjavne opakovane volá malloc, aby si tam celý ten súbor narval naraz
Pretože nenávidím programy, ktoré si alokujú viac pamäte, než potrebujú.Pokud si přečtete pořádně i na co reagujete, tak zjistíte, že na "proč bych neměl chtít namapovat do paměti 3GB soubor"
Aha, sorry, ty si sa na začiatku pýtal práve na mapovanie a ja som to pochopil ako načítanie súboru do pamäte. Tak to sa ospravedlňujem
No, to už teraz bohužiaľ nie je
Ale aj tak by ma zaujímalo, prečo to ten vim rieši tak dementne. Možno kvôli kompatibilite so systémami, ktoré mapovanie neposkytujú (ak také vôbec sú)? Ak by išlo len o to, tak nie je problém si napísať vlastný buffering. Asi to skôr nikoho netrápi, lebo 100MB súbory sa väčšinou needitujú
Tak povídejte, jak v javě namapuju do paměti 3GB soubor?Zřejmě nijak. Moje otázka nebyla nějak ironická, jen jsem se zajímal o to, jak velkej problém je tu indexaci vylepšit, abych mohl buď zdvyhat obočí nad laxností vývojářů SUNu (v případě, že to problém není), nebo s pochopením přikyvovat hlavou (v případě, že to je velký problém)
A pevně dané rozsahy/velikosti primitivních datových typů, když už teda v Javě primitivní typy máme, jsou mnohem lepší než ten céčkový zmatek.To je sice hezké, jenže Javu vyvíjí jedna firma a ta samá firma vyvíjí také jeden runtime VM, tedy JVM.
long
em.
FileChannel
, ByteBuffer
a spol.
Správný způsob indexace je takovým typek, který má stejnou velikost jako ukazatelTo umožňuje který jazyk? Mimochodem mapování souborů do paměti v Javě funguje. I pro ty tvoje oblíbené desetigigové soubory. Indexuje se
long
em. Nevíš a mluvíš – jako obvykle.
1: public static int binarySearch(int[] a, int key) { 2: int low = 0; 3: int high = a.length - 1; 4: 5: while (low <= high) { 6: int mid = (low + high) / 2; 7: int midVal = a[mid]; 8: 9: if (midVal < key) 10: low = mid + 1 11: else if (midVal > key) 12: high = mid - 1; 13: else 14: return mid; // key found 15: } 16: return -(low + 1); // key not found. 17: }Jestli nejse slepej, indexujou intem.
Arrays must be indexed by int values; short, byte, or char values may also be used as index values because they are subjected to unary numeric promotion (§5.6.1) and become int values. An attempt to access an array component with a long index value results in a compile-time error.
long
em. Co to má společného s poli?
Jo, na size_t
jsem si nevzpomněl, díky.
To umožňuje který jazyk?Minimálně C/C++ - size_t, v stl je to *::size_type pro indexování v polích, ptrdiff_t k přičítání k ukazateli.