algo de compression - Page 1

qqun en a un de tout fait?
qui compresse un segment memoire et renvoie un pinteur vers le segment compressé?
(et vice versa)

parce que j'ai dl les sources de gzip mais c'est trop cho à adapter.
[edit]Edité par janjan2 le 08-04-2002 à 13:37:25[/edit]

E voila un : c'est même tout fait, spécialement pour TI.
Compression et décompression ON-calc.
C'est ce que j'utilisais dans Krypton. (compression RLE me semble-t-il)

http://hosted.calc.org/~gforce/download.php?what=compresslib

Tu as aussi ziplib.
Au fait, j'ai aussi essaye d' adapter gzip on calc, mais ca fait un programme de pret de 40 Ko.

oué mais ziplib c pas terrible quand tu progg en nostub .. a moins que de ton programme nostub tu appelles un programme kernelleux qui lui compressera avec ziplib mais alors là ...

PpHd> et puis il y a des problemes dans le format:
on ne pourrait meme pas lire directement les fichiers ac gzip pour pc
(dates,checksums diff)
dc j'ai preferer prendre un algo simple et pas lourd.

mon prog est pour l'instant en nostub,mais je vais ptetre le passer en kernel
car j'ai refait ttes les fcts et il prends 22k!(9 en ppg)

neurOne>merci, je vais voir!

neurOne> ça a l'air nickel

T'as aussi l'algo de FL : regarde dans les sources de flib. C'est du Huffman, mais ça compresse aussi bien sinon mieux que ziplib... Si tu arrives à décrypter ses sources, parceque perso, je trouve que c'est un peu le bordel.

les sources de flib sont bordélique... mais probablement pour gagner un max en espace mémoire !

janjan2> c ce que je pensais utiliser pr ma sottise .. c moins chiant que de faire un programme complet kernelleux

je vais voir ce que donne le rle en compression,
sinon, j'implementerai m propre algo LZ77

Il y a quelque chose propose sur le forum de la tict.

ouais je vais voir!

mais ces putains de ezboards

Il y avait un sujet quelque part là-dessus... je crois que c'est Thibaut qui expliquait aussi le principe d'Huffman...

Oui dans la section Algorithmie et optimisation du forum, j'ai fait un topic intitulé "Mon implémentation d'Huffman".

Mais je ne crois pas que j'y explique vraiment l'algo. Pour une explication de l'algorithme adaptatif, il faut chercher dans Actualités je crois, où j'avais expliqué à quelqu'un comment faire.

Et sinon tu avances , JanJan ?

PphD> tu continues ton algo sur le LZ? ? tu fais koi exact, une nvelle lib pour kernelleux ou alors un truc sympa pour tout le monde ?

Une lib pour kernelleux evidemment. Mais utilisable par tout le monde puisqu'elle sera aussi lancable (Avec toute une partie de gestion de fichier).

oki, le "evidement", t'aurais pu t'en passer

Pkoi ?

pr mon amour propre

j'avance mon projet oui,
pour le huffman, je le ferai qd j'aurai fini mon prog...

j'ai un pote qui fait un editeur d'images avec:
-2/4gris pe 7 si j'arrive à le onvaincre et tant pis pour le nostub...
-toutes les fcts de bases
-retaiilage/rognage
-calques
-texte insere(formaté)
-export avec tramage.....
& j'en passe

C'est bien

Comment ça bordélique mes sources :-)

C'est un peu vrai, mais j'étais bien obligé. En plus, plus ça va et plus les versions de TI-GCC font des programmes qui prennent de la place (par exemple, compilé avec la version 0.94b12, Flib2 fait 8185 octets, en rappelant que ça ne doit pas dépasser 8192 = 8Ko...)

Rajoute quelques directives pour minimiser la place requise:
#define NO_EXIT_SUPPORT
#define NO_CALC_DETECT
#define NO_AMS_CHECK

Ces directives devraient être "disablées" par défaut, au même titre que SAVE_SCREEN et OPTIMIZE_ROM_CALL !!!

Non:
- Ne pas mettre le support pour exit par défaut rend incompatibles les programmes qui utilisent exit et/ou atexit.
- Ne pas détecter le modèle permet l'exécution d'un programme sur une calculatrice pour laquelle il n'a pas été prévu et rend beaucoup plus gros les programmes qui utilisent souvent CALCULATOR. (Ce sont les 2 raisons pour lesquelles on a mis la détection de modèle.)
- Ne pas détecter la version d'AMS permet l'exécution d'un programme sur une version d'AMS pour laquelle il n'a pas été prévu, ce qui fait planter la calculatrice. Ça a d'ailleurs été un bogue latent de TIGCC qui n'a pas été corrigé pendant longtemps: beaucoup de programmes nécessitent AMS 1.01 sur TI-92+ (sur TI-89, AMS 1.00 est OK) et plantent sous AMS 1.00 pour TI-92+. Avec la vérification de la version d'AMS, ce problème est enfin résolu: MIN_AMS vaut 101 (TI-89 AMS 1.00/TI-92+ AMS 1.01) par défaut, et le programme vérifie en temps d'exécution si on n'est pas sur TI-92+ AMS 1.00. Si ce n'était qu'à moi de décider, NO_AMS_CHECK serait interdit.

Effectivement, je n'ai pas déclaré NO_CALC_DETECT , NO_AMS_CHECK, ça existe depuis vraiment peu et je n'avais pas fait gaffe. C'est cool !

- Ne pas détecter le modèle permet l'exécution d'un programme sur une calculatrice pour laquelle il n'a pas été prévu et rend beaucoup plus gros les programmes qui utilisent souvent CALCULATOR?

?
Je crois que ca ne change rien du tout par rapport à la macro CALCULATOR qu'un programme compilé pour une seule calculatrice utilise ou non #define NO_CALC_DETECT (puisque que #define _ONE_CALC_ONLY est défini de toute façon).
Je pense comme Thibaut qu'il devrait plutôt il y avoir un #define CALC_DETECT à la place, car beaucoup de monde utilisant les dernières versions de TIGCC ne savent que c'est activé par défaut et ne souhaite par avoir de détection (et généralement si l'executable n'existe pas avec les deux extensions .xxz et .89z dans le zip du programme, il n'est pas compatible on-calc, et tant pis pour celui qui a quand même voulu tester le programme sur la mauvaise calc).

100% d'accord.

Me too. Mais je crois que Monsieur Kevin aime bien imposer ses idées...