Na trh v České republice přichází HP EliteBoard G1a. Jde o plnohodnotný AI počítač integrovaný přímo do těla klávesnice, tedy zařízení, které na první pohled vypadá jako minimalistická klávesnice, ale ve skutečnosti nahrazuje klasickou počítačovou jednotku.
V lednu bylo oznámeno, že desktopové prostředí Xfce bude mít vlastní kompozitor pro Wayland s názvem xfwl4. O víkendu byla vydána první preview verze.
Minulý týden byl oficiálně vydán Android 17. Detaily na blogu a stránkách věnovaných vývojářům.
Dnes jde do prodeje zařízení Steam Machine. Steam Machine 512 GB za 1 039 EUR a Steam Machine 2 TB za 1 359 EUR. Do čtvrtka 25. června do 19:00 se lze zapsat na seznamy. Ty budou jednorázově náhodně slosovány, čímž bude určeno pořadí rezervací a čekacích listin.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.51.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek v oznámení o vydání a také na YouTube a PeerTube.
Byla vydána nová verze 2026.3.0 "Carousels & Killer Whales" svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Přehled novinek v poznámkách k vydání a na GitHubu.
Tento týden (24. a 27. června) vyprší platnost Microsoft certifikátu v UEFI vydaných v roce 2011. Nové certifikáty byly vydány v roce 2023. Kdo na počítačích, i virtuálních, používá zabezpečené spouštění (Secure Boot), měl by si ověřit, že má certifikáty aktualizovány, viz např. články na Red Hat nebo Fedora. Pro stávající systémy se nic nemění. Nadále se budou normálně spouštět. Zavaděče podepsané pouze klíčem z 2023 se ale na počítačích s pouze certifikátem 2011 nespustí. Ve Fedoře je zavaděč shim ve verzi 16.1-6 podepsán klíči 2011 i 2023.
Uživatelé mobilních telefonů s Linuxem si nyní mohou nainstalovat aplikaci Mobilní Datovka. Díky tomu je přístup k datovým schránkám dostupný i na zařízeních s mobilními linuxovými distribucemi, jako jsou například Mobian, NixOS Mobile, pmOS atd. Aplikace je dostupná na Flathubu.
Software Freedom Conservancy v novém dokumentu shrnuje doporučení, jak přistupovat ke generativní AI založené na LLM při přispívání do svobodného a open-source softwaru. Mimo jiné vyzývá k obezřetnosti, transparentnosti a revizi generovaného kódu člověkem.
Byla vydána nová verze 5.6.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
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:
