Je veux créer une matrice booléenne d'une taille que l'utilisateur va mettre comme entrée.Pro exemple - l'utilisateur peut mettre un grand nombre comme 1000000000000; alors je dois créer une matrice booléenne de la taille 1000000000000.Le problème à faire face est, je ne peux pas stocker l'entrée comme INT, car il ne peut pas contenir un si grand nombre - je suis donc incapable de créer le tableau .Double est un option .Je peut stocker le numéro d'entrée comme double, mais je ne sais pas créer le tableau de la taille du double numéro. C'est l'idée - qui ne fonctionne pas si La cible dépasse la plage int. L'aide est appréciée. P>
5 Réponses :
doit créer une matrice booléenne de la taille 1000000000000. Le problème que je suis confronté est, je ne peux pas stocker l'entrée comme int p> blockQuote>
Votre problème n'est pas ça. Votre problème principal est que vous n'aurez pas assez de mémoire pour allouer une structure de données avec 1 000 000 000 000 éléments (même si vous avez surmonté les limitations de
int code> indexation). P>Vous devrez repenser l'algorithme. P>
Et même si vous avez eu un système qui comptait que beaucoup de mémoire adressable, les matrices Java sont limitées à des éléments (2 ^ 31 - 1). Cette limite est encore plus fondamentale.
@Stephenc: C'est pourquoi je dis "structure de données" plutôt que "array". On pourrait facilement créer une gamme de tableaux ou d'une sorte, mais cela ne ferait que reporter l'inévitable.
2 147 483,647 entrées de taille de mots ne sont qu'à environ 4G de mémoire. Beaucoup de systèmes ont cela. Je ne dis pas que je ne suis pas d'accord avec votre point principal i>, cependant. :-)
@ T.J.Crowder: D'où vient ce numéro? L'OP parle de 1 000 000 000 000 éléments.
En fait, vous avez dit "tableau".
@NPE: Désolé, tout à fait vrai. Ce numéro est integer.max_value code>. Je me concentrais sur un tableau qui dépassait cela, ignorant le numéro d'échantillon. Mais encore une fois, vous avez tout à fait raison d'utiliser la valeur de l'échantillon de l'OP.
Vous ne pouvez pas créer de tableau en Java qui a une taille supérieure au maximum positif Il semble peu probable que vous ayez vraiment besoin de créer un tableau de mais 1 000 000 000 000 éléments? Cela nécessiterait de l'ordre de 1-2 To de RAM. Comme le dit NPE, si vous n'exécutez pas sur un supercalculateur, vous n'allez pas avoir cela. P> int code>, car Les index de tableau sont int code> . (Il en va de même pour les différents Liste code> implémentations A>. Vous peut em> être capable de créer une avec plus d'entrées [A Linkedlist code>, par exemple], mais des choses comme obtiennent code> et et Taille code> Ne démarrez pas tout à fait fonctionner, vous ne pouvez obtenir qu'à des entrées ultérieures via un itérateur code> [en supposant que les choses ne soient pas simplement une pause, ce qui prendrait un moment.) P>
booléen code> avec une pièce de plus de 2 147 483 647 entrées, mais si vous le faites vraiment, vous devrez créer plusieurs tableaux et choisir le bon En prenant le module de votre index (qui devra être un long code>). (Ou utilisez une bibliothèque non JDK, si l'on existe pour le faire.) Cela prendrait quelque chose comme 4 g de RAM. Faisable, mais les chances sont assez élevées qu'une approche différente serait entièrement meilleure. P>
En fait, vous pouvez créer un linkedlist code> plus grand que cela. Mais vous ne voudriez pas utiliser obtenir (int) code> dessus :-)
@Stephenc: Avez-vous déjà essayé de le faire? J'ai une forte soupçon que cela se briserait. Dans tous les cas, l'utilisation de la mémoire serait énorme (tous ces pointeurs à double liaison).
Je n'ai pas essayé. Mais la liste Javadoc pour Taille () code> Permet spécifiquement des listes> max_int
@Stephenc: oooh, donc ça fait.
Merci :) a eu l'idée. En quête d'une différence. approcher.
Que diriez-vous d'utiliser un HASHMAP et d'utiliser des clés longues et des valeurs booléennes. P>
là, vous avez plusieurs avantages.
1. Vous pouvez utiliser des index dans la gamme de longs
2. Vous n'avez pas à vous soucier de la taille maximale de l'index d'élément utilisé. Tant qu'il est long, il fonctionnera
3. Vous n'allouez pas de mémoire pour toute la collection à l'avance. Au lieu de cela, vous n'utiliserez que la mémoire dont vous avez besoin. p>
Tout d'abord: vous avez vraiment besoin d'une bonne raison d'allouer cette mémoire. Comme d'autres l'ont dit, vous voudrez peut-être repenser l'approche. p>
Quelques suggestions: limiter le montant à allouer à un maximum ou le stocker dans un fichier et rechercher les données ou allouer sur une base indispensable (allocation paresseuse). Si les données sont clairsemées (peu de booléens réels, mais à des index très largement répandus), vous êtes préférable avec une carte. Si c'est principalement des zéros, envisagez de stocker uniquement ceux :) P>
Deuxièmement: il est théoriquement possible d'allouer 8 * la taille maximale de la matrice Booléennes si vous emballez les bits. Voir cette discussion pour inspiration: Implémentation d'un bitfield de style C dans Java P >
Vous pouvez créer une abstraction, par exemple une matrice de tableaux (vous pouvez même la modifier).
objet [] [] peut être booléen ou autre. P>
class LargeArray {
private final long size;
private final int sizeI;
private final int sizeJ;
private final Object [][] objects;
public LargeArray() {
sizeI = 3;//Any reasonable value;
sizeJ = Integer.MAX_VALUE;
objects = new Object [sizeI][sizeJ];
size = sizeI * sizeJ;
}
public long size() {
return size;
}
public Object get(long index) {
int i = index / sizeJ;
int j = index % sizeJ;
return objects[i][j];
}
public void set(long index, Object object) {
int i = index / sizeJ;
int j = index % sizeJ;
objects[i][j] = object;
}
}
Vous pouvez faire avec un fichier mappé en mémoire pour fournir le stockage avec un bit par booléen, vous avez besoin de 128 Go de disque. Évident que vous voudriez avoir la même quantité de mémoire, mais cela fonctionnera sans cela (mais à une vitesse réduite)