Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 5
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Ce que vous recherchez peut être compressé et recherché dans un format compressé. Cela réduira la quantité de données et vous permettra de conserver toutes les données dans la RAM. (en théorie)
Ce que vous recherchez peut être compressé et recherché dans un format compressé. Cela réduira la quantité de données et vous permettra de conserver toutes les données dans la RAM. (en théorie)
imo - pour effectuer une recherche dans un fichier compressé, il faut d'abord le décompresser - en théorie, écrire un algorithme pour la recherche de données dans un fichier compressé - c'est impossible.
et le problème est que mt4 (32 bit) ne peut pas contenir beaucoup de mémoire vive.
---
il est logique de stocker un grand volume dans une base de données et d'utiliser des requêtes pour obtenir des données calculées à l'avance
Je ne vois pas de meilleur moyen d'appliquer des solutions toutes faites que d'écrire mon propre mécanisme de traitement des données.
SQL est très bon pour le stockage de grosses données, bien que 20 gigas ne soient pas beaucoup pour SQL...
--
Vous pouvez écrire votre propre mécanisme et lire un fichier donné en plusieurs parties et allouer une quantité maximale de mémoire pour un fragment lu afin d'accélérer la lecture.
et plusieurs fragments de 20 gigas devront être lus pour faire un cycle de calcul
La question est de savoir si cela sera plus rapide que l'option de chargement des données dans la base de données et de traitement via des requêtes SQL - je ne pense pas.
je pense qu'il serait presque plus rapide d'introduire les données dans le SQL
ichmo - si vous souhaitez effectuer une recherche dans un format compressé, vous devez d'abord le décompresser
La solution la plus saine serait bien sûr de changer l'algorithme. Mais comme elle est inconnue, il n'y a rien de concret à suggérer ici. Les pensées générales peuvent ne pas l'être du tout, bien sûr.
Par exemple, puisque plusieurs lectures de fichiers sont nécessaires, ces lectures pourraient se produire dans une "boucle" interne. On pourrait essayer de "transférer" la lecture à la "boucle" extérieure elle-même - les guillemets sont utilisés parce qu'en général un tel "transfert" pourrait signifier la création d'un algorithme complètement nouveau à partir de zéro :).
Un autre indice découle de la mention des lectures séquentielles avec un décalage - un algorithme itératif exigeant une lecture uniquement "décalée" pourrait résoudre ce problème. Mais là encore, cela pourrait signifier créer un algorithme complètement différent à partir de zéro.
Ou peut-être qu'il ne s'agit pas du tout de cela :)
Ce n'est pas nécessaire. Vous pouvez comprimer ce que vous cherchez. Et voilà ! :)
---
Il y a une grande quantité d'informations (environ 20 Go dans un fichier texte).
Les informations sont constituées du même type de séquences, environ un million.
Il est nécessaire de parcourir toutes les séquencesà plusieurs reprises et de faire quelques calculs.
---
à partir de 20 gigas, il faut alimenter les données dans l'algorithme.
il ne cherche pas - il a des données sous forme de fichier - qui sont utilisées dans l'algorithme - alimenté à l'algorithme de calcul
La solution la plus saine serait bien sûr de changer l'algorithme. Mais comme elle est inconnue, il n'y a rien de concret à suggérer ici. Les pensées générales peuvent ne pas l'être du tout, bien sûr.
Par exemple, puisque plusieurs lectures de fichiers sont nécessaires, ces lectures pourraient se produire dans une "boucle" interne. On pourrait essayer de "transférer" la lecture à la "boucle" extérieure elle-même - les guillemets sont utilisés parce qu'en général un tel "transfert" pourrait signifier la création d'un algorithme complètement nouveau à partir de zéro :).
Un autre indice découle de la mention des lectures séquentielles avec un décalage - un algorithme itératif exigeant une lecture uniquement "décalée" pourrait résoudre ce problème. Mais là encore, cela pourrait signifier créer un algorithme complètement différent à partir de zéro.
Ou peut-être qu'il ne s'agit pas du tout de cela :)
---
Il y a une grande quantité d'informations (environ 20 Go dans un fichier texte).
Les informations sont constituées du même type de séquences, environ un million.
Il est nécessaire de parcourir toutes les séquencesà plusieurs reprises et de faire quelques calculs.
---
à partir de 20 gigaoctets, vous devez introduire les données dans l'algorithme.
il ne cherche pas - il a une base de données - qui est utilisé dans l'algorithme
Ce n'est pas nécessaire. Vous pouvez compresser ce que vous cherchez. Et voilà ! :)
Tu me surprends, ma chère)))).
Quel algorithme utiliser pour la compression ? Huffman, Lempel-Ziv ?
Eh bien, il vous donnera une compression 4 à 8 fois supérieure à celle d'un rédacteur de texte. Il faut tenir compte du fait que les algorithmes de compression créent des arbres de recodage différents pour chaque fichier.
En d'autres termes, le fichier source aura un arbre, et la portion de données à trouver aura son propre arbre.
C'est juste intéressant, comment proposez-vous de le rechercher, même si théoriquement ))))
La compression des données n'est rien d'autre que du codage. Si nous faisons une analogie avec le cryptage, nous obtenons deux messages différents (données compressées) cryptés avec des clés différentes (arbres de recodage).
Il n'est même pas possible de les faire correspondre de quelque manière que ce soit, sans parler d'une fonction de recherche ;)))
Tu me surprends, ma chère)))).
Quel algorithme utiliser pour la compression ? Huffman, Lempel-Ziv ?
Eh bien, il vous donnera 4 à 8 fois la compression pour un rédacteur de texte. Il faut tenir compte du fait que les algorithmes de compression créent des arbres de recodage différents pour chaque fichier.
En d'autres termes, le fichier source aura un arbre, et la partie des données à trouver aura un autre arbre.
C'est juste intéressant, comment proposez-vous de le rechercher, même si théoriquement ))))
La compression des données n'est rien d'autre que du codage. Si nous faisons une analogie avec le cryptage, nous obtenons deux messages différents (données compressées) cryptés avec des clés différentes (arbres de recodage).
Ils ne sont même pas comparables en quoi que ce soit, sans parler de la fonction de recherche ;)))
Oups et je suis frappé par beaucoup de choses ici.
Je pense que même un enfant devrait être capable de le comprendre. Si vous comprimez un texte à l'aide d'un algorithme, il sera exactement le même sous une forme comprimée aujourd'hui et demain aussi.
Voulez-vous dire qu'en utilisant le même algorithme de compression et en compressant deux textes différents, vous pouvez obtenir deux séquences de données totalement identiques ?
Juste une conspiration. Bien sûr, ça peut être n'importe quoi, mais je suppose que la recherche. Je devine même quoi.
>>> Je ne sais pas ce que je cherche ...
>>> Vous devez parcourir toutes les séquencesà plusieurs reprises et effectuer certains calculs.
Eh bien - oui - je regarde - mais en regardant à travers 20 gigs...
Fondamentalement, la recherche est basée sur le fait qu'il y a une sorte de recherche et de comparaison.
Je me base sur ce que l'auteur a écritPeut-être que les données ne peuvent pas être réduites - compressées - indexées.
il est logique de mettre les données en SQL
transmettre la logique métier au serveur + données
le conseiller expert n'envoie que des données courtes au serveur pour l'énumération et le calcul.
et recevoir une réponse immédiate.