morciw escribió: Fijate que por ejemplo el 4, se almacena como 100. En un codigo octal por ejemplo seria 4. Por lo que ya estarias ahorrando espacio.
Eso es erróneo. Con código binario solo tienes 2 simbolos, y por eso necesitas 3 simbolos para representar el 4. En octal tienes 8 simbolos. La información es la misma y no estas ahorrando ningun espacio. Incluso 4 es otra representación de lo mismo, en el sistema decimal (10 simbolos). Y en todos los casos la información ocupa lo misma, cambiar la base (o sistema de representacion) no cambia nada.
Es como si en lugar de usar el alfabeto tradicional a-z, decido utilizar el alfabeto nianoniano compuesto de a-z-@, donde este ultimo símbolo representa todo el texto del quijote. De esta forma, el quijote podría representarse con solo un símbolo: @. Eso ni es compresión ni es nada
La compresión se basa en eliminar de un mensaje lo que no es información util, es decir, lo que es redundancia o predecibilidad (un ejemplo tonto, si en un texto pone 1 2 3 4 5 6... parece probable que lo siguiente sea un 7, y como tal se puede comprimir la información). Lo primero es muy facil de hacer, lo segundo no tanto, y cuando mayores son los mensajes (los archivos) mas dificil es contrar patrones que repitan, comportamientos que hagan predecible la información, etc. Una vez eliminada esa redundandia, esa predecibilidad, no es posible comprimir mas ya que supondría eliminar información.
Por lo que he mirado, los compresores de lso que hablan hacen precisamente eso, analizar exhaustivamente la información en busca de patrones, relgas, predicciones, utilizando alfabetos adaptativos y muy dependientes del mensaje (archivo) a comprimir, a diferencia de los huffman, LZ, etc usados por RAR, ZIP y similares. En ningun caso sobrepasan e llímite de compresión del que hablo (y no se como se llama, pero existe y es perfectamente definible).
