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

 

Quello che cercate può essere compresso e cercato in formato compresso. Questo ridurrà la quantità di dati e vi permetterà di mantenere tutti i dati nella RAM. (teoricamente)

 
Integer:

Quello che cercate può essere compresso e cercato in formato compresso. Questo ridurrà la quantità di dati e vi permetterà di mantenere tutti i dati nella RAM. (teoricamente)

imo - se volete cercare in forma compressa - dovete prima decomprimere - in teoria, dovete scrivere un algoritmo per la ricerca di dati in forma compressa - impazzite

e il problema è che mt4 (32 bit) non può contenere molto nella RAM

---

è logico mettere un grande volume in un database e usare le query per ottenere dati calcolati pronti

Non riesco a pensare a un modo migliore per applicare soluzioni già pronte che scrivere il mio meccanismo di elaborazione dei dati.

SQL è molto buono per immagazzinare grandi dati anche se 20 giga non è molto per SQL...

--

Potete scrivere il vostro meccanismo e leggere un dato file in parti e allocare la massima quantità di memoria per un frammento di lettura per accelerare

e diversi frammenti da 20 giga dovranno essere letti per fare un ciclo di calcolo

la domanda è se sarà più veloce dell'opzione di caricamento dei dati nel database e dell'elaborazione tramite query SQL - non credo.

Penso che sarebbe quasi più veloce inserire i dati in SQL

 
YuraZ:

ichmo - se vuoi cercare in formato compresso, devi prima decomprimere

Non necessariamente. Puoi comprimere quello che stai cercando. Ecco fatto! :)
 

La soluzione più sana sarebbe ovviamente quella di cambiare l'algoritmo. Ma dato che è sconosciuto, non c'è nulla di concreto da suggerire qui. I pensieri generali possono non esserlo affatto, naturalmente.

Per esempio, poiché sono richieste letture multiple di file, queste letture potrebbero avvenire in un "ciclo" interno. Si potrebbe provare a "trasferire" la lettura al "loop" esterno stesso - le virgolette sono usate perché in generale un tale "trasferimento" potrebbe significare creare un algoritmo completamente nuovo da zero :).

Un altro indizio deriva dalla menzione delle letture sequenziali con uno spostamento - qualche algoritmo iterativo che richiede la sola lettura dello "spostamento" potrebbe risolvere questo problema. Ma di nuovo, questo potrebbe significare creare un algoritmo completamente diverso da zero.

O forse non si tratta affatto di questo :)

 
Integer:
Non è necessario. Potete comprimere ciò che state cercando. Ecco fatto! :)

---

C'è una grande quantità di informazioni (circa 20 GB in un file di testo).

L'informazione consiste nello stesso tipo di sequenze, circa un milione.

È necessario passare attraverso tutte le sequenzeripetutamente e fare alcuni calcoli.

---

da 20 giga, devi inserire i dati nell'algoritmo.

non sta cercando - ha dei dati sotto forma di un file - che è usato nell'algoritmo - alimentato all'algoritmo di calcolo

 
Candid:

La soluzione più sana sarebbe ovviamente quella di cambiare l'algoritmo. Ma dato che è sconosciuto, non c'è nulla di concreto da suggerire qui. I pensieri generali possono non esserlo affatto, naturalmente.

Per esempio, poiché sono richieste letture multiple di file, queste letture potrebbero avvenire in un "ciclo" interno. Si potrebbe provare a "trasferire" la lettura al "loop" esterno stesso - le virgolette sono usate perché in generale un tale "trasferimento" potrebbe significare creare un algoritmo completamente nuovo da zero :).

Un altro indizio deriva dalla menzione delle letture sequenziali con uno spostamento - qualche algoritmo iterativo che richiede la sola lettura dello "spostamento" potrebbe risolvere questo problema. Ma di nuovo, questo potrebbe significare creare un algoritmo completamente diverso da zero.

O forse non si tratta affatto di questo :)

è logico mettere l'algoritmo con una grande quantità di dati nel server SQL
 
YuraZ:

---

C'è una grande quantità di informazioni (circa 20 GB in un file di testo).

L'informazione consiste nello stesso tipo di sequenze, circa un milione.

È necessario passare attraverso tutte le sequenzeripetutamente e fare alcuni calcoli.

---

da 20 gigabyte, bisogna inserire i dati nell'algoritmo.

non sta cercando - ha un database - che è usato nell'algoritmo

Solo una cospirazione. Naturalmente potrebbe essere qualsiasi cosa, ma immagino che stia cercando. Sto persino indovinando cosa.
 
Integer:
Non è necessario. Puoi comprimere quello che stai cercando. Ecco fatto! :)

Mi stupisci, mio caro))))

Quale algoritmo dobbiamo usare per la compressione? Huffman, Lempel-Ziv?

Bene, vi darà 4-8 volte la compressione per uno scrittore di testo. Considerate il fatto che gli algoritmi di compressione creano diversi alberi di ricodifica per ogni file.

In altre parole, il file sorgente avrà un albero, e la porzione di dati da trovare avrà il proprio albero.

È solo interessante, come proponi di cercarlo, anche se teoricamente ))))

La compressione dei dati non è altro che la codifica. Se facciamo un'analogia con la crittografia, otteniamo due messaggi diversi (dati compressi) crittografati con chiavi diverse (alberi di ricodifica).

Non è nemmeno possibile abbinarli in alcun modo, figuriamoci con una funzione di ricerca )))

 
elugovoy:

Mi stupisci, mio caro))))

Quale algoritmo dobbiamo usare per la compressione? Huffman, Lempel-Ziv?

Bene, vi darà 4-8 volte la compressione per uno scrittore di testo. Considerate il fatto che gli algoritmi di compressione creano diversi alberi di ricodifica per ogni file.

In altre parole, il file di origine avrà un albero, e la porzione di dati da trovare avrà un altro albero.

È solo interessante, come proponi di cercarlo, anche se teoricamente ))))

La compressione dei dati non è altro che la codifica. Se facciamo un'analogia con la crittografia, otteniamo due messaggi diversi (dati compressi) crittografati con chiavi diverse (alberi di ricodifica).

Non sono nemmeno paragonabili in alcun modo, figuriamoci una funzione di ricerca )))

Ops e sono colpito da molte cose qui.

Penso che anche un bambino dovrebbe essere in grado di capirlo. Se si comprime un testo con un algoritmo, sarà esattamente lo stesso in forma compressa oggi e anche domani.

Stai dicendo che usando lo stesso algoritmo di compressione e comprimendo due testi diversi puoi ottenere due sequenze di dati completamente identiche?

 
Integer:
Solo una cospirazione. Naturalmente, può essere qualsiasi cosa, ma presumo che la ricerca. Sto persino indovinando cosa.

>>> Non so cosa sto cercando ...

>>> Devi passare attraverso tutte le sequenzeripetutamente e fare alcuni calcoli.

Beh - sì - cercando - ma cercando attraverso 20 concerti...

Fondamentalmente, la ricerca si basa sul fatto che c'è una sorta di ricerca e confronto.

Mi baso su quello che ha scritto l'autore

Forse i dati non possono essere rimpiccioliti - compressi - indicizzati.


è logico mettere i dati in SQL

passare la logica di business al server + dati

l'Expert Advisor invierà solo dati brevi al server per l'enumerazione e il calcolo

e ricevere una risposta pronta.