Discussion :

[.....1.....]

Salut,

C'est encore moi

Je reviens vers vous car je cherche à manipuler un nombre de 645 chiffres, sauf que celui-ci est bien trop grand pour ma machine, visiblement. Donc j'ai cherché en ligne, et excepté des méthodes un peu complexes du style :

• Utiliser gmp.
• Jouer avec des chaînes de caractères et des malloc().

Eh bien je n'ai pas trouvé grand-chose, excepté ceci : long double Flottant double long 10 3.4*10^-4932 à 3.4*10^4932

Du coup je ne comprends pas pourquoi le compilateur refuse de compiler, car sauf erreur un nombre à la puissance 4932 fait bien plus de 645 caractères...

Bref, si vous confirmez que le lien ci-dessus indique une bêtise - ou que j'ai mal compris - je vais me lancer dans des manipulations complexes, n'empêche que je suis étonné que le compilateur refuse de compiler.

Apluss'

PS : petite anecdote aussi : Windows semble ne pas gérer l'affichage des long double (%Lf, etc...).
PS 2 : j'ai des camarades qui s'en sortent avec Java, mais je n'aime pas ce langage.

[Bktero]

Et on peut voir ton code ?

[Mat.M]

Salut,
Je reviens vers vous car je cherche à manipuler un nombre de 645 chiffres, sauf que celui-ci est bien trop grand pour ma machine, visiblement.
Du coup je ne comprends pas pourquoi le compilateur refuse de compiler

il faudrait donner plus de précision on n'est pas madame soleil...
1) de quelles manipulations s'agit-il ? Oui malloc peut suffire en stockant des chaïnes de caractères cependant le problème c'est qu'il faut convertir les chiffres qui composent le nombre en caractères et vice-versa.
Donc voir ce que cette bibliothèque GMP peut apporter de pertinent

2)le compilateur refuse de compiler : quel est le message d'erreur ?

[.....1.....]

Salut, merci pour vos réponses.

@Bktero tu veux voit tout le code ? Car voici comment je déclare ce fameux nombre : long double key = 29999[...];

@Mat.M oui c'est curieux je m'attendais pourtant à trouver madame soleil...

Alors voici le message d'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
warning: integer constant is too large for its type
long double key = 29999[...];
                                                  ^~~~~~~~~~~~~~~~~~~[...]

Je chercher à trouver de quels deux nombres premiers ce nombre (key - clé RSA -) est le produit).

J'utilise d'ailleurs l'opérateur modulo, mais visiblement le type de la donnée ne lui plait pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
error: invalid operands to binary % (have 'long double' and 'long double')
reste = key%i;
           ^

[Daïmanu]

Bonjour.

Lors de la déclaration, tu mets bien le suffixe L (12345L) ? Car sinon un entier (bien trop grand pour la machine) est créé puis converti en long double.

L'opérateur modulo ne fonctionne que sur des entiers. l'équivalent pour flottant est la fonction fmod.

[Bktero]

C'est quoi ce [...] ?

[Bousk]

Tu peux tenter un uint64_t vis stdint. Mais est-ce que ta machine le supporte ? Est-ce suffisant ?

Manipuler de tels nombres est difficiles, c'est bien pour ça qu'il existe GMP. Utiliser GMP est le plus simple, ne pas savoir le faire ne présage rien de bon..
Comment peux-tu en arriver à devoir manipuler de tels nombres en étant clairement un débutant ?
Camarades, donc étudiants et exercices. De quelles manipulations parle-t-on ? Tu peux sûrement t'en sortir pour recréer des opérations simples et l'afficher (ce serait une simple chaîne de caractères), mais c'est bien tout.

[.....1.....]

@Daïmanu non je ne l'avais pas mis, mais même après cela j'obtiens la même erreur...mais en quoi cela aurait pu résoudre le problème si le nombre est trop grand pour la machine ? Et merci pour fmod.

@Bktero ça symbolise le fait que j'ai coupé le reste : je ne vais pas écrire le nombre de 645 chiffres, ni la suite de tous les '~~~~~' que j'obtiens dans le message d'erreur...

@Bousk merci, j'essaierai ta première suggestion. Concernant GMP j'ai bien précisé au début que je ne m'y étais pas encore attaqué et que je le ferai si cela s'avère nécessaire. Sinon comme je l'ai dit le but est de casser une clé RSA en retrouvant les deux nombres premiers dont le produit donne la clé en question.

[Médinoc]

Tu peux tenter un uint64_t vis stdint. Mais est-ce que ta machine le supporte ? Est-ce suffisant ?

2⁶⁴ est largement inférieur à 10⁶⁴⁵, donc non ce ne sera pas suffisant.

Ce qui rend le reste de ton message d'autant plus important: Utiliser GMP.
C'est la référence quand il s'agit de manipuler des Grands Entiers.

PS: long double, ça reste des nombres à virgule flottante, donc si pseudo-à-coucher-dehors a besoin de précision à l'unité près, ce n'est pas la peine. Surtout sous Windows: Visual C++ ne les supporte pas réellement (c'est juste un alias de double, donc à peine 53 bits de mantisse) et MinGW les fait à 80 bits (63-64 (?) bits de mantisse).

Edit: C'est pour de la cryptographie? (quelle surprise, c'est le champ numéro un concernant l'utilisation de Grands Entiers...) Alors la précision à l'unité près est obligatoire, donc tu oublies tous les types standards du C et tu prends GMP.
Edit2: Ou bien tu changes de langage. Le C# supporte une classe BigInteger depuis le .Net Framework 4.0.

[dalfab]

Bonjour,

Ton but serait, si j'ai bien compris, de trouver les 2 facteurs d'un nombre de 645 chiffres.
Si ton objectif est d'y arriver en moins de 10 000 années, j'ai peur qu'aucune bibliothèque de l'univers connu actuel (y compris GMP qui est quand même pas optimisée) n'y arrive. le système RSA est finalement pas si mal foutu.

[.....1.....]

@Médinoc OK je ferai ça alors. Ça confirme aussi ce que faisais faire les autres en Java : utiliser un package spécifique pour traiter les grands nombres.

@Dalfab non, c'est faisable en moins d'un minute : il s'agit d'un travail à but éducatif donc la clé est volontairement faible, même si elle est très longue. Dans l'absolu il n'y a pas énormément de valeur à tester, surtout si tu ne considère que des nombres premiers pour effectuer l'opération.

Bref, encore une fois merci à vous pour votre aide, ça m'a encore été très utile. Je vais regarder la doc sur GMP

Apluss'

[Sve@r]

Bonjour

@Médinoc OK je ferai ça alors. Ça confirme aussi ce que faisais faire les autres en Java : utiliser un package spécifique pour traiter les grands nombres.

Python3 gère les grands nombres de façon native. Donc si t'as le choix du langage...

Dans l'absolu il n'y a pas énormément de valeur à tester, surtout si tu ne considère que des nombres premiers pour effectuer l'opération.

Oui mais faut quand-même les sortir les premiers entre 2 et 10^323...

[.....1.....]

Salut Sve@r

Merci pour ta réponse. En effet avec Python c'est tout simple, sauf que je dois ruser et, en supposant que key = a * b, je dois effectuer ma boucle de calcul en commençant avec a très grand (puis décrémentation) plutôt que a = 1 (puis incrémentation) pour que Python accepte le calcul. Bref, pas évident...

Justement : la clé est faible, c'est-à-dire qu'il ne faut pas tester beaucoup d'entiers premiers pour trouver les deux nombres que je cherche (c'est en ça que la clé est faible). Mais à la main c'est impensable, je dois atteindre un premier proche de 10^8 afin d'obtenir un résultat concluant.

APluss'

Edit : mon idée de décrémentation était débile puisque du coup tout l'intérêt de la faiblesse de la clé saute ; mais après quelques recherches j'ai découvert que // dans Python permettait de bien gérer les divisions de nombres très grands par des nombres bien plus petits.

[Sve@r]

je dois effectuer ma boucle de calcul en commençant avec a très grand (puis décrémentation) plutôt que a = 1 (puis incrémentation) pour que Python accepte le calcul.

Ca je comprends pas. Les opérations se font dans le type le plus large des deux opérandes. Et même en P2, si tu divises un "L" par un petit int, le résultat est donné en "L". Et sous P3 comme tout est "L" de façon interne même plus à se poser de questions. 10**500 // 1 fonctionne (en tout cas chez-moi ça marche)...

[.....1.....]

Salut,

Oui chez moi aussi, sauf qu'au début je ne savais pas qu'il fallait utiliser // au lieu de /. Du coup j'ai cherché un peu avant de comprendre d'où venait le problème...