Dotaz: Ukazatele v C, pole doublu

[Preston Pigglesworth]

Přílohy:

• LVP_solver1.c (5471 bytů)
• lapack2.c (3002 bytů)

Dobry den, nevim si rady z nasledujicim problemem v C. Z knihovny lapack mam funkci pro reseni soustavy linearnich rovnic _dgesv, volam ji presne podle prikladu z http://software.intel.com/sites/products/documentation/hpc/mkl/lapack/mkl_lapack_examples/dgesv_ex.c.htm

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?

---

---

Odpovědi

[Michal Kubeček]

Nezkoumal jsem to nijak podrobně, ale problém by mohl být spíš v těch ostatních parametrech, které nejsou pointery na double. V jedné ukázce totiž u všech předáváte pointery na int, zatímco v druhé pointery na long.

[Dr. Eddy]

no, kdyz uz nejsou srozumitelne nazvy promennych, tak bys aspon ten kod mohl okomentovat. aspon nejak zhruba, abychom vedeli, co se kde deje. A velmi prakticke by bylo napsat, co je ktera promenna (vstupni / vystupni data, ridici promenne atd.).

[Preston Pigglesworth]

dgesv je subroutina na reseni soustavy rovnic A*X=b , pritom pri volani dgesv( &n, &nrhs, a, &lda, ipiv, b, &ldb, &info ) je A predstavovano pomoci pole a. b je na VSTUPU predstavovano pomoci pole b. Na VYSTUPU se reseni X zapisuje do pole b! [Myslim, ze takovy komentar tam nekdeje]. n je pocet radku a sloupcu ctvercove matice A. nrhs=1 - pocet pravych stran ,lda=ldb=n ipiv jsou koeficienty z LU rozkladu, info je navratova hodnota 0= spravne ukonceni

[luky]

Po letmom pohlade na oba programy som si vsimol jeden rozdiel vo funkciach 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.

[Preston Pigglesworth]

Příloha:

• LVP_solver1.c (4750 bytů)

Dekuji za reakce, omlouvam se, ze sem vas zmatl tema ukazkama, zkousel jsem, jestli nemuze byt problem v tom, ze fortranovsky integer odpovida Cckovskemu long int.. V tomto problem neni, je to osetreno pres lapacke.h

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

[Dr. Eddy]

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

To 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.

[Dr. Eddy]

jo, pardon, blbe koukam a pak blbe kecam... jsem uz unaveny...

[Michal Kubeček]

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?

[Preston Pigglesworth]

Příloha:

• LVP_solver1.c (4782 bytů)

Upravil jsem solver1.c tak aby ho bylo mozne spustit bez tech veci okolo, kompiluju to pomoci 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.

Pro začátek např. zkuste alokovat dynamicky pole se stejným obsahem jako mají as a bs a zavolat funkci na ně.

To ted jsem prave vyzkousel pomoci tech statickych poli 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

[Preston Pigglesworth]

Vypada to, ze problem je nekde v tom plneni matic ( ////FILL MATRIX // ) : kdyz jsem presunul

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

[Michal Kubeček]

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.

[Preston Pigglesworth]

Dekuji vsem za pomoc! S tim zaokrouhlovanim mate pravdu, _dgesv pocita spravne. Nakonec jsem nasel chybu ve spatnem umisteni jedne zavorky pri plneni matice S, vzniklo to behem kopirovani z matlabovskeho prototypu. Protoze me ale v minulosti jeden vypocet pocital nesmysly diky ukazatelum, podezrival jsem spatno spravu pameti, za to se omlouvam.. Kazdopadne jeste jednou: diky za pomoc!

[Preston Pigglesworth]

Jeste jsem zkousel pouzit jinou knihovnu (intel MKL), vysledek stale stejne spatny, takze knihovnou to neni.