Grands entiers cpp

Bonsoir,

J'ai un exercice � faire et j'aimerai le faire de la mani�re la plus adapt�e.
Les int et long long int ayant une limite, il s'agit de cr�er une classe en utilisant de la m�moire allou� dynamiquement pour repr�senter et utiliser de tr�s grands entiers (la seule limite sera donc la puissance de l'ordinateur).

Comment feriez vous? Je pense � utiliser des strings, mais j'aimerai conna�tre votre opinion.

Salut,

la string est de loin le pire des choix possibles

Perso j'opterais pour des tableaux de long long, et une r�impl�mentation de tous les op�rateurs

Int�ressant.
C'est � dire en mettant un chiffre par case?
42: t[0]=2, t[1]=4

Citation:

---

Envoy� par Bousk

Salut,

la string est de loin le pire des choix possibles

---

Dans le cadre d�une impl�mentation r�elle, oui. Dans le cadre d�un exercice, pas forc�ment (si par string on entend � tableau de caract�res + longueur). �a permet d�avoir une visualisation plus � habituelle � des donn�es, et donc aide � comprendre ce qu�il se passe.

Citation:

---

Perso j'opterais pour des tableaux de long long, et une r�impl�mentation de tous les op�rateurs

---

yep.

Il y a des librairies pour cela: wiki

Comment cela se passe: avec des tableaux de unsigned char (parce qu'en C/ C++ c'est le plus petit)

Exemple: le nombre 2741369578 devient |2|7|4|1|3|6|9|5|7|8|

Pour g�rer le signe, il faut passer par une classe

Ensuite c'est simple: multiplication, addition et division c'est comme � l'�cole :mrgreen:
La soustraction c'est d�s fois une addition.

Par contre, les calculs flinguent le CPU :aie:

Citation:

---

Envoy� par marcelin88

Int�ressant.
C'est � dire en mettant un chiffre par case?
42: t[0]=2, t[1]=4

---

Non
Chaque partie du tableau repr�sente une partie du nombre r�el

Par exemple, tu choisis le unsigned char comme brique de base, ses valeurs seront 0-255
pour repr�senter 256 tu auras 255 dans une premi�re case, 1 dans une seconde
apr�s faut aussi pr�voir un bit de signe

puis impl�menter toutes les op�rations

Citation:

---

Envoy� par white_tentacle

Dans le cadre d�une impl�mentation r�elle, oui. Dans le cadre d�un exercice, pas forc�ment (si par string on entend � tableau de caract�res + longueur). �a permet d�avoir une visualisation plus � habituelle � des donn�es, et donc aide � comprendre ce qu�il se passe.

---

Non avec une chaine de caract�res ce n'est pas facile:

1. En C++, on a l'impression que c'est un tableau (� cause de l'op�rateur []), mais la repr�sentation m�moire peut �tre lourde. Par exemple en MFC (si je ne me trompe pas :whistle:), un string stockait un pointeur de char et un de wchar et utilisait l'un ou l'autre
2. Pour les op�rations, � chaque chiffre tu as un d�calage de '0' [caract�re 0]: cela va devenir lourd :aie:
3. Tu peux stocker la valeur r�elle, mais attention � l'utilisation parce que un type string n'est pas pr�vu pour stocker des chiffre/ nombres. Le caract�re 9 ou 10 c'est le beeper :mouarf:

Citation:

---

Envoy� par Bousk

Non
Chaque partie du tableau repr�sente une partie du nombre r�el

Par exemple, tu choisis le unsigned char comme brique de base, ses valeurs seront 0-255
pour repr�senter 256 tu auras 255 dans une premi�re case, 1 dans une seconde
apr�s faut aussi pr�voir un bit de signe

puis impl�menter toutes les op�rations

---

1. Si tu peux d�couper facilement un int ou un long en morceaux de 256, dans la vraie vie tu vas avoir en entr�e soit une chaine de caract�re soit un tableau, mais tous deux peuvent d�passer la capacit� 4 octects: Bonne chance pour le d�coupage :ccool:
2. 256, cela va �tre p�nible parce que tu vas avoir � g�rer les d�bordements: 255 + 1 = 0 et non pas 256 :mrgreen:
3. Comment tu vas faire la multiplication?

Citation:

---

Envoy� par foetus

1. Si tu peux d�couper facilement un int ou un long en morceaux de 256, dans la vraie vie tu vas avoir en entr�e soit une chaine de caract�re soit un tableau, mais tous deux peuvent d�passer la capacit� 4 octects: Bonne chance pour le d�coupage :ccool:
2. 256, cela va �tre p�nible parce que tu vas avoir � g�rer les d�bordements: 255 + 1 = 0 et non pas 256 :mrgreen:
3. Comment tu vas faire la multiplication?

---

En m�me temps, si tu n�es pas capable de r�pondre � ces probl�mes l� (qui soin loin d��tre insurmontables, et sont le principal int�r�t de l�exercice), tu ne r�ussiras jamais � impl�menter une gestion de grands nombres correctes, quelqu�en soit la repr�sentation interne.

Comme l�a dit Bousk, la repr�sentation � base de tableau de � mettre ici le type le plus grand pour lequel on a des op�rations de base performantes � sera vraisemblablement la meilleure impl�mentation en terme de rapidit� et de compacit� m�moire (quoique je me demande si on n�a pas int�r�t � utiliser le type de taille inf�rieure, ce qui permet de faire les op�rations dans le type de taille sup�rieure sans craindre un d�bordement). Une repr�sentation � base de char d�cimaux ne pose � vrai dire ni plus ni moins de difficult�s (modulo la possibilit� d�avoir des valeurs qui n�ont aucun sens, mais �a �a se r�gle avec des invariants), si ce n�est qu�elle est plus lisible pour l�humain et moins efficace pour la machine.

Citation:

---

Envoy� par foetus

Comment tu vas faire la multiplication?

---

C'est assez simple : une multiplication n'est rien d'autre qu'une suite d'additions.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

// exemple pour 12*7 // 12 = 1 1 0 0 // 7 = 0 1 1 1   result = 0; result1 = ((1 1 0 0) * (1)) << 0 result += result1 result2 = ((1 1 0 0) * (1)) << 1 result += result2 result3 = ((1 1 0 0) * (1)) << 2 result += result3 result4 = ((1 1 0 0) * (0)) << 3 result += result4

---

Ainsi il n'y � que des multiplication par 1 et 0.
On ne manipule jamais de grands nombres (les multiplication par 1 ou 0 ne sont pas faites).
Les d�calages de bits ne sont pas fait non plus de mani�re "conventionnelle" (avec les op�rateurs << ou >>), mais � la main, tout comme les additions qui agissent sur de grands nombres (qui sont faites par packet de 8/16/32/64/128/... bits), on utilise la carry comme entr�e suppl�mentaire pour la prochaine addition.

Ce code n'est pas optimal, il faut compter le nombre de bits � 1 et r��crire la multiplication dans le bon sens : ici on aurait 7*12 car 12 poss�de moins de bits � 1 que 7.

�a reste un algo hautement vectorisable, et si une instruction madd (a = b*c+d) est dispo c'est un bon cas d'utilisation.

@Iradrille Effectivement cela rajoute plus de "multiplications" :mrgreen:

Parce que si on passe par des tableaux de unsigned char on peut faire les op�rations de base avec des boucles.
[Pour les op�rations comme le cos, log, etc... je ne sais pas par contre: peut �tre des d�veloppements de Lagrange ou autre joyeuset�s math�matiques :?]

Ton exemple n'est pas pertinent: prends un exemple style 1745698234 * 94267185624 :whistle:

Ton exemple 12 -> |1|2| et 7 -> |7|
|1|2|
* |7|
-----

0) Taille du r�sultat = "un truc s�rement simple du style [nombre de chiffres de op1 + nombre de dizaines de op2 + 1]"
1) 2*7 -> 4 retenue 1
2) 7*1 + retenue
3) Retenue 0 -> Rien � faire

|0|8|4|

Et niveau optimisation des op�rations de base, j'avais lu sur Internet que c'�tait impossible:

• On ne sait pas grouper les op�rations.
• On peut sauvegarder certains r�sultats interm�diaires. Mais il faut savoir lesquels, comment les stocker et quand les r�utiliser
• Certains avaient utilis� les maths pour optimiser mais en d�finitive c'�tait plus lent

Citation:

---

Envoy� par foetus

Ton exemple n'est pas pertinent: prends un exemple style 1745698234 * 94267185624 :whistle:

---

Je ne vois pas comment prendre de plus grands nombres rend un exemple pertinent ou non, mais soit.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// 1 745 698 234 = 110 1000 0000 1101 0011 1101 1011 1010 // 94 267 185 624 = 1 0101 1111 0010 1100 0011 0001 1001 1101 1000   result = 0; result1 = ((110 1000 0000 1101 0011 1101 1011 1010) * (0)) << 0 result += result1 result2 = ((110 1000 0000 1101 0011 1101 1011 1010) * (0)) << 1 result += result2 result3 = ((110 1000 0000 1101 0011 1101 1011 1010) * (0)) << 2 result += result3 result4 = ((110 1000 0000 1101 0011 1101 1011 1010) * (1)) << 3 result += result4 result5 = ((110 1000 0000 1101 0011 1101 1011 1010) * (1)) << 4 result += result5 ....

---

Quelques soient les nombres, la technique reste la m�me. Et c'est le m�me algo qu'une multiplication en base 10 (oui, oui, celui qu'on apprend au CE1 ou CE2).

Mais il y � deux probl�mes majeurs � travailler en base 10 : une mauvaise utilisation de la m�moire, utiliser 8 bits par chiffre (cad. 8 bits pour repr�senter 10 valeurs), alors qu'on peut repr�senter 256 valeurs avec 8 bits.
Exemple : 94267185624
en base 10, taille = log10(94267185624) = 11 octets (88 bits + 1 bit de signe)
en base 2, taille = log2(94267185624) = 35 bits + 1 bit de signe

Et des probl�mes d'optimisations : un CPU fonctionne en base 2, il sera bien plus simple d'optimiser des calculs en base 2, qu'en base 10, sans compter les probl�mes qui peuvent arriver avec une plus grande utilisation de m�moire : plus de cache miss, etc...

Niveau optimisation, m�me sans parler de vectorisation, en base 2 on peut facilement faire des op�rations sur 32 bits d'un coup (voir 64 bits pour les additions), alors qu'en base 10 il faudra faire chaque chiffre 1 par 1.
2^32 > 10^9. En base 10 il faudra faire 9 op�rations l� ou en base 2 on n'en fera qu'une.

M�me si il semble y avoir moins d'�tapes en base 10, les calculs seront plus long.

Citation:

---

Envoy� par Iradrille

Je ne vois pas comment prendre de plus grands nombres rend un exemple pertinent ou non, mais soit.

Code:

---

1 2	// 1 745 698 234 = 110 1000 0000 1101 0011 1101 1011 1010 // 94 267 185 624 = 1 0101 1111 0010 1100 0011 0001 1001 1101 1000

---

---

Si c'est pertinent parce que tu ne peux pas coder: :langue2:

Code:

---

1 2 3

long long op1_1 = (94267185624LL * 1745698234LL); long long op1_2 = 101011111001011000011000110011101100;

---

Citation:

---

Envoy� par Iradrille

Quelques soient les nombres, la technique reste la m�me. Et c'est le m�me algo qu'une multiplication en base 10 (oui, oui, celui qu'on apprend au CE1 ou CE2).

Mais il y � deux probl�mes majeurs � travailler en base 10 : une mauvaise utilisation de la m�moire, utiliser 8 bits par chiffre (cad. 8 bits pour repr�senter 10 valeurs), alors qu'on peut repr�senter 256 valeurs avec 8 bits.
Exemple : 94267185624
en base 10, taille = log10(94267185624) = 11 octets (88 bits + 1 bit de signe)
en base 2, taille = log2(94267185624) = 35 bits + 1 bit de signe

Et des probl�mes d'optimisations : un CPU fonctionne en base 2, il sera bien plus simple d'optimiser des calculs en base 2, qu'en base 10, sans compter les probl�mes qui peuvent arriver avec une plus grande utilisation de m�moire : plus de cache miss, etc...

Niveau optimisation, m�me sans parler de vectorisation, en base 2 on peut facilement faire des op�rations sur 32 bits d'un coup (voir 64 bits pour les additions), alors qu'en base 10 il faudra faire chaque chiffre 1 par 1.
2^32 > 10^9. En base 10 il faudra faire 9 op�rations l� ou en base 2 on n'en fera qu'une.

M�me si il semble y avoir moins d'�tapes en base 10, les calculs seront plus long.

---

Tout cela on est d'accord mais dans ton code comment tu fais "result += result1"? :koi: :koi:

Parce qu'avec un std::bitset, tu n'as que des op�rations logiques.
Page de ce type

Code:

---

1 2 3 4 5 6

XXX result = 0; // XXX -> n'importe quel type std::bitset<35> result1( std::string("101011111001011000011000110011101100") );   result1 <<= 2; // Okay result += result1; // Not Okay

---

�dit: Donc en gros, pour utiliser une solution avec le type std::bitset et il faut d'abord faire l'addition pour ensuite faire la multiplication :whistle:
La solution tableau d'unsigned char est plus facile d'acc�s :mrgreen:

Citation:

---

Envoy� par Bousk

Salut,

la string est de loin le pire des choix possibles

---

Pas sur, tout depend des criteres. Si l'appli a peu de calcul et beaucoup d'IO, il peut etre sense d'utiliser des string avec un chiffre decimal par caractere (et dans le codage utilise) comme representation.

Citation:

---

Perso j'opterais pour des tableaux de long long,

---

La j'ai du mal a voir les criteres qui en font un bon choix. L'utilisation d'un type non signe dont on est capable de calculer un multiplication sans risque de depassement me semble un meilleur choix. La question ensuite est "est-ce qu'on prend tout l'intervalle ou bien on se limite a la plus grande puissance de 10 qui tient dedans" (et le choix n'est pas si simple, on passe facilement plus de 20% du temps a faire des conversions depuis ou vers du decimal, donc une representation pour laquelle c'est peu couteux est sensee, quitte a perdre un peu de memoire) .

En passant pour la division qui est l'operation la plus compliquee.

Citation:

---

Envoy� par foetus

Tout cela on est d'accord mais dans ton code comment tu fais "result += result1"? :koi: :koi:

---

On parlait de multiplication, je partais du principe que l'addition �tait donc fonctionnelle.
Niveau code, peut �tre quelque chose du genre

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

struct big_int { bool sign; std::vector<uint32_t> data; };   big_int operator+(const big_int& lhs, const big_int& rhs) { big_int result;   int s = std::max(lhs.data.size(), rhs.data.size()); ++s; bool carry = false; for(int i=0; i<s; ++i) { uint64_t a = (i >= lhs.data.size()) ? 0ull: lhs.data[i]; uint64_t b = (i >= rhs.data.size()) ? 0ull: rhs.data[i];   uint64_t add = a + b + (carry ? 1ull: 0ull);   carry = add > 0xFFFFFFFF; result.data.push_back((uint32_t)(add & 0xFFFFFFFF)); }   // TODO sign return result; }

---

(Pas test�, aucune id�e de si �a marche avec des nombres n�gatifs)

Citation:

---

Envoy� par Iradrille

(Pas test�, aucune id�e de si �a marche avec des nombres n�gatifs)

---

Il te manque aussi la gestion du cas o� tu as une retenue � la fin. Mais sinon, oui, c�est l�id�e.

Int�ressant ;), mais du coup si on revient � mon nombre 94267185624

en base 10, taille = log10(94267185624) = 11 octets (88 bits + 1 bit de signe)
en base 2, taille = log2(94267185624) = 35 bits + 1 bit de signe

Il te faudra alors, pour le stocker, 8 octets (64bits) + 1 signe.
Et les op�rations se font sur 64bits, mais potentiellement le CPU devrait aim�.

@white_tentacle: c'est pris en compte avec le "++s" (mais il y � un risque d'ins�rer un 0 inutile dans le vector). Enfin �a reste plus de l'algo que du code utilisable de toute fa�on.

@foetus: oui, le nombre utilisera 8 octets ici, plus la taille d'un vector + le bit de signe (+ l'alignement), �a peut �tre am�lior�.
Mais sur de tr�s grands nombres l'espace perdu sera minime par rapport � la taille du nombre. Pour r�duire cet espace perdu on peu utiliser des entiers sur 8 ou 16 bits (� la place de 32 comme ici), au prix de calculs plus lents.