Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 10
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ci sto provando di nuovo.
Abbiamo tre file.
1. L. Tolstoj. Guerra e Pace, Volume 1.
2. L. Tolstoj. Guerra e Pace, Volume 2.
3. F. Dostoevskij. Delitto e castigo.
Confezioniamo ognuno di loro.
Abbiamo tre file impacchettati senza nome (non chiedetemi come faccio a immaginare un file senza nome). Abbiamo anche un file non confezionato, che sia "Delitto e castigo".
Come trovare questo file nei tre file compressi nel modo più economico?
Opzione 1: devo comprimere tutti e tre i file e trovare il file che sto cercando.
Opzione 2. Comprimi il file che stai cercando e trova lo stesso identico file tra i tre compressi.
Mm-hmm - quindi quello che proponi non va bene
Sì, so che se i dati sono corti, la dimensione aumenta quando si archivia.
Se volete continuare in questa direzione, potete anche usare l'hashing o il checksum per cercare, non dovete usare la codifica di compressione. Crea un indice hash e cerca per dicotomia.
Ma questo è se la porzione di fonte è disponibile in dimensioni reali.
Per esempio, in questi casi uso DBMS senza trucchi. Spendo meno tempo nello sviluppo e il prodotto è stabile.
State dicendo tutte le cose giuste, e questo sottolinea ancora una volta che l'opzione di compressione dovrebbe essere giustificata per il compito.
Dovete fare affidamento sulla dichiarazione del problema.
Se volete continuare in questa direzione, potete anche usare l'hashing o il checksum per cercare, non dovete usare la codifica di compressione. Crea un indice hash e cerca per dicotomia.
Ma questo è se la porzione di fonte è disponibile in dimensioni reali.
Per esempio, in questi casi uso DBMS senza trucchi. Spendo meno tempo nello sviluppo e il prodotto è stabile.
Quindi non era questo il mio suggerimento. In ogni caso l'idea è interessante.
>>> Parlando di confrontare due sequenze compresse.
Dima! Ricordami - è di questo che stavamo parlando.
>>> questo è esattamente quello che abbiamo discusso in pratica.
>>> Sì, lo so, se i dati sono corti, aumenta la dimensione quando si archivia.
>> ecco perché non va bene
--
Ecco perché i database industriali non hanno questa ideologia.
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Intero:
Buona idea.si può provare
>>> Per esempio, in questi casi uso DBMS senza trucchi. Ci vuole meno tempo per sviluppare e il prodotto è stabile.
ma è meglio usare un database SQL industriale già pronto
>>> Parlando di confrontare due sequenze compresse.
Dima! Ricordami - è di questo che stavamo parlando.
>>> questo è esattamente quello che abbiamo discusso in pratica.
>>> Sì, lo so, se i dati sono corti, aumenta la dimensione durante l'archiviazione.
>> ecco perché non va bene
--
Ecco perché neanche le basi industriali hanno questa ideologia
...
puoi provare questo
>> Io, per esempio, in questi casi, uso un DBMS senza trucchi. Spendo meno tempo nello sviluppo e il prodotto è stabile.
ma è meglio usare database SQL industriali già pronti
Yurichik, intendo dire senza colpi di scena con l'elaborazione dei file, la compressione, ecc. Intendevo solo lavorare con l'SQL e la logica del robot/indicatore. Ho lavorato con molti database, l'unico problema era quello di far funzionare insieme MQL e SQL)). Ho creato una bella soluzione senza array e strutture.
In generale, preferisco non reinventare la ruota e risolvere i problemi con i mezzi migliori.
Penso che sia per un'altra ragione. Poiché il problema di caricare dati di grandi dimensioni nel sistema operativo è risolto in modo diverso lì, non vengono caricati, ma letti direttamente dal disco. (credo)
il server lo fa... in modo molto efficiente.