Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
Na webu československého síťařského setkání CSNOG 2026 je vyvěšený program, registrace a další informace k akci. CSNOG 2026 se uskuteční 21. a 22. ledna příštího roku a bude se i tentokrát konat ve Zlíně. Přednášky, kterých bude více než 30, budou opět rozdělené do tří bloků - správa sítí, legislativa a regulace a akademické projekty. Počet míst je omezený, proto kdo má zájem, měl by se registrovat co nejdříve.
Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Projekt D7VK dospěl do verze 1.0. Jedná se o fork DXVK implementující překlad volání Direct3D 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil Národní politiku koordinovaného zveřejňování zranitelností (pdf), jejímž cílem je nejen zvyšování bezpečnosti produktů informačních a komunikačních technologií (ICT), ale také ochrana objevitelů zranitelností před negativními právními dopady. Součástí je rovněž vytvoření „koordinátora pro účely CVD“, jímž je podle nového zákona o kybernetické … více »
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Napsal jsem mensi program na jeji odzkouseni, viz priloha lapack2.c -- funguje OK
Kdyz ji ale pouzivam tam kde ji potrebuju, tak jsou vysledky pokazde spatne, krome prvniho prvku. Napada me chyba v ukazatelich, ale podle clanku, co jsem procital tady i jinde, by to melo byt v poradku.Zkousel jsem i zapisovat do souboru jednotlive sekvence vypoctu.. vsechno je v poradku dokud nedojde na _dgesv. Ta sice spravne zapise vysledk do vstupniho pole B, ale s naprosto spatnymi cisly! Zkopiroval jsem obsah souboru B.txt a S.txt do zkouseciho programu a obdrzel jsem spravny vysledek.[overeny GNU/octave]
Muzete mi prosim vysvetlit, jaky je z pohledu te funkce rozdil v tom jestli ji dam odkaz pole, pevne dane velikosti s na pevno naplnenymi cisly, nebo odkaz dynamicky alokovane pole?
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
double. V jedné ukázce totiž u všech předáváte pointery na int, zatímco v druhé pointery na long.
LVP_solveGE() (zo suboru LVP_solver1.c) a funkciou LVP_solveG() (zo suboru lapack2.c). V jednom su lokalne premenne typu long int a v druhom int. Mozno to bude v tom.
Funkce dgesv( &n, &nrhs, a, &lda, ipiv, b, &ldb, &info ) da spravny vysledek pokazde, kdyz jsou pole a a b zavedeny jako double a[121]={...}; double b[11]={...};
Kdyz se ale snazim ty pole zavest dynamicky, tak to pokazde vypocita uplne nesmysly
Zjednodusil jsem ukazku,jak to jen slo.. kdyz nahradim volani LVP_solveGE(n,S,B); za LVP_solveGE(n,as,bs); tak se dostavi spravny vysledek.
P.S.Omlouvam se, ze to vypada tak neprehledne, ale to je proste vypocet..Resp. to je neco, co "proste musi byt" v C, i kdyz je to v C zbytecne, spis az nevhodne
Funkce dgesv( &n, &nrhs, a, &lda, ipiv, b, &ldb, &info ) da spravny vysledek pokazde, kdyz jsou pole a a b zavedeny jako double a[121]={...}; double b[11]={...}; Kdyz se ale snazim ty pole zavest dynamicky, tak to pokazde vypocita uplne nesmyslyTo bude ten problem, protoze je rozdil mezi dynamicky a staticky alokovanym polem. Funkce totiz ocekava staticke pole, ktere by melo byt alokovane jako souvisly blok v pameti, zatimco dynamicky alokovane pole velikosti [n][m] je n poli velikosti m ruzne po pameti. Takze by asi bylo vhnodne ty matice definovat jako jednorozmerne pole a program prepsat.
Dost by pomohlo, kdyby ta ukázka šla přeložit bez spousty souborů, které vy máte, ale my se o jejich obsahu můžeme jen dohadovat. Pro začátek např. zkuste alokovat dynamicky pole se stejným obsahem jako mají as a bs a zavolat funkci na ně. Pokud bude výsledek stejný jako u staticky alokovaného (což je více než pravděpodobné), problém je jinde, než kde se ho snažíte hledat.
Ještě mne napadá: nikde nekontrolujete návratové hodnoty malloc(), nemůže být problém v tom, že selže alokace? Jak velká je ta vaše matice?
gcc LVP_solver1.c lapack_LINUX.a lapacke.a blas_LINUX.a tmglib_LINUX.a libgfortran.so.3.0.0 Dal bych jsem i ty knihovny, ale maji dohromady 30MB.
To ted jsem prave vyzkousel pomoci tech statickych poliPro začátek např. zkuste alokovat dynamicky pole se stejným obsahem jako mají
asabsa zavolat funkci na ně.
as, bs. prekopiroval jsem jejich obsah do B a S (pred tim, nez sem volal _dgesv) pomoci
for (i=0; i<n; i++) { *(B + i) =bs[i]; }
for (i=0; i<n*n; i++) { *(S + i) =as[i]; }
Vysledek je kupodivu v poradku!
O to vic tomu ted ale nerozumim, protoze ty cisla v tech statickych polich as, bs jsem ziskal primo z tohoto programu tim, ze jsem to pole ihned po naplneni for cykly zapsal to textoveho souboru
for (i=0; i<n; i++) { *(B + i) =bs[i]; } for (i=0; i<n*n; i++) { *(S + i) =as[i]; } Pred vsechno to naplnovani, tak to zase vyhodilo spatny vysledek..
jeste jsem za kazde to plneni matice napsal jeji vypis pomoci for (i=0; i<n; i++) {printf("%20.20f \n",*(B+i) ); } ... vsechno je v poradku,vstupy do _dgesv jsou stejne, jako v pripade pouziti statickeho pole
Hodnoty ve statických polích nejsou úplně stejné jako ty počítané, vypadá to, že jsou zaokrouhlené na šest desetinných míst. A pokud místo zkopírování statického pole dám
for (i=0; i<n; i++) {
B[i] = 1E-6 * lround(1E6 * B[i]);
}
for (i=0; i<n; i++) {
for (j=0; j<n; j++) {
S[i+j*n] = 1E-6 * lround(1E6 * S[i+j*n]);
}
}
dostanu stejné výsledky jako se statickým polem. Takže můj tip je, že celý problém je v (ne)stabilitě té soustavy, tj. že i malá změna v koeficientech nebo pravé straně může způsobit (relativně) velkou změnu řešení. Ale nechce se mi počítat vlastní čísla, abych si to ověřil.
Tiskni
Sdílej:
