Starling (GitHub) je desktopové prostředí vytvořeno umělou inteligencí (s dohledem jednoho vývojáře během šesti měsíců).
Dne 30. června 2026 byla završena fyzická realizace projektu Czech National Quantum Communication Infrastructure (CZQCI), tedy České národní kvantové komunikační infrastruktury. Projekt byl realizován od 1. března 2023 a financován z Národního plánu obnovy částkou 121,6 milionu Kč. Cílem podpořeného projektu bylo vybudovat základy národní kvantové komunikační infrastruktury a ověřit možnosti jejího praktického využití. Mezi
… více »Město Šumperk se stalo terčem kybernetického útoku, chod úřadu je omezen. Zjišťuje se, jestli unikla nějaká data. Cílem hackerů byla městská datová síť. První útoky zaznamenali odborníci na informační technologie již v pondělí večer, závady se ale plně projevily až dnes ráno. Město událost nahlásilo Národnímu úřadu pro kybernetickou a informační bezpečnost (NUKIB).
Samba, svobodná implementace síťového protokolu SMB/CIFS, byla vydána ve verzích 4.24.5, 4.23.10 a 4.22.11. Řešeno je 6 zranitelností.
Přední technologické společnosti (Adobe, Cadence, Capital One, Cisco, Cloudera, Cloudflare, Cognition, CrowdStrike, Databricks, Dell Technologies, DoorDash, Elastic, HPE, Hugging Face, IBM, LangChain, Linux Foundation, Microsoft, NAVER, NetApp, Nous Research, NVIDIA, OpenClaw, Palantir, Palo Alto Networks, Red Hat, Reflection AI, Salesforce, SAP, ServiceNow, Siemens, SK Telecom, Snowflake, SpacexAI, Synopsys, Thinking
… více »Krabix.cz je online 3D konfigurátor krabiček pro 3D tisk s exportem do STL. Běží přímo v prohlížeči. Nic se neposílá na server.
Nadace Open Home Foundation spustila veřejnou preview verzi komunitní databáze zařízení pro Home Assistant. Má fungovat jako „Wikipedie pro chytrá zařízení".
Na stránce nového panelu Firefoxu přibudou nové widgety. Například denně aktualizována interaktivní křížovka.
PGSimCity (GitHub) je webová 3D vizualizace vnitřního fungování databázového systému PostgreSQL v podobě města. Vytvořena pomocí umělé inteligence.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.0 a 24.04-1.4. Nová verze 24.04-2.0 již počítá s výřezy pro fotoaparát (notch) a zaoblenými rohy displeje. Webový prohlížeče Morph přešel z Chromia 87 na Chromium 134. Do shellu Lomiri byl přidán editor snímků obrazovky.
To je na delší povídání, v podstatě jde o to že uživatel bude muset ten hash opsat z webu do mobilu, takže dlouhý hash nebude zrovna to pravé. Napadlo mě jedno řešení - vzít třeba jenom prvních x cifer z MD5 hashe, to by snad mělo stačit...
Jinak souhlasím, že je lepší ptát se na původní problém, normálně bych to udělal, teď ale dělám na progamu pro jednu firmu a nemůžu mluvit o tom co přesně dělám.
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: