Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Tak jsem ti něco malýho napsal, protože jsem se nudil. Koukni na to. Jinak by to měl bejt jednosměrnej algoritmus (neměla by se dát napsát funkce, která z čísla udělá string).
public static double getHash(String s, int lenght) { Double tmp = new Double(0); for (int i = 0; i < s.length(); ++i) { char c = s.charAt(i); int j = (int) c; tmp += j; } while (tmp < Math.pow(10, lenght - 1) || tmp > Math.pow(10, lenght)) { if (tmp >= Math.pow(10, lenght)) { //System.out.println("vetší než " + Math.pow(10, lenght)); double zbytek = tmp % 2; tmp = ((tmp / 2) + zbytek)- (zbytek / 2); } if (tmp < Math.pow(10, lenght-1)) { //System.out.println("menší než " + Math.pow(10, lenght-1)); tmp = tmp * 2; } } return tmp; }
No tohle je myslim tak trochu odstrasujici priklad, jak podobnou vec neimplementovat
Je to čístě nástřel. Zajímala by mne vaše implementace, když tahle je odstrašující.
Proc je napriklad promenna tmp Double a ne double?
S tim Double máte pravdu, to jsem tam nechal omylem (předtím jsem to tam měl úmyslně).
Proc ten hash neni celociselny?
Hash je celočíselný, ale typu double. Snad napsat return (int)tmp; a přepsat předpis metody dotazující zvládne.
Jenom teď ještě řeším,že pro podobné stringy to hází dost podobné hashe. Ještě pošlu druhou verzi, kde bude tohle ošetřeno.
public static int getHash(String s, int lenght) { int usedLenght = lenght + 1; double tmp = 0; for (int i = 0; i < s.length(); ++i) { char c = s.charAt(i); int j = (int) c; tmp += j; } tmp = Math.abs(Integer.reverse((int)tmp)); while (tmp < Math.pow(10, usedLenght - 1) || tmp > Math.pow(10, usedLenght)) { if (tmp >= Math.pow(10, usedLenght)) { int zbytek = (int)(tmp % 2); tmp = ((tmp / 2) + zbytek) - (zbytek / 2); } if (tmp < Math.pow(10, usedLenght - 1)) { tmp = tmp * 2; } } return (int) (tmp / 10.0); }
Proc vymyslet kolo.
Na 100% souhlasim. Já tu metodu vymýšlim čístě ze zvědavosti.
prehozeni pismen vedlo na ruzny haskod, coz trivialni scitani znaku nesplnuje
Po malé úpravě (viz. příloha) splňuje. Ale trochu se stydím, že mě to nenapdalo hned (a hlavně samo od sebe).
Realizovat celociselne operace v typech s plovouci carkou samozrejme ciste technicky lze (dokud nejsou cisla moc velka), ja to ale povazuji za spatny programatorsky postup, protoze to neni logicke.
Javu se teprve učím. Normálně programuji v jazycích kde se datové typy moc neřeší (hlavně PHP). Upravil jsem metodu, aby celou dobu pracovala s celočíselnými datovým typem. Takhle vám to příjde logicky správné už ?
podivej se treba, jak se pocita hashcode pro tridu String, zdrojaky jsou napriklad pro Sun implementaci k dispozici
Kouknul jsem, implementoval jsem sám ze zvědavosti. Má to však pro zadání (pevná délka a asi by autor chtěl pouze kladná čísla) nějáké mouchy.
Jinak děkuji za poznámky. Rád se něco přiučím.
Jen pro srovnání, jsem změřil NetBeans profilerem rychlosti všech tří hashů (můj originální - getHash, moje implementace hashCode - hashCode a originální hashCode - origHashCode). Výsledky jsem přiložil jako obrázek.
public static long getHash(String s, int lenght) { int usedLenght = lenght + 1; long tmp = 0; for (int i = 0; i < s.length(); ++i) { char c = s.charAt(i); int j = (int) c; tmp += (j*(i+1)); } tmp = Math.abs(Integer.reverse((int)tmp)); while (tmp < Math.pow(10, usedLenght - 1) || tmp > Math.pow(10, usedLenght)) { if (tmp >= Math.pow(10, usedLenght)) { int zbytek = (int)(tmp % 2); tmp = ((tmp / 2) + zbytek) - (zbytek / 2); } if (tmp < Math.pow(10, usedLenght - 1)) { tmp = tmp * 2; } } return (tmp / 10); }
public static int hashCode(String s) { int hash = 0; for(int i =0; i < s.length(); i++) { hash = hash + s.charAt(i) * (int)Math.pow(31, s.length() - (i + 1)); } return hash; }
tmp = ((tmp / 2) + zbytek) - (zbytek / 2);
Máte uplnou pravdu, je to zbytečné. Teď to opravdu postrádá smysl. Kód jsem opravil. V podstatě jsem došel sám ke stejnému výpočtu, jako je originální javovský String.hashCode. Rozdíl je skoro jen v tom, že já používám:
hash += s.charAt(i)*(i+1);
a originál Sun metoda hashCode:
hash += s.charAt(i) * (int)Math.pow(31, lenght - (i + 1));
Long.reverse()
nechápu vůbec. Váš algoritmus se od algoritmu použitého v Javě dost podstatně liší – ovšem je pravda, že ty algoritmy jsou co do míry hashování srovnatelné. Myslím, že pro oba dva nebude problém napsat inverzní funkci (která vrátí některý z možných vstupů), implementace String.hashCode()
ve skutečnosti hashuje jenom podle pravých 7 znaků, další znaky se k hashi prakticky jen přičtou (takže u ASCII textu se osmý a další znak zprava promítnou jen do dolních 7 bitů hashe).
Pokud to celé má sloužit jako bezpečnostní kód, použil bych nějakou prověřenou hashovací funkci (SHA nebo klidně i MD5), výsledek bych rozdělil na skupiny bitů požadované délky a z těch bych XORováním udělal jednu skupinu požadované délky.
Tiskni Sdílej: