Autor Tema: ¿Entropía superada?

0 Usuarios y 1 Visitante están viendo este tema.

11 Marzo, 2025, 05:04 pm
Leído 2800 veces

Lotelak

  • $$\Large \color{#6a84c0}\pi$$
  • Mensajes: 4
  • País: ar
  • Karma: +0/-0
Hola a todos, hace mucho tiempo que estoy trabajando en un compresor de datos aleatorios sin perdidas, lo cual hoy por hoy es imposible, pero creo que debo compartir mis avances actuales los cuales son muy importantes, he desarrollado un compresor de datos aleatorios sin perdidas que comprime bits aleatorios y he calculado su entropía y es como promedio en todas las pruebas 0.95, o sea que segun la teoría es imposible de comprimir 32 bits en 31 por ejemplo, he probado miles de bloques aleatorios de 102400 bits de largo con una compresión que supera muy pocas veces los 100000 bits y nunca ha superado los 102400 bits originales, es decir que se comprime y parece ser que se supera la entropia, como dato muy importante debo aclarar que los bits originales pasan antes de la compresion por un simple preproceso, el cual remplaza los 00000 por 01010 y 11111 por 10101 no se quitan ni se agregan bits solo se modifica un poco los bits aleatorios y solo una vez o sea que si hay por ejemplo 000000000 se remplaza y queda 010100000 quedando todavia una cadena 000000, es un preproceso muy simple, en general el compresor que he desarrollado comprime mucho mejor mientras menos bits consecutivos tenga el bloque de bits aleatorios a comprimir. lo cual es una ventaja para el compresor, ya el compresor donde esta toda la logica de la compresion esta terminando y estos son sur resultados, en lo que esyoy trabajando ahora en en optimizar el preproceso el cual debe tener como objetivo reducir lo mas que se pueda los bits consecutivos del mismo valor, logrando esto comprime mucho mejor, ya el compresor esta demostrando en la práctica superar la entropia.

13 Marzo, 2025, 11:17 am
Respuesta #1

Luis Fuentes

  • el_manco
  • Administrador
  • Mensajes: 58,907
  • País: es
  • Karma: +0/-0
Hola

Bienvenido al foro.

Recuerda leer y seguir  las reglas del mismo así como el tutorial del LaTeX para escribir las fórmulas matemáticas correctamente.

Hola a todos, hace mucho tiempo que estoy trabajando en un compresor de datos aleatorios sin perdidas, lo cual hoy por hoy es imposible, pero creo que debo compartir mis avances actuales los cuales son muy importantes, he desarrollado un compresor de datos aleatorios sin perdidas que comprime bits aleatorios y he calculado su entropía y es como promedio en todas las pruebas 0.95, o sea que segun la teoría es imposible de comprimir 32 bits en 31 por ejemplo, he probado miles de bloques aleatorios de 102400 bits de largo con una compresión que supera muy pocas veces los 100000 bits y nunca ha superado los 102400 bits originales, es decir que se comprime y parece ser que se supera la entropia, como dato muy importante debo aclarar que los bits originales pasan antes de la compresion por un simple preproceso, el cual remplaza los 00000 por 01010 y 11111 por 10101 no se quitan ni se agregan bits solo se modifica un poco los bits aleatorios y solo una vez o sea que si hay por ejemplo 000000000 se remplaza y queda 010100000 quedando todavia una cadena 000000, es un preproceso muy simple, en general el compresor que he desarrollado comprime mucho mejor mientras menos bits consecutivos tenga el bloque de bits aleatorios a comprimir. lo cual es una ventaja para el compresor, ya el compresor donde esta toda la logica de la compresion esta terminando y estos son sur resultados, en lo que esyoy trabajando ahora en en optimizar el preproceso el cual debe tener como objetivo reducir lo mas que se pueda los bits consecutivos del mismo valor, logrando esto comprime mucho mejor, ya el compresor esta demostrando en la práctica superar la entropia.

No se si te entiendo, pero que es imposible codificar 32 bits en 31 bits sin pérdida no tiene discusión.

Es imposible distinguir entre \( M=2^32 \) mensajes distintos, sólo con \( C=2^{31} \) codificaciones, porque si [tex ]M>C[/tex] necesariamente dos mensajes distintos deberán de codificarse con el mismo código.

Si estás haciendo comprobaciones con mensajes aleatorios, lo que puede ser es que obtengas aparentes resultados de superación del límite de entropía bien porque trabajas con un número no significativo de experimentos o bien porque estos no son realmente aleatorios.

Saludos.

13 Marzo, 2025, 06:48 pm
Respuesta #2

Tachikomaia

  • $$\Large \color{#5b61b3}\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 1,297
  • País: uy
  • Karma: +0/-0
  • Sexo: Masculino
Yo tampoco entiendo el tema, Winrar es un programa capaz de comprimir ciertos archivos, no sé cómo.

Lo que se me ocurre es que si tienes un dato con muchas repeticiones, puedes indicarlo, como ya se hace en Matemáticas: 10^X para abreviar un número que luego del 1 tiene X 0s.
Si es un número que se repite, podrías poner NúmeroxRepeticiones, por ejemplo 15x3, entendiendo que es 15 repetido 3 veces: 151515.
Si es un texto, tu archivo podría contener en principio un caracter que no esté en el texto, y entonces en vez de x usar ese caracter.
Esto haría que los archivos tarden más en cargarse, sí, además en la mayoría de los casos no es posible hacerlo.

Una posible mejora podría ser que si una cadena larga se repite muchas veces en distintos lados separados, se podría en principio indicar un caracter especial que signifique la cadena, y en vez de repetirla, poner el caracter.

Me parece, sin ánimo de ofender y si no me equivoco, que has dicho muy poco, fue como "Creo que logré algo impresionante, ergo lo informo", pero no dices cómo ni lo demuestras... No le veo mucho sentido.

13 Marzo, 2025, 06:58 pm
Respuesta #3

Lotelak

  • $$\Large \color{#6a84c0}\pi$$
  • Mensajes: 4
  • País: ar
  • Karma: +0/-0
Saludos, y gracias por responder, la verdad es que ed un tema muy polémico y el cual viendolo desde un punto de vista matemático radical pues es logico que es imposible superar la entropia de shannon, pero hay veces en que la logica y las reglas de una era determinada se rompen para pasar a otr era, a mi me cuesta creer lo que hace mi compresor le explico con detalles, le aclaro que esto no es mentira ni es broma esta probado en la práctica en mi entorno de desarrollo, los detalles técnicos de los pasos del compresor son los siguientes:
1- Se genera una cadena de largo 102400 bits aleatorios, y se calcula su Entropía con la fórmula muy conocida de shannon y en este caso es 1.0 entropia máxima, solo se puede representar esta cadena de bits con 102400 bits, esta cadena se modifica en preproceso muy sencillo lo único que se modifica es 00000 por 01010 y 11111 por 10101, una sola pasada, es decir que en el caso de 000000000 seria 010100000, lo cual no elimina la cadena 00000 al 100% lo mismo con la cadena 11111, bien eso es muy simple la modificación del preproceso, se vuelve a calcular la entropia y es igual 1, pues no se elimina ningun bits solo se modifico de una manera muy simple, no creo qur exista un metodo de compresión que comprima esa cadena modificada, bueno seguimos, le compresor comprime esos 102400 bits y crea 2 datas, la primera 40000 y la segunda 60000, en total 100000, logrando comprimir 2400 bits, y ademas esas datas tienen muchas redundancias y se pueden comprimir con un simple compresor estandar por ejemplo el. xz refuce a un 90% estas datas para tener una idea, luego el compresor descomprime usando únicamente esas dos datas nada más, y logra reconstruir al 100% la cadena de 102400 bits, y de una manera simple y sencilla el preproceso hace la inversion de la modificación anterior y se obtiene la cadena de 102400 bits original, el preproceso usa 6200 bits, pero si hacemos los cálculos al final de todo el proceso de compresión se comprimen 12400 bits, el 90% de 100000 es 10000, en conclusion, mi compresor tiene la peculiaridad de comprimir mejor cuando la cadena aleatoria de bits tiene pocos bits consecutivos es algo extraño porque se supone que mintras mas redundancia mejor comprensión y mi compresor es todo lo contrario, el codigo no lo voy a compartir hasta que nl tenga la seguridad y el apoyo necesario de la comunidad científica, esto no es broma y podría causar un caos global, yo se muy bien las consecuencias de esto, y se muy bien que son catástroficas, debe estar rn buenas manos, mi entorno de desarrollo esta offline al 100% y es imposible que alguien pueda haceder a el, esta cifrado y todas las firmas de seguridad estab tomadas, esto es muy serio y me enfrento a un gran dilema, pues se que nadie me va a creer hasta no ver las pruebas, por este motivo hasta que no tenga las garantías de mi seguridad no voy a revelar el codigo, me tomo muchos años y un enorme sacrificio, solo esepero que algún dia tomen en serio esta publicación y este descubrimiento que cambiaria todo no se quede en el olvido, yo estoy dispuesto a colaborar solo si tengo garantías muy solidas para mi seguridad, saludis y muchas gracias por su tiempo

14 Marzo, 2025, 05:23 am
Respuesta #4

Tachikomaia

  • $$\Large \color{#5b61b3}\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 1,297
  • País: uy
  • Karma: +0/-0
  • Sexo: Masculino
Si a los 00000 los cambias por 01010 y tenías varios 01010 ¿luego cómo sabes cuales eran 00000? O no estoy entendiendo. Se supone que la información no debe perderse ni modificarse.

Y si quieres ser tomado en serio (lo cual intento hacer), creo que tienes 2 caminos:
A- Como me dijo GPT (porque le pregunté qué opinaba de tu 1er mensaje): "publicar un documento formal con pruebas matemáticas y experimentales para que la comunidad científica lo analice."
B- O publicarlo aquí pero más detalladamente.

No recuerdo bien pero ya ha habido algún usuario que decía haber descubierto algo o solucionado algo que no se podía y luego de preámbulo innecesario se notó que no era el caso.

14 Marzo, 2025, 01:10 pm
Respuesta #5

Lotelak

  • $$\Large \color{#6a84c0}\pi$$
  • Mensajes: 4
  • País: ar
  • Karma: +0/-0
Saludos entiendo, explicación simple se genera una cadena de 102400 bits aleatorios se remplaza 00000 por 01010 y 11111 por 10101, se comprimen generando 100000 bits esta data se comprime con un compresor estandar mas hasta 90000, pero hay que sumarle los 6200 bits que necesita el preproceso, en total son 96200 bits, luego de descomprime con el compresor estandar generando los 100000 y se descomprime con mi compresor generado los 102400, luego se desmodifica generandl los 102400 bits originales sin perdida de información, en conclusión 102400 bits aleatorios se comprimen a 96200, esto supera la entropia, no voy a compartir codigo hasta que la comunidad científica tome esto en serio y se me den garantías pra mi seguridad, estoy pensando en una manera de dar algun detalle publico pero hay mucho riesgo de ingeniería inversa con públicar únicamente el descompresor y la data comprimida por ejemplo, estoy analizando otra variantes es un gran dilema, muchas gracias por la paciencia y comprensión.
Conclusion final:
Archivo original :102400 bits
Archivo comprimido: 96200 bits
Archivo descomprimido: 102400 bits
Son iguales al 100% bit por bit.

14 Marzo, 2025, 02:03 pm
Respuesta #6

Luis Fuentes

  • el_manco
  • Administrador
  • Mensajes: 58,907
  • País: es
  • Karma: +0/-0
Hola

Saludos entiendo, explicación simple se genera una cadena de 102400 bits aleatorios se remplaza 00000 por 01010 y 11111 por 10101, se comprimen generando 100000 bits esta data se comprime con un compresor estandar mas hasta 90000, pero hay que sumarle los 6200 bits que necesita el preproceso, en total son 96200 bits, luego de descomprime con el compresor estandar generando los 100000 y se descomprime con mi compresor generado los 102400, luego se desmodifica generandl los 102400 bits originales sin perdida de información, en conclusión 102400 bits aleatorios se comprimen a 96200, esto supera la entropia, no voy a compartir codigo hasta que la comunidad científica tome esto en serio y se me den garantías pra mi seguridad, estoy pensando en una manera de dar algun detalle publico pero hay mucho riesgo de ingeniería inversa con públicar únicamente el descompresor y la data comprimida por ejemplo, estoy analizando otra variantes es un gran dilema, muchas gracias por la paciencia y comprensión.
Conclusion final:
Archivo original :102400 bits
Archivo comprimido: 96200 bits
Archivo descomprimido: 102400 bits
Son iguales al 100% bit por bit.

Vaya por delante que me parece una exageración lo que he marcado en rojo; no es tan "peligroso" ni importante todo esto, como para temer por tu seguridad. No se simplemente te refieres a que te roben la idea. Pero una idea en un cajón...no tiene recorrido.

Por otra parte, veamos si te entiendo:

¿Afirmas que con tu sistema CUALQUIER código de 102400 bits puede ser codificado sin pérdida de información en menos de 102400 bits?.

Saludos.

14 Marzo, 2025, 07:50 pm
Respuesta #7

Lotelak

  • $$\Large \color{#6a84c0}\pi$$
  • Mensajes: 4
  • País: ar
  • Karma: +0/-0
Puede que sea una exageración, pero si le preguntas a una IA sobre las consecuencias de un compresor asi, lo primero que te dira es que es imposible, pero si le insistes que si fuera el caso de ser posible, que te diera un ejemplo bien detallado de las consecuencias de esto, te diría cosas que puede ser que nadie haya pensado, yo mismo no tenía ni idea de las consecuencias, y al profundizar sobre estas consecuencias es logico que piense que mi vida esta en peligro o me roben la idea, o peor aun que caiga en manos equivocadas que solo lo usarían para el mal, por ejemplo toda la seguridad actual tiene como base la criptografia, un compresor asi tiene potencial para romper toda la criptografia actual, háblamos de todo el mercado de criptomonedas, encriptado de códigos nucleares, no te podrias imaginar laa graves consecuencias a nivel mundial que traeria esto si no se explota con sabiduría, es un riesgo incluso hablar aqui, pero tenía que hacerlo y puede parecer super exagerado y fantasíoso pero es real, y tiene potencial para ser un mejor, mi compresor comprime mucho mejor en cadenas de bits que tengan menos bits consecutivos, es decir mientras menos bits consecutivos tenga la cadena de bits aleatorios mejor comprime, el explota eso, puede que sea una parte de la teoría de la información que no ha sidl explorada, la mayoría de los compresores explotan la redundancia, la repetición, pero el mio es todo lo contrario si hay menos repeticiónes y menls redundancia mas comprime, mi intención no es discutir con nadie, ni buscar fama ni gloria, simplemente estoy haciendo lo que cualquiera de ustedes hubiera hecho en mi lugar, no es fácil esto y he tenido que meditar mucho para mantenerme claro y estar en paz con esto, actualmente estoy trabajando en alguna manera de demostrar que es real, sin exponer el código, creo que vulnerando algun sistema de encriptacion coml el sha por ejemplo seria una prueba, bueno gracias por los comentarios, no puedo compartir ningún detalle del código, espero entiendan, saludos

14 Marzo, 2025, 10:46 pm
Respuesta #8

Luis Fuentes

  • el_manco
  • Administrador
  • Mensajes: 58,907
  • País: es
  • Karma: +0/-0
Hola

 Sería mucho más productivo para intentar entenderte sin necesidad de que expongas tu método que respondieses a esto:

Citar
¿Afirmas que con tu sistema CUALQUIER código de 102400 bits puede ser codificado sin pérdida de información en menos de 102400 bits?.

Saludos.

15 Marzo, 2025, 12:06 am
Respuesta #9

Richard R Richard

  • Ingeniero Industrial
  • $$\Large \color{#9c57a6}\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 4,054
  • País: ar
  • Karma: +2/-0
  • Sexo: Masculino
  • Dentro de la ciencia todo,fuera de la ciencia nada
creo que vulnerando algun sistema de encriptacion coml el sha por ejemplo seria una prueba,


¿Afirmas que tu software puede mostrar el archivo o documento original o lo que sea se haya encriptado con el algoritmos sha256?
https://es.wikipedia.org/wiki/SHA-2


Eso si sería interesante, no te preocupes por la tercera guerra,  esa se librará igual algún día y no será por tu causa.



Saludos  \(\mathbb {R}^3\)