Sasume
: On peut utiliser printf pour afficher les long long sur TI ?
AMS n'implémente aucune des 3 conventions dans son vcbprintf.Pollux
: Et surtout, The Right Thing est d'utiliser "std::cout<<machin;", pas ces hacks de printf.
Si il fallait 10 s pour un simple cout, ça se saurait GoldenCrystal
: Oué mais il sait pas programmer en C++... (D'ailleurs, la stl n'utilise-t-elle pas les fonctions de la lib c en interne ?)
GoldenCrystal :
Tu racontes vraiment n'importe quoi KevinSi il fallait 10 s pour un simple cout, ça se saurait
Kevin Kofler
:Pollux
: Et surtout, The Right Thing est d'utiliser "std::cout<<machin;", pas ces hacks de printf.
J'appellerais plutôt ça "The Wrong Thing". C'est la manière la plus efficace de faire un "Hello, World!" de plusieurs KO et qui prend 10 secondes.
class ostream {
// données internes
char *data;
int length;
...
public:
...
operator<<(const char *s) {
while (*s)
this<<(*s++);
return this;
}
};
TIGCCLib par Zeljko Juric que c'est vrai... Cela dit il y a d'autres trucs plus délicats qui, si on ne fait pas gaffe, peuvent être très bloatwaresque. En l'occurence, ça n'est pas le cas, et c'est même bien plus efficace que printf("%s",string) -- printf a en plus comme "features" de :
Et de toute façon LZ77+Arith ne devrait pas donner des résultats significativement meilleurs que LZ77+Huff, parce que la différence entre LZ77 et LZ77+Huff est déjà relativement minime (enfin, plus ou moins grande selon la façon dont tu codes ton LZ77).
Excellente compression, nécessite très peu de mémoire pour décompresser (marche même sur TI, je viens de faire l'intégration à un ttstart expérimental). Seul problème: il y n'a pratiquement pas de documentation, la seule référence est la source sans aucun commentaire. Donc j'ai peur que ce soit inutilisable pour toi.
Pourquoi le codage arithmétique donne les même résultats que Huffman? Le peu de site que j'ai vu parler de la compression arithmétique souligné ça puissance de coder dans le meilleur des cas un symbole sur 0.15 bits alors que Huffman fait 1 bit
De plus j'ai les même taux en faisant BWT+Huff et BWT+ARI.
Le codage arithmétique peut aussi faire sur 0.1 bits, 0.01 bits, 0.001 bits et même moins que ça
Oui, enfin le codage arithmétique doit au moins être quelques fractions de pourcent plus efficace, non? Enfin tout dépend de la façon dont est réglé ton codage adaptif, évidemment (et si t'as pas les mêmes réglages en Huff et en ARI, c normal que ARI soit moins efficace que ce qu'il devrait être [ou le contraire] )
OK il donne 1% de mieux que Huffman mais c'est vraiment minable, j'attend à ce qu'il fasse mieux.
Enfin il y a une légère différence, donc y a pas de pb niveau implémentation...
Ah ok j'ai horreur de voir un code illisible et sans commentaires.
Mais c'est vrai que ça passe mieux avec le syntax highlighting et des tabs de 4 caractères (au lieu de 2)
(la limite théorique est apparemment de 12 Go, même si l'implémentation utilise des int ^^ d'ailleurs j'ai l'impression que y a un exploit utilisable à ce niveau-là 
faudrait que je télécharge et installe 7zip pour vérifier, mais je pense bien qu'on peut le faire crasher avec un .lzma invalide )), une consommation de RAM très faible et une vitesse de décompression raisonnable (à peu près 2 fois le temps de décompression de ttpack - mais il faudra que je fasse des benchs plus précis que de l'à-vue-d'œil sous VTI).Kevin Kofler :
"Pas adapté aux TIs"? Il donne juste des fichiers 11% plus petits que les 2 ex-meilleurs (PepZip et ttpack) dans mes tests
(je n'ai pas encore testé XPak, mais je crois qu'il est lui aussi battu facilement)
), XPak n'a pas la prétention d'être meilleur que ttpack...
tout cela avec une routine de décompression assez petite (dans les options qu'il donne, j'ai privilégié la taille par rapport à la vitesse comme d'habitude)
une consommation de RAM très faible et une vitesse de décompression raisonnable (à peu près 2 fois le temps de décompression de ttpack - mais il faudra que je fasse des benchs plus précis que de l'à-vue-d'œil sous VTI).
Euh, il fait qd même des manipulations bit à bit en faisant un packet de décalages et de lectures mémoire à chaque bit, j'ai l'impression, donc bon... Tu peux donner un chiffre en ko/s ? (je trouve ça plus parlant)
)Thibaut B :
Grâce à Kevin plus personne n'utuilisera le format d'exécutables compressés de TIGCC