Portál AbcLinuxu, 12. května 2025 10:19
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:
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:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.