Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 9

 
Urain:

à Komposter : Andrei, si tu es bloqué sur le problème de dimension, cela signifie que tu as fait une erreur dans la formulation du problème.

Il y a trois options ici :

1 réfléchissez-y vous-même

2 ouvrir le problème dans un forum public

3. Résolvez le problème en privé (pour les personnes qui, selon vous, peuvent le résoudre et en qui vous avez confiance pour garder le secret).

Laissez-moi vous expliquer ce que je veux dire : si vous enregistrez des nouvelles, vous pouvez écrire des tongs de l'ensemble des nouvelles, ou vous pouvez faire un codage des phrases typiques (compression), "solde du compte" se transforme en 1, "équité du compte" en 2, etc. Une autre variante du problème typique est le désir de remplir des données déjà triées, pour les grandes dimensions c'est la mort, il est plus facile d'ajouter à la fin et de faire un tri conditionnel par index.

Je pense que je comprends ce que je veux dire quand je dis qu'il y a une erreur dans la définition de la tâche.

Eh bien, un tel échange peut être effectué dans un bon éditeur de texte. Je suppose que dans toutes les conditions (lorsqu'on parle de nouvelles), l'information redondante sera >40%.

Toutefois, cela ne supprimera pas la fonctionnalité d'écriture pour le traitement des données textuelles. Si le problème de volume est résolu, le problème de performance peut surgir.

Et en général, l'énoncé du problème n'est pas entièrement résolu, c'est un fait... pas beaucoup de données, mais plus d'options ;)

 

Ce n'est pas ce dont nous parlons ici.

 
YuraZ:

>>> On parle de la comparaison de deux séquences compressées.

élément unique puisqu'il n'a pas de séquence n'est pas compressé, la recherche échoue

Contrôle - en pratique

exemple - compresser deux fichiers RAR

ÉLÉMENT - 08:01 :

ET SEQUENCE

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.



---

Ouvrez les deux fichiers RAR dans un éditeur HEX et essayez de trouver

Vous constaterez que l'élément 08:01 : n'est pas compressé.

et ça ne correspondra pas à ce qu'il y a dans le second fichier.


Si vous comprimez chaque entrée - chaque colonne séparément - vous n'obtiendrez pas de gain de taille.

Au contraire, vous augmenterez le volume de données au détriment des données de contrôle de l'archiveur.

 
YuraZ:

Vérifiez-le - en pratique

exemple - RAR compresse deux fichiers

ÉLÉMENT - 08:01 :

ET SEQUENCE

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.



---

Ouvrez les deux fichiers RAR dans un éditeur HEX et essayez de trouver

Vous constaterez que l'élément 08:01 : n'est pas compressé.

et ça ne correspondra pas du tout.


mais si vous compressez chaque entrée - chaque colonne séparément - vous ne gagnerez pas en taille

au contraire vous augmenterez la quantité de données

Chaque enregistrement doit être compressé individuellement. Bien entendu, cela n'a de sens que lorsque les enregistrements sont suffisamment volumineux pour être compressés.

 
Integer:

Chaque enregistrement doit être compressé individuellement. Naturellement, cela n'a de sens que si les enregistrements sont suffisamment volumineux pour être réellement compressés.

Nous en sommes donc arrivés au point où nous devons travailler par blocs. En conséquence, il sera impossible de trouver une information qui ne corresponde pas à la taille d'un bloc.
 
Contender:
Eh bien, nous sommes arrivés à la conclusion que nous devons travailler en bloc. Par conséquent, il sera impossible de trouver une information qui ne correspond pas à la taille d'un bloc.

Pourquoi ça ? De quoi ? Quel est le problème ? On n'en est pas là.

 
Integer:

Pourquoi ça ? De quoi ? Quel est le problème ? On n'en est pas là.

Et il parle toujours des bals avec Mischka :)
 
Integer:

Chaque enregistrement doit être compressé individuellement. Naturellement, cela n'a de sens que si les enregistrements sont suffisamment volumineux pour pouvoir les compresser réellement.

Dimitri - si tu comprimes chaque enregistrement - une ligne

Vous allez augmenter le volume - vérifiez-le !


201 a1.rar -- compressé aaaa1 Je ne peux pas dire que c'est compressé, mais c'est compressé.

c'était 535 aaaa1

est devenu 77 a2.rar un élément est compressé - ou plutôt il n'est pas compressé ... mais dans le fichier + octets de contrôle

était 8 aaaa2

---

le volume de données passera de 20 gigas à la taille de 20 gigas élément de recherche + octets de vélocité

Quel est l'intérêt alors ?

 
YuraZ:

Dimitri - si tu comprimes chaque enregistrement - une ligne

Vous allez augmenter le volume - vérifiez-le !


201 a1.rar -- compressé aaaa1 Je ne peux pas dire que c'est compressé, mais c'est compressé.

535 aaaa1

77 a2.rar un élément est compressé - ou plutôt il n'est pas compressé ... mais dans le fichier + octets de contrôle

8 aaaa2

---

le volume de données passera de 20 gigas à la taille de 20 gigas élément de recherche + octets de gestion

Quel est l'intérêt alors ?

Oui, je sais que si les données sont courtes, l'archivage augmente leur taille.
 
Integer:
Oui, je sais que si les données sont courtes, leur taille augmente lors de l'archivage.

Mm-hmm - c'est pourquoi celui que vous avez suggéré n'est pas bon.

Raison: