Hozzászólások
-
SzerzőBejegyzés
-
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
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);
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);
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).
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 wrote:vetnél a progira egy-két pillantást? /Cikizni nem kell 😉 /Akkor „no comment” módban:
Code:==26995== Memcheck, a memory error detector.
==26995== Copyright (C) 2002-2007, and GNU GPL’d, by Julian Seward et al.
==26995== Using LibVEX rev 1804, a library for dynamic binary translation.
==26995== Copyright (C) 2004-2007, and GNU GPL’d, by OpenWorks LLP.
==26995== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==26995== Copyright (C) 2000-2007, and GNU GPL’d, by Julian Seward et al.
==26995== For more details, rerun with: -v
==26995==
==26995== My PID = 26995, parent PID = 26994. Prog and args are:
==26995== ./csillag
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x8048872: force (csillag.c:108)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x8048874: force (csillag.c:108)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x8048918: force (csillag.c:118)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x804891A: force (csillag.c:118)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x43B857: __printf_fp (in /lib/libc-2.6.so)
==26995== by 0x4370CC: vfprintf (in /lib/libc-2.6.so)
==26995== by 0x440022: printf (in /lib/libc-2.6.so)
==26995== by 0x80495A8: main (csillag.c:374)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x43B8D7: __printf_fp (in /lib/libc-2.6.so)
==26995== by 0x4370CC: vfprintf (in /lib/libc-2.6.so)
==26995== by 0x440022: printf (in /lib/libc-2.6.so)
==26995== by 0x80495A8: main (csillag.c:374)
==26995==uzsolt wrote:vetnél a progira egy-két pillantást? /Cikizni nem kell 😉 /Akkor „no comment” módban:
Code:==26995== Memcheck, a memory error detector.
==26995== Copyright (C) 2002-2007, and GNU GPL’d, by Julian Seward et al.
==26995== Using LibVEX rev 1804, a library for dynamic binary translation.
==26995== Copyright (C) 2004-2007, and GNU GPL’d, by OpenWorks LLP.
==26995== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==26995== Copyright (C) 2000-2007, and GNU GPL’d, by Julian Seward et al.
==26995== For more details, rerun with: -v
==26995==
==26995== My PID = 26995, parent PID = 26994. Prog and args are:
==26995== ./csillag
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x8048872: force (csillag.c:108)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x8048874: force (csillag.c:108)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x8048918: force (csillag.c:118)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x804891A: force (csillag.c:118)
==26995== by 0x80489DD: g (csillag.c:151)
==26995== by 0x8049045: rk4 (csillag.c:268)
==26995== by 0x8049554: main (csillag.c:370)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x43B857: __printf_fp (in /lib/libc-2.6.so)
==26995== by 0x4370CC: vfprintf (in /lib/libc-2.6.so)
==26995== by 0x440022: printf (in /lib/libc-2.6.so)
==26995== by 0x80495A8: main (csillag.c:374)
==26995==
==26995== Conditional jump or move depends on uninitialised value(s)
==26995== at 0x43B8D7: __printf_fp (in /lib/libc-2.6.so)
==26995== by 0x4370CC: vfprintf (in /lib/libc-2.6.so)
==26995== by 0x440022: printf (in /lib/libc-2.6.so)
==26995== by 0x80495A8: main (csillag.c:374)
==26995==A C forráskód hordozható, semmi gond vele. Viszont a lebegőpontos ábrázolás és aritmetika nem éppen könnyű, bármennyire is annak látszik. Elég ha túl kicsi számmal történik osztás, és ott is a NaN, azt meg már hiába kisebbíted. Egyes processzorok több bittel ábrázolják a számokat a lebegőpontos regiszterekben mint ahogy tárolják, ezt a -ffloat-store opcióval tudod kiküszöbölni. Aztán ott van a véges ábrázolás miatti hiba elhanyagolása, amikor azt feltételezed, hogy két szám egyenlő, és nem azt hogy a két szám különbsége kisebb egy hibamaximumnál (lásd hibaterjedés). Egyes véges decimális számokat nem lehet hiba nélkül véges bináris lebegőpontos formában ábrázolni, más részeredmények meg végesek lehetnek tört formában, de véges lebegőpontos alakban nem, stb…
Egy példa, hogy milyen könnyű látszólag jó, de valójában hibás kódot írni:
Code:#includeint main ()
{
double a, b;
float m;
b = a = 1.0;
m = 1.0 / 3.0;
a -= m * 3.0;
a += 1.0;
if (a == b)
printf(„Egyenlőn”);
else
printf(„Nem egyenlő: %lf, %lfn”, a, b);
}Eredmény (nem meglepő módon):
Code:Nem egyenlő: 1.000000, 1.000000A C forráskód hordozható, semmi gond vele. Viszont a lebegőpontos ábrázolás és aritmetika nem éppen könnyű, bármennyire is annak látszik. Elég ha túl kicsi számmal történik osztás, és ott is a NaN, azt meg már hiába kisebbíted. Egyes processzorok több bittel ábrázolják a számokat a lebegőpontos regiszterekben mint ahogy tárolják, ezt a -ffloat-store opcióval tudod kiküszöbölni. Aztán ott van a véges ábrázolás miatti hiba elhanyagolása, amikor azt feltételezed, hogy két szám egyenlő, és nem azt hogy a két szám különbsége kisebb egy hibamaximumnál (lásd hibaterjedés). Egyes véges decimális számokat nem lehet hiba nélkül véges bináris lebegőpontos formában ábrázolni, más részeredmények meg végesek lehetnek tört formában, de véges lebegőpontos alakban nem, stb…
Egy példa, hogy milyen könnyű látszólag jó, de valójában hibás kódot írni:
Code:#includeint main ()
{
double a, b;
float m;
b = a = 1.0;
m = 1.0 / 3.0;
a -= m * 3.0;
a += 1.0;
if (a == b)
printf(„Egyenlőn”);
else
printf(„Nem egyenlő: %lf, %lfn”, a, b);
}Eredmény (nem meglepő módon):
Code:Nem egyenlő: 1.000000, 1.0000002008-12-12-22:31 Hozzászólás: Digitális aláírás (távszámla) – jellegzetes magyar módra… hogy tudom kezelni? #2177450Nemrég kaptam egy ilyen távszámlás csodát. Kicsit más a leányzó fekvése, sajnos megint hallgattam arra, amit írtál. A fájl _tartalmazza_ a publikus kulcsot, sőt, még időbélyeget és egy nyilatkozatot is a létrehozó személytől (T-Com számla). Ez a része maximálisan rendben van, szó sincs bizalmi elvű digitális aláírásról! Olyan is létezik, de ez nem az. Lényegi oldalról maximálisan megfelelő, ha hitelesített szoftverrel ellenőrzi valaki. De itt van a bukta, nem általános formátumról van szó, hanem egy egyedi Multisignó formátumú XML alapú fájlról. Ezért csak egy szoftverrel lehet megnyitni, mert ez nem MELASZ formátum, ha jól sejtem (a MELASZ formátum sem publikus, fizetni kell érte). Szerencsére a tartalma szintén maximálisan rendben van, szabványos x.509 és base64 kódolású. Csak a formátum nem az, aminek lennie kellene. Írtam egy bash szkriptet, ezzel ki tudod csomagolni a PDF fájlt. Több is lehet beágyazva, de most csak az első a lényeges:
mssign2pdf.sh
Code:#!/bin/bashif test „x$#” != „x2”
then
echo „Használata: $0 .mssign .pdf”;
exit 0;
fixgrep -x „/Pack/Objects/Object[1]/text()” $1 |grep -ve ” |base64 -d > $2
A böngészőhöz való megnyitó szkript (mssign_open.sh):
Code:#!/bin/bashif test „x$#” != „x1”
then
echo „Használata: $0 .mssign”;
exit 0;
fixgrep -x „/Pack/Objects/Object[1]/text()” $1 |grep -ve ” |base64 -d > /tmp/tt.pdf
evince /tmp/tt.pdf &FIGYELMEZTETÉS: a fenti szkriptek nem hitelesítenek semmit sem, csak kicsomagolják az első megtalált beágyazott fájlt.
Szükség van az xgrep programra, sok disztrib alapból támogatja.
http://www.wohlberg.net/public/software/xml/xgrep/ -
SzerzőBejegyzés
legutóbbi hsz