Salut � tous!
J'essaie de faire un programme pour trouver des nombres premiers, mais je suis confront� � un probl�me : comment faire pour stocker des nombres entier sup�rieurs � 2^64 - 1 (unsigned long long int)?
Merci.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter
Stocker un entier tr�s grand
Salut � tous!
J'essaie de faire un programme pour trouver des nombres premiers, mais je suis confront� � un probl�me : comment faire pour stocker des nombres entier sup�rieurs � 2^64 - 1 (unsigned long long int)?
Merci.
Hio,
Il y a des librairies pour �a.
Une des plus connues est GMP.
Salut,
Sauf erreur, il n'y a pas vraiment moyen
A moins que je ne dise une erreur, il n'est en effet pas pr�vu dans l'imm�diat de rajouter un type plus grand que unsigned long long ...
Tu peux toujours envisager de travailler avec un bitset, qui devrait te permettre de g�rer de nombres de n'importe quelle ordre de grandeur, mais, tu restera fortement emb�t� pour arriver � le repr�senter en base d�cimale, et ce, sans m�me parler des soucis pour arriver � g�rer les divisions
Ceci dit, j'ai r�cemment (enfin, cela date d'il y a un mois ou deux) fait l'exp�rience avec un simple entier chez moi...
Mon "vieux clou" (un "antique" Athlon 1700 XP) a moulin� pendant plus de 7 heures pour me trouver les nombres premiers entre 0 et UINT_MAX... puis j'ai abandonn�
Il parrait aussi que, avec 64 bits, on pourrait donner un num�ro unique � chaque grain de sable pr�sent sur terre... d�s lors, estimes-tu r�ellement utile de vouloir aller plus loin
A m�diter: La solution la plus simple est toujours la moins compliqu�e
Tu fais erreur, beaucoup de langages, comme le Python ou le Java, proposent des entiers et des flottants cod�s sur un nombre ind�fini de bytes. Ce serait certainement tr�s simple � impl�menter en C++, mais je ne connais pas de biblio qui le fait.Envoy� par koala01
Sauf erreur, il n'y a pas vraiment moyen
De toute fa�on, c'est compl�tement inutile de trouver les nombres premiers, alors un truc inutile de plus...
En fait je fais �a avec un pote, parce qu'on s'amuse � trouver les nombres entiers les plus grands possibles (hilarant...
Comme le l'ai indiqu�, le fait est qu'il n'y ait aucun type pr�vu pour supporter plus de 64 bits dans la norme...
Comme je l'ai indiqu� aussi, il ne reste, � ma connaissance, que le bitset qui devrait permettre de faire coexister deux long long plus ou moins efficacement
Le fait que certains langages puissent le permettre ne signifie nullement que tous les langages doivent le faire
A la r�flexion, il est vrai que tu devrais pouvoir arriver � tester des valeurs allant jusqu'� 128 bits, �tant donn� que seules les valeurs inf�rieures � la racine carr�e du nombre sont � tester...De toute fa�on, c'est compl�tement inutile de trouver les nombres premiers, alors un truc inutile de plus...
En fait je fais �a avec un pote, parce qu'on s'amuse � trouver les nombres entiers les plus grands possibles (hilarant...
Mais tu en resterais de toutes fa�ons confront� au probl�me de la repr�sentation en d�cimale du nombre trouv�... Seul l'hexad�cimal aurait une chance de repr�senter quelque chose de plus ou moins compr�hensible (et t'obligeant encore � te "palucher" la conversion hexa->decimal
Ce n'est pas forc�ment int�gr� au langage, en Java c'est une simple classe. Alors en C++, avec la r�d�finition d'op�rateurs et les transtypages implicites, ce serait on ne peut plus simple � utiliser. Et oui, je sais tr�s bien que ce n'est pas int�gr� � la biblio standardLe fait que certains langages puissent le permettre ne signifie nullement que tous les langages doivent le faire
Dio,
Si �a ne sert � rien, pourquoi tant de personnes se fatiguent � chercher de nouveaux algorithmes pour �a ?De toute fa�on, c'est compl�tement inutile de trouver les nombres premiers, alors un truc inutile de plus...
En fait je fais �a avec un pote, parce qu'on s'amuse � trouver les nombres entiers les plus grands possibles (hilarant...
Je peux comprendre que �a ne te serve pas, mais ne fait pas de ton cas une g�n�ralit�.
Pour aller plus loin, il faut une librairie de calcul multi-pr�cision, soit existante, comme GMP, d�j� cit�e, soit faite maison (un assez gros travail si on veut qu'elle soit performante).
Tu as tout faux en l'occurrence.Comme le l'ai indiqu�, le fait est qu'il n'y ait aucun type pr�vu pour supporter plus de 64 bits dans la norme...
Comme je l'ai indiqu� aussi, il ne reste, � ma connaissance, que le bitset qui devrait permettre de faire coexister deux long long plus ou moins efficacement
Le fait que certains langages puissent le permettre ne signifie nullement que tous les langages doivent le faire
A la r�flexion, il est vrai que tu devrais pouvoir arriver � tester des valeurs allant jusqu'� 128 bits, �tant donn� que seules les valeurs inf�rieures � la racine carr�e du nombre sont � tester...
Mais tu en resterais de toutes fa�ons confront� au probl�me de la repr�sentation en d�cimale du nombre trouv�... Seul l'hexad�cimal aurait une chance de repr�senter quelque chose de plus ou moins compr�hensible (et t'obligeant encore � te "palucher" la conversion hexa->decimal
Le bitset est sans le moindre doute une des pires solutions pour r�soudre ce genre de probl�me.
J'ai t�l�charg� GMP mais j'ai pas du tout compris comment l'installer
J'ai peu etre tord en parlant de bitset, je l'accorde, mais dans ce cas, quelle solution proposerais tu toi<snip>
Tu as tout faux en l'occurrence.
Le bitset est sans le moindre doute une des pires solutions pour r�soudre ce genre de probl�me.
Par contre, je ne vois pas o�, dans la citation que tu fais, j'ai tord en rappelant que l'on peut se contenter de tester les nombres plus petits que la racine carr�e d'un nombre � tester, ni dans le fait que tu risque de toutes fa�ons d'avoir des probl�me de repr�sentation en base dix...
En deux mots, je te serait gr� d'�tre attentif � tes citations
Si tu travailles avec Gcc (mingw ou similaire), tu peux installer MSYS et te baser sur les explications que je fournis dans mon Guide de la Compilation de Gcc sous windows (en particulier compiler GMPlib)...J'ai t�l�charg� GMP mais j'ai pas du tout compris comment l'installer
Si tu travailles avec VC++, d�sol�, je ne suis pas assez habitu� avec ce compilo pour pouvoir t'aider
Kio,
A part le coup de la racine carr�e, que j'ai oubli� de couper, tu as tout faux, je me r�p�te.J'ai peu etre tord en parlant de bitset, je l'accorde, mais dans ce cas, quelle solution proposerais tu toi
Par contre, je ne vois pas o�, dans la citation que tu fais, j'ai tord en rappelant que l'on peut se contenter de tester les nombres plus petits que la racine carr�e d'un nombre � tester, ni dans le fait que tu risque de toutes fa�ons d'avoir des probl�me de repr�sentation en base dix...
En deux mots, je te serait gr� d'�tre attentif � tes citations
La repr�sentation d�cimale de grands nombres n'est pas plus difficile que celle des nombres plus habituels, c'est exactement le m�me algorithme qu'on utilise.
Et il ne s'agit surtout pas de faire une repr�sentation en base 10 dans les donn�es stock�es, rien de tel pour faire un programme qui rame.
La solution est de faire un tableau d'un type unsigned (le plus grand support� par le mat�riel, pas seulement par le compilateur), et de traiter les morceaux successivement, exactement comme on traite � la main notre repr�sentation d�cimale.
Il faut bien entendu ajouter un champ donnant la taille effectivement utilis�e, et un autre donnant le signe.
A partir de l�, tu fais ce que tu veux.
C'est pas tr�s difficile de stocker un entier de grandeur al�atoire, il suffit de faire une liste chain�e ou chaque noeud contient un short/int/long d�pendant du nombre de digits qu'on veut par noeud, ensuite il te reste un sale boulot au niveau des algo d'addition/soustraction/multiplication/division/mod/etc. Mais sinon �a reste dans le monde du tr�s possible!
Gio,
Une liste cha�n�e est une solution, mais un tableau est bien pr�f�rable dans ce cas, pour une question de temps d'acc�s aux donn�es.
Dans les calculs multi-pr�cisions, le temps de calcul augmente vite si on utilise des nombres assez grands, et il faut rapidement faire une version suffisamment optimis�e en vitesse, sinon on risque d'attendre les r�sultats un peu trop longtemps.
Ouais j'ai eu des mauvaise surprises avec les mutliplications... j'addtionnais n fois un nombre m... c'�tait vraiment trop long! Mais bon la mon algo semble faire le tout en O(lognlogn) (En fait, j'ai vraiment des doutes sur ma fa�on de calculer la complexit� de mon algo �tant donn�e que la fft se fait en O(nlogn)...).
Je vais revoir ma structure de donn�e pour mettre le tout dans un tableau, je n'avais pas du tout pens� � �a! Ce serait beaucoup plus simple, je crois et plus rapide!
Utiliser des fft pour la multiplication n'est rentable que pour des tr�s grands nombres. Il y a d'autres algo qui sont d'une complexit� calculatoire interm�diaire entre le n carr� de l'algo na�f et le N log N de l'utilisation des FFT mais avec en pratique des constantes telles qu'ils sont meilleurs dans la plupart des cas.
J'ai une question aussi na�ve que l'algo en n^2 au sujet des complexit�s. J'ai calcul� mon algo en O(lognlogN) pour le calcul n*N o� n et N sont les nombres, mais j'ai O(X*x) o� X et x sont respectivement les longueurs de n et N. Si je veux comparer avec Karatsuba, fft ou autre, il utilise n comme �tant le nombre ou le nombre de chiffre composant le nombre?
Nombre de chiffres.
R�pondre avec citation
Partager