Algorithmes, méthodes de résolution, comparaison de leurs performances - page 18
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
Pourquoi une solution parfaite à un problème particulier est-elle perçue comme une moquerie ? Sérieusement, je ne comprends pas...
Quelle était votre tâche ? Rappelez-le vous ici publiquement s'il vous plaît.
Vous avez écrit des bêtises. Essentiellement une variante de l'accès à un tableau par son index. En réalité, les numéros de transaction sont aléatoires, et tout votre exemple s'effondrera lorsque vous devrez résoudre le vrai problème.
Attends d'y arriver, je suis sûr que ce sera demain.
***
Si je devais m'assurer que les données ne disparaissent pas d'un tableau lorsque sa taille est modifiée, ***
Voici une vérification pour les tableaux dynamiques :arr_dynamique unidimensionnel etarr_dynamique_multi bidimensionnel.
Comme vous pouvez le constater, lorsque la taille du tableau augmente, les valeurs précédentes sont conservées:
Vous avez écrit des bêtises. Essentiellement une variante de l'accès à un tableau par son index. En réalité, les nombres de transactions sont aléatoires, et tout votre exemple s'effondrera lorsque vous devrez résoudre un problème réel.
Vous faites référence aux billets, je suppose. Je veux dire des numéros de transaction séquentiels.
Vous pouvez faire un tableau parallèle les uns à côté des autres pour enregistrer les billets.
Ou plusieurs tableaux parallèles pour enregistrer le reste des données de chaque commande.
Voici une vérification pour les tableaux dynamiques :arr_dynamique unidimensionnel etarr_dynamique_multi bidimensionnel.
Comme vous pouvez le constater , lorsque la taille du tableau est augmentée, les valeurs précédentes sont conservées:
le cacher ici purement OOP et tout ce qui est utile
Voici une vérification pour les tableaux dynamiques :arr_dynamique unidimensionnel etarr_dynamique_multi bidimensionnel.
Comme vous pouvez le voir , si vous augmentez la taille du tableau, les valeurs précédentes restent:
Je voudrais discuter de l'impression et du commentaire - pourquoi personne n'y prête attention.
Il existe une propriété magique : la capacité, qui est d'ailleurs absente de CHashMap pour une raison quelconque (ce qui est un oubli flagrant des développeurs). En le spécifiant, nous contournons le re-partitionnement. Vous pouvez le spécifier dans cette tâche, donc je ne vois pas de problème.
Vous pouvez spécifier lacapacité dans CHashMap via le constructeur.
D'ailleurs, la raison pour laquelle ils ont des facteurs d'échelle différents est également très étrange. Il est plus difficile de réorganiser CHashMap que CArrayList, plus simple.
CHashMap utilise CPrimeGenerator pour choisir les nombres premiers.
Mais malheureusement, l'implémentation de CPrimeGenerator ne répond pas aux attentes et ne contient que les valeurs ci-dessous :
Le facteur de croissance moyen est de l'ordre de 1,2 %.
Quelle était votre tâche ? Rappelez-le pour vous-même ici publiquement s'il vous plaît.
Trouver la solution la plus rapide et la plus efficace pour ajouter des mégas à un tableau (liste, dictionnaire...), et récupérer des mégas d'un tableau par numéro d'ordre de transaction, lorsque le nombre de transactions futures est inconnu.
Trouvez la solution la plus rapide et la plus efficace pour ajouter des mégas à un tableau (liste, dictionnaire...), et récupérer des mégas du tableau, avec un nombre inconnu de transactions futures.
Il n'était donc pas question d'un billet.
Cependant, je vous conseille de commencer à compliquer votre code avec toutes sortes de choses comme des fonctions passe-partout.