Forráskód nem hordozható?

[gabaman]

Valami felülírja a tmp változót, a bűnös a 83. sorban található tömbök egyike amit túlcímzel. A 125. sorra gyanakszom: a NUM_FORCE kisebb lehet mint a kdt(i,j).

[gabaman]

Valami felülírja a tmp változót, a bűnös a 83. sorban található tömbök egyike amit túlcímzel. A 125. sorra gyanakszom: a NUM_FORCE kisebb lehet mint a kdt(i,j).

[uzsolt]

Húh, ezzel már inkább csak holnap/ma. Késő van már ehhez.

[uzsolt]

Húh, ezzel már inkább csak holnap/ma. Késő van már ehhez.

[gabaman]

Nekem nem, egy progiban hibát keresek és sürgős. De míg fordít, megnéztem a forráskódod és megtaláltam a hibát, bár nem ott, de tényleg van nem inicializált memória egy szerintem rossz index miatt.

    DEBUG_MSG(„k4 kiszámolása…n”);
    // k4 meghatározása
    for (i=0; i<NUM; i++) {
        for (j=0; j<DIM2; j++) {
            tmp_r[j] = planets.r[j]+rkb][color color=red]3[/color][/b[j];
        }
    }
    right_side = g(tmp_r,planets);
    KITOLT(3);
    DEBUG_MSG(MSG_OK);

[gabaman]

Nekem nem, egy progiban hibát keresek és sürgős. De míg fordít, megnéztem a forráskódod és megtaláltam a hibát, bár nem ott, de tényleg van nem inicializált memória egy szerintem rossz index miatt.

    DEBUG_MSG(„k4 kiszámolása…n”);
    // k4 meghatározása
    for (i=0; i<NUM; i++) {
        for (j=0; j<DIM2; j++) {
            tmp_r[j] = planets.r[j]+rkb][color color=red]3[/color][/b[j];
        }
    }
    right_side = g(tmp_r,planets);
    KITOLT(3);
    DEBUG_MSG(MSG_OK);

[uzsolt]

Valóban, oda a piros hármas helyett egy sima fekete kettes kell…  A nan-ok megjelenését okozhatta ez?

(Szoktál egyébként valamikor aludni?)

[uzsolt]

Valóban, oda a piros hármas helyett egy sima fekete kettes kell…  A nan-ok megjelenését okozhatta ez?

(Szoktál egyébként valamikor aludni?)

[gabaman]

uzsolt wrote:

Valóban, oda a piros hármas helyett egy sima fekete kettes kell…  A nan-ok megjelenését okozhatta ez?

Egyértelműen. Simán túlcsordulna egy egész (pl. int) típusú mutató, lebegőpontosnál ez nem történhet meg, ezért a sok NaN. Mivel 10.000 egymásra épülő sor van, ezért ha egy ismeretlen értékű változót minden lépésnél hozzáadsz, akkor alap esetben szinte elkerülhetetlen a túlcsordulás (NaN). De ha az eredeti kód kimeneteit vizsgálod (./csillag &>outN), akkor ha különbséget vizsgálod (diff -u out1 out2) akkor láthatod, hogy mindig más kimenetet kapsz, még ha nem is jön elő a sok NaN (nekem sokszor előjött). Azt láttam, hogy a hármas rossz, de mivel nem ismerem a pontos feladatot nem akartam semmit sem javasolni. A gcc erőteljesen optimalizál, nem mindig ott jön ki a hiba, mint ahol valójában bekövetkezik.

uzsolt wrote:

(Szoktál egyébként valamikor aludni?)

Akkor nem, ha „lendületben” vagyok, aludni bármikor lehet (főleg hétvégén), problémát elhárítani nem mindig. ;D

[gabaman]

uzsolt wrote:

Valóban, oda a piros hármas helyett egy sima fekete kettes kell…  A nan-ok megjelenését okozhatta ez?

Egyértelműen. Simán túlcsordulna egy egész (pl. int) típusú mutató, lebegőpontosnál ez nem történhet meg, ezért a sok NaN. Mivel 10.000 egymásra épülő sor van, ezért ha egy ismeretlen értékű változót minden lépésnél hozzáadsz, akkor alap esetben szinte elkerülhetetlen a túlcsordulás (NaN). De ha az eredeti kód kimeneteit vizsgálod (./csillag &>outN), akkor ha különbséget vizsgálod (diff -u out1 out2) akkor láthatod, hogy mindig más kimenetet kapsz, még ha nem is jön elő a sok NaN (nekem sokszor előjött). Azt láttam, hogy a hármas rossz, de mivel nem ismerem a pontos feladatot nem akartam semmit sem javasolni. A gcc erőteljesen optimalizál, nem mindig ott jön ki a hiba, mint ahol valójában bekövetkezik.

uzsolt wrote:

(Szoktál egyébként valamikor aludni?)

Akkor nem, ha „lendületben” vagyok, aludni bármikor lehet (főleg hétvégén), problémát elhárítani nem mindig. ;D

[Szerző]

Bejegyzés