Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 9

 
Urain:

a Komposter: Andrei, se sei bloccato sul problema della dimensione, significa che hai fatto un errore nella formulazione del problema.

Qui ci sono tre opzioni:

1 pensaci da solo

2 aprire il problema in un forum pubblico

3 risolvere il problema in privato (per tutti quelli che pensi possano risolverlo e di cui ti fidi per mantenere il segreto).

Ti spiego cosa intendo: se salvi le notizie, puoi scrivere perizomi di tutta la notizia, oppure puoi fare una codifica di frasi tipiche (compressione), "saldo del conto" diventa 1, "capitale del conto" diventa 2, ecc. Un'altra variante del problema tipico è il desiderio di riempire i dati già ordinati, per le grandi dimensioni questa è la morte, è più facile aggiungere alla fine e fare l'ordinamento condizionato dagli indici.

Credo di capire cosa intendo quando dico che c'è un errore nella definizione del compito.

Bene, potete fare una tale sostituzione in un buon editor di testo. Suppongo che in tutte le condizioni (quando si parla di notizie), l'informazione ridondante sarà >40%.

Tuttavia, questo non eliminerà la funzionalità di scrittura per l'elaborazione dei dati di testo. Se il problema del volume è risolto, il problema delle prestazioni può insinuarsi.

E in generale l'enunciato del problema non è completamente risolto, è un fatto... non molti dati, ma più opzioni ))

 

Non è di questo che stiamo parlando.

 
YuraZ:

>>> Parla di confrontare due sequenze compresse.

elemento unico poiché non ha sequenza non è compresso, la ricerca fallisce

Controllare - in pratica

esempio - comprimere RAR due file

ELEMENTO - 08:01:

E SEQUENZA

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.



---

Aprire entrambi i file RAR in un editor HEX e cercare di trovare

Troverete che l'elemento 08:01: non è compresso

e non corrisponderà a quello che c'è nel secondo file.


Se comprimi ogni voce - ogni colonna separatamente - non otterrai un guadagno di dimensioni

Al contrario, si aumenterà il volume dei dati a spese dei dati di controllo dell'archiviatore

 
YuraZ:

Controlla - in pratica

esempio - RAR comprime due file

ELEMENTO - 08:01:

E SEQUENZA

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.



---

Aprire entrambi i file RAR in un editor HEX e cercare di trovare

Troverete che l'elemento 08:01: non è compresso

e non corrisponderà in alcun modo.


ma se comprimi ogni voce - ogni colonna separatamente - non guadagnerai in dimensioni

al contrario aumenterete la quantità di dati

Ogni record deve essere compresso individualmente. Naturalmente, ha senso solo quando i dischi sono abbastanza grandi per comprimerli.

 
Integer:

Ogni record deve essere compresso individualmente. Naturalmente, questo ha senso solo se le registrazioni sono abbastanza grandi da essere davvero compresse.

Quindi, siamo arrivati al punto in cui dobbiamo lavorare in blocchi. Di conseguenza, sarà impossibile trovare un'informazione che non corrisponde a un blocco di dimensioni.
 
Contender:
Bene, siamo giunti alla conclusione che dobbiamo lavorare in blocchi. Di conseguenza, sarà impossibile trovare un'informazione che non corrisponde alla dimensione di un blocco.

Perché? Da cosa? Qual è il problema? Non si è arrivati a questo.

 
Integer:

Perché? Da cosa? Qual è il problema? Non si è arrivati a questo.

E sta ancora parlando di palle con Mischka :)
 
Integer:

Ogni record deve essere compresso individualmente. Naturalmente, ha senso solo se le registrazioni sono abbastanza grandi per comprimerle davvero.

Dimitri - se comprimi ogni record - una linea

Aumenterai il volume - controlla!


201 a1.rar -- compresso aaaa1 Non posso dire che sia compresso, ma è compresso.

era 535 aaaa1

è diventato 77 a2.rar un elemento è compresso - o meglio non è compresso ... ma nel file + byte di controllo

era 8 aaaa2

---

il volume dei dati aumenterà da 20 giga alla dimensione di 20 giga elemento di ricerca + velocity byte

Qual è il punto allora?

 
YuraZ:

Dimitri - se comprimi ogni record - stringa

Aumenterai il volume - controlla!


201 a1.rar -- compresso aaaa1 Non posso dire che sia compresso, ma è compresso.

535 aaaa1

77 a2.rar un elemento è compresso - o meglio non è compresso ... ma nel file + byte di controllo

8 aaaa2

---

il volume di dati aumenterà da 20 giga alla dimensione di 20 giga elemento di ricerca + byte di gestione

Qual è il punto allora?

Sì, so che se i dati sono corti, la dimensione aumenta quando si archivia.
 
Integer:
Sì, so che se i dati sono brevi, aumentano di dimensione quando si archivia.

Mm-hmm - ecco perché quello che hai suggerito non va bene

Motivazione: