¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 9

 
Urain:

a Komposter: Andrei, si estás atascado en el problema de la dimensión, significa que has cometido un error al formular el problema.

Aquí hay tres opciones:

1 Piénselo usted mismo

2 abrir el problema en un foro público

3 resolver el problema en privado (para todas las personas que creas que pueden resolverlo y en las que confíes para mantener el secreto).

Te explico lo que quiero decir: si guardas noticias, puedes escribir tangas de toda la noticia, o puedes hacer codificación de frases típicas (compresión), "saldo de cuenta" se convierte en 1, "patrimonio de cuenta" en 2, etc. Otra variante del problema típico es el deseo de rellenar los datos ya ordenados, para dimensiones grandes esto es la muerte, es más fácil añadir al final y hacer una ordenación condicional por índices.

Creo que entiendo lo que quiero decir cuando digo que hay un error en la definición de la tarea.

Pues bien, puedes hacer esa sustitución en un buen editor de texto. Supongo que en todas las condiciones (al hablar de noticias), la información redundante será >40%.

Sin embargo, no se librará de la función de escritura para el procesamiento de datos de texto. Si el problema del volumen se resuelve, el problema del rendimiento puede aparecer.

Y en general el planteamiento del problema no está totalmente resuelto, es un hecho... no hay muchos datos, pero sí más opciones ))

 

No se trata de eso.

 
YuraZ:

>>> Hablando de comparar dos secuencias comprimidas.

elemento único ya que no tiene secuencia no se comprime, la búsqueda falla

Comprobar - en la práctica

ejemplo - comprimir RAR dos archivos

ELEMENTO - 08:01:

Y SECUENCIA

08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10:56:12.
10:56:12.
10:56:12.
10:56:13.
10:56:39.
10:56:39.
10:56:39.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10:57:52.
11:44:50.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.



---

Abra ambos archivos RAR en un editor HEX y trate de encontrar

Verá que el elemento 08:01: no está comprimido

y no coincidirá con lo que hay en el segundo archivo.


Si comprime cada entrada -cada columna por separado- no obtendrá un aumento de tamaño

Por el contrario, aumentará el volumen de datos a expensas de los datos de control del archivador

 
YuraZ:

Compruébelo - en la práctica

ejemplo - RAR comprimir dos archivos

ELEMENTO - 08:01:

Y SECUENCIA

08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10:56:12.
10:56:12.
10:56:12.
10:56:13.
10:56:39.
10:56:39.
10:56:39.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10:57:52.
11:44:50.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.08:01:
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.



---

Abra ambos archivos RAR en un editor HEX y trate de encontrar

Verá que el elemento 08:01: no está comprimido

y no coincidirá de ninguna manera.


pero si comprime cada entrada -cada columna por separado- no ganará en tamaño

por el contrario, aumentará la cantidad de datos

Cada registro tiene que ser comprimido individualmente. Por supuesto, sólo tiene sentido cuando los discos son lo suficientemente grandes como para comprimirlos.

 
Integer:

Cada registro tiene que ser comprimido individualmente. Naturalmente, esto sólo tiene sentido si las grabaciones son lo suficientemente grandes como para ser realmente comprimidas.

Así que hemos llegado al punto de tener que trabajar en bloques. Por lo tanto, será imposible encontrar una información que no corresponda a un bloque en tamaño.
 
Contender:
Bueno, hemos llegado a la conclusión de que debemos trabajar en bloques. Por lo tanto, será imposible encontrar una información que no corresponda al tamaño de un bloque.

¿Por qué? ¿De qué? ¿Cuál es el problema? No llegó a eso.

 
Integer:

¿Por qué? ¿De qué? ¿Cuál es el problema? No llegó a eso.

Y sigue hablando de pelotas con Mischka :)
 
Integer:

Cada registro tiene que ser comprimido individualmente. Naturalmente, sólo tiene sentido si las grabaciones son lo suficientemente grandes como para comprimirlas realmente.

Dimitri - si comprime cada registro - una línea

Aumentarás el volumen - ¡compruébalo!


201 a1.rar -- comprimido aaaa1 No puedo decir que esté comprimido, pero está comprimido.

fue 535 aaaa1

se convirtió en 77 a2.rar un elemento se comprime - o más bien no se comprime ... pero en el archivo + bytes de control

era 8 aaaa2

---

el volumen de datos aumentará de 20 gigas al tamaño de 20 gigas elemento de búsqueda + bytes de velocidad

¿Qué sentido tiene entonces?

 
YuraZ:

Dimitri - si comprime cada registro - una línea

Aumentarás el volumen - ¡compruébalo!


201 a1.rar -- comprimido aaaa1 No puedo decir que esté comprimido, pero está comprimido.

535 aaaa1

77 a2.rar un elemento está comprimido - o más bien no está comprimido ... pero en el archivo + bytes de control

8 aaaa2

---

el volumen de datos pasará de 20 gigas al tamaño de 20 gigas elemento de búsqueda + bytes de gestión

¿Qué sentido tiene entonces?

Sí, sé que si los datos son cortos, el tamaño aumenta al archivar.
 
Integer:
Sí, sé que si los datos son cortos, aumentan de tamaño al archivarlos.

Mm-hmm - es por eso que el que usted sugirió no es bueno

Razón de la queja: