BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10443)

1829 | #238b | ^ | Idézet | Thu, 07 Feb 2013 21:37:48 +01

78.92.*.*

*.pool.t-online.hu

@kemi:
@TCH:
Meg a help file-ban át kéne írni azt a 256²⁵⁶ értéket, hisz nem annyi az összes lehetséges tábla száma, hanem sokkal kevesebb, egy táblában minden kulcs különbözik.
Több. 256!.

Ööö, mi? Én hülye vagyok matekból, de

256! = 8.578 * 10⁵⁰⁶
256²⁵⁶ = 3.232 * 10⁶¹⁶

tehát a hatványos verzió circa az oktodecilliárdszorosa a faktoriálisnak.
De egyébként így átláthatóbb is: 1*2*3*...*256 < 256*256*256*...*256
Valamit elszámoltál a faktoriálisnál. Mondjuk én se voltam százas, amikor anno beírtam a 256²⁵⁶-ot. :P Javítod akkor faktoriálisra?

@kemi:
Az előrefele kódolónál még nem probléma, de a hátrafele kódolónál ki kell szedni egy tömbbe a lépéseket, vagyis egyszer végig kell iterálni a listán, aztán a tömböt már lehet a végétől az eleje felé feldolgozni.

De ezt kérdezem, hogy miért? Miért tárolod a listában a lépéseket? Nem lenne célszerűbb erre 3 db globális tömböt használni és azokat indexelni közvetlenül a lista előre és hátra iterálása helyett?

char* passwords[]; /* faszomba vannak C-ben a stringtombok */
char modes[]; /* leven c-ben nincs boolean adattipus */
unsigned long long int regenerate[]; /* nem valoszinu, hogy valaki 8 milliard byte utan akarna uj tablat generalni, de lehet. meg ugye itt minusz se kell */

És ennyi. Viszont most kipróbáltam, az újragenerálás mezője túlcsordul 2 milliárd után és mínusz szám lesz belőle. Szerintem legyen 64 bites unsigned. Vagy ha 64 bites nem is, unsigned mindenképpen.

@kemi:
Köszi a tippet. A hátrafele kódoló egy 800k-s fájlon 58 másodpercről 18 másodpercre gyorsult.

Nincs mit. Működött a visszakódolás vele (ergo visszakaptad az eredeti fájlt), vagy csak a sebességet nézted meg?