Bibliothèque de classes génériques - bogues, description, questions, caractéristiques d'utilisation et suggestions - page 9
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
Je dois ajouter que j'ai utilisé deux fonctions et un tableau dans la solution. Pas de pointeurs ou de connexions.
Votre solution n'est pas bonne. Vous disposez déjà d'un tableau de 100x100x255, soit 2 550 000 cellules, réservé à 100 mots ! Et si vous avez 10 000 000 de mots, vous atteindrez la limite de la mémoire sur les systèmes 32 bits. Et que se passe-t-il s'il y a plus de 100 collisions ? Combien de mots commencent par la lettre S, et combien commencent par la lettre P ? - Il y en a manifestement plus de 100, alors pourquoi ne pas les stocker ?
C'est-à-dire qu'il faut trouver le bon équilibre entre la taille du dictionnaire (RAM) et la complexité de calcul de la fonction de hachage (CPU) pour chaque tâche.
Après avoir écrit tout cela, il m'est apparu qu'il n'y a pas de tâche pratique pour stocker les ticks de la manière discutée dans le fil de discussion. Ils sont triés par heure et stockés dans un tableau simple.
Il en va de même pour les commandes/offres historiques. Et, à en juger par HistorySelect, ils sont stockés dans un tableau par temps. Et je pense qu'il n'y a rien (dans l'implémentation actuelle) qui permette de rechercher des enregistrements par ticket ou par ID.
Et tout cela parce que dans le cas de l'histoire nommée, il n'est pas raisonnable de faire quelque chose comme ça. Un simple tableau est suffisant pour s'entraîner.
Veuillez écrire de manière succincte, sans les spoilers sous forme de chapeaux et d'entités superflues.
C'est un exemple de formation, alors excusez-moi, mais non. Je tiens cependant à souligner que c'est ainsi que le code est écrit dans la version de combat : de la manière la plus concise et efficace possible (comme vous l'aimez). Dans les exemples de formation, le code est écrit pour tous, il est aussi simple et clair que possible, de sorte que même un utilisateur non averti puisse le comprendre.
s.w. Caps, ok, je vais le nettoyer.Toutefois, je tiens à souligner que c'est ainsi que le code est écrit dans la version de combat : de la manière la plus concise et efficace possible (comme vous l'aimez).
En réalité, sur les projets, le code est rédigé selon le "code de conduite".
Et une telle variante, comme dans le casde fxsaber, n'est pas utilisée :
La raison est banale - impossibilité de déboguer de manière pratique.
Votre solution n'est pas bonne. Vous disposez déjà d'un tableau de 100x100x255, soit 2 550 000 cellules, réservé à 100 mots ! Et si vous avez 10 000 000 de mots, vous aurez atteint la limite de la mémoire sur les systèmes 32 bits. Et que se passe-t-il s'il y a plus de 100 collisions ? Combien de mots commencent par la lettre S, et combien commencent par la lettre P ? - Certainement plus de 100, alors pourquoi ne pas les stocker ?
Je suis retourné étudier le code suggéré parReTeg Konow code.
Désolé, mais c'est de la foutaise et une ignorance totale des sujets de hachage en général, sans parler des tables de hachage.
Pourquoi créer ce cercueil sur roues alors que vous pourriez aller sur hubr et au moins vous familiariser avec le sujet des hashs.
Oui, ce n'est pas une tâche triviale que d'implémenter décemment votre propre table de hachage.
Mais dans les codes proposés, il n'est même pas question d'une quelconque compréhension.
Les amis. Je vois que le fil est devenu silencieux.
Je ne veux pas perturber la discussion, donc je me retire volontairement.
Il peut y avoir beaucoup de choses intéressantes dans la bibliothèque.
N'hésitez pas à en discuter.
(Ma solution est de toute façon pire, car elle est 3,2 fois plus lente).
Votre solution n'est pas bonne. Vous disposez déjà d'un tableau de 100x100x255, soit 2 550 000 cellules, réservé à 100 mots ! Et si vous avez 10 000 000 de mots, vous aurez atteint la limite de la mémoire sur les systèmes 32 bits. Et que se passe-t-il s'il y a plus de 100 collisions ? Combien de mots commencent par la lettre S, et combien commencent par la lettre P ? - Il y en a manifestement plus de 100, alors pourquoi ne pas les stocker ?
Lataille du tableau peut être facilement modifiée pour s'adapter à la taille du dictionnaire.
Je ne considère pas les variantes sans fin.
Je suis retourné étudier le code suggéré parRetag Konow code.
Désolé, mais c'est de la foutaise et une incompréhension totale du sujet des hachages en général, sans parler des tables de hachage.
Pourquoi créer ce cercueil sur roues alors que vous pourriez aller sur hubr et au moins vous familiariser avec le sujet des hashs.
Oui, ce n'est pas une tâche triviale que d'implémenter décemment votre propre table de hachage.
Mais dans les codes proposés, il n'est même pas question d'une quelconque compréhension.
Votre solution n'est pas bonne. Vous disposez déjà d'un tableau de 100x100x255, soit 2 550 000 cellules, réservé à 100 mots ! Et si vous avez 10 000 000 de mots, vous aurez atteint la limite de la mémoire sur les systèmes 32 bits. Et que se passe-t-il s'il y a plus de 100 collisions ? Combien de mots commencent par la lettre S, et combien commencent par la lettre P ? - Il y en a manifestement plus de 100, alors pourquoi ne pas les stocker ?
Dans ma version, il est peu probable qu'il y ait plus de 100 collisions. Pouvez-vous penser à plus de 100 mots qui commencent par une lettre et qui ont le même nombre de lettres ?
(sauf pour les variantes "texte 1", "texte 2", "texte 3", "texte 4", "texte 5"...)