une petite question en C...

[-rem-]

Bon, salut a tous, je vais poser ma premiere question ici, soyez indulgents...

Je voudrais faire une comparaison de tailles de fichiers, pour une stratégie d'archivage. Je vais devoir archiver des fichiers contenant des nombres uniquement, pas de notions de lettres ou autres choses, par exemple ( double ) :

911

930

etc...

Ce que je veux, c'est générér un fichier ASCII, piece of cake, mais je veux aussi générer un fichier binaire directement. C'est a dire que je veux que 3, codé sur la taille d'un mot processeur ( soit 32 bits dans mon cas au passage ) fait 4 octets, alors que je veux l'ecrire directement en bits, dans le fichier, soit 11 = 2 bits, ce qui fait 16 fois moins. Je ne sais pas non plus comment les séparer, le "\n" et le "\r" en binaire je connais pas..

Je suis conscient que le fichier binaire ne sera pas directement interprétable derriere, j'ecrire de toutes facons une passerelle entre binaire et ascii en C, si elle n'existe pas deja.

Bien entendu, etant un peu connaisseur de linux, et un peu ingenieur, je connais le C et les RTFM, et c'est pas la peine de me repondre qu'il faut faire un "wb" dans mon fopen, ni autre chose dans le genre qui ne fonctionne pas.

Pour ceux que ca intéressent, c'est pour un calcul de code scientifique assez pointu, et cela peut faire gagner 4 a 5 fois plus d'espace et qu'on travaille sur des fichiers pouvant atteindre plusieurs giga. Je veux comparer un ascii compressé avec bzip --best et un binaire pur. Je ne peux pas faire de tables de hashage avec indexation/compression md5 derriere, il faut donc que je passe par la.

Merci de vos réponses...

[lorinc]

comme tu le sais déjà, on ne peut écrire que des octets en C (au plus petit, hein...), donc il va falloir que tu concatènnes tes nombres binaire jusqu'à pouvoir écrire un octet.

une petite idée :

-> tu prends ton nombre et tu fais les division pour avoir les coeff des puissances de 2

-> tu prends 0x00.

-> tu le décales de 1 ( mon_octet << 1 )

-> tu le masque pour mettre la bonne valeur ( mon_octet & 0xFF pour un 1 ou 0xFE pour un 0 )

et ainsi de suite jusqu'à 8, tu écrit et tu recommences.

c'est long et fastidieux, mais bon...

tu peux trouver ça aussi dans les sources de programmes de compression (Huffman, Shannon-Fano par exemple). d'ailleurs, ça m'étonnerait que bzip ne prenne pas en compte se genre de choses, à vérifier...

[theocrite]

En fait ce que tu veux, c'est écrire la représentation binaire des nombres en virant les 0 de gauche ?

Dans ce cas, faut un séparateur de façon à pouvoir déterminer si plusieurs bits qui se suivent appartiennent au même nombre ou représentent deux nombres différents.

Par ailleurs comme le dit lorinc, la plupart des compressions devraient déjà permettre de réduire la taille au maximum (tout du moins ça ne fera pas gagner grand chose).

Et si tu dois manipuler des nombres binaires, méfie toi du double, il est parfois "tricky" de l'utiliser, que ce soit pour le convertir en short/long ou pour les problèmes d'arrondis.

[lorinc]

je viens d'y réfléchir un peu plus profondément (me rappeler de certains trucs qui aurait du me faire sursauter de suite... :tr'anspi: )

d'une part, la plupart (pour ne pas dire toutes) les libs de compression fonctionnent avec des alphabet de taille binaire variable (sionon adieu le gain de compression...), d'autre part, tu aura forcement de plus mauvais résultats.

ça tient à l'entropie de la source. dans le systeme que tu propose, il est clair que le objets codés avec le moins de bits ne sont pas les plus récurents.

le codage optmimal fait en sorte que la source (les données à coder) asuivent une distribution uniforme en fonction de leur poids. en gros, que les objets les plus representés soient codés avec le moins de bits.

ex :

tu as 1 fois le nombre 3 dans ton fichier et 15 fois le nombre 14 et 30 fois 255.

avec ton codage, tu coderais 3 sur deux bits (11), 14 sur 4 (1110) et 255 sur 8 (11111111), donc ton fichier ferait (en faisant abstraction des symbolesde séparation)

1*2+15*4+30*8=

302bits

un codage entropique (comme Huffman (qui est le meilleur dans certain cas)) te diras:

prenons l'alphabet suivant

255 est le plus présent notons le 0

14 ensuite --> 10

et enfin 3 -> 11

chaque symbole est identifiable à la volée et on a au total

1*2 + 15*2 + 30*1 = 62bits

tous les codages fonctionnent (plus ou moins) sur ce principe, et en laissant la source dans son état entropique de départ, tu auras forcement de moins bon résultats qu'en changeant d'espace de representation.

à mon avis tu devrais plutôt regarder du côté des codage propre aux séquences de nombres que de tronquer leur representation

[-rem-]

Oui, moi mon avis est de prendre un fichier ascii standard, et de le compresser avec un bzip2 --best, c'est tout aussi efficace, et plus simple.

Mais j'effectue une prestation d'un mois pour un groupe de chercheurs en physique ( Laboratoire D'ingenierie Mecanique et E... ", des mecaniciens, et ils aimeraient ce genre de chose vu la taille des données a manipuler. Apparement, ils feraient ca avec fortran, mais la ma prestation et mes gouts informatiques poussent vers le C.

C'est marrant, j'ai l'impression que j'aurais posté ce topic dans "le forum maison" et ca revenait au meme, mais ptet que quelqu'un aurait fait un modopliz, ca aurait ete marrant...

EDIT de theo : modopliz

[lorinc]

Ah, les mécaniciens...

c'est comme les chimistes

======>[heureusement qu'ils restent dans blabla... ]

[Duke98]

ah le fortran 77 une grande histoire de non amour

j'ai pas programmé très longtemps en fortran, mais c'etait bien chiant.

par contre pour faire des calculs le fortran c'est bien

http://www.lmcp.jussieu.fr/enseignement/ye...2/fortran1.html

tout en bas de la page.

et je crois que meme actellement tu feras beaucoup moins bien en C (la je m'avance je connais mal le C...)

il y a quand meme une raison pour que les scientifiques utilisent (encore) le fortran...

[-rem-]

il y a quand meme une raison pour que les scientifiques utilisent (encore) le fortran...

Oui :

- ils sont nuls en C

- Ils maitrisent bien fortran

- c'est assez simple, et proche de la logique mathématiques plutot que de la logique informatique.

Mais je pense [tres fortement] que je ferais mieux en C.

[Duke98]

niveau programmation oui,

mais niveau manipulation de nombres réels avec des calculs très compliqués un compilo fortran produit un meilleur code qu'un compilo C.

quand le seul critère est le temps de calcul...

enfin c'était mon petit sur le pourquoi de l'utilisation du fortran en science

[Fafhrdius]

Juste pour dire désolé, je suis pas assez balèze en C

[lorinc]

les résultat seront bien plus performants en C car c'est beaucoup plus proche de la machine...

m'enfin, là où il y a matière à gagner, c'est dans les algo de compression, et je pense que les libs ont été suffisament bien écrites et réécrites pour ne pas pouvoir y aporter grand chose...