voila j ai un petit projet a rendre pour dans pas trop longtemps
il s agit de programmer (en C bien sur !!) une calculatrice capable de gerer les nombres infinis dans les differentes bases possibles ( avec gestion des prioritées, %,  ... )
 
> Titoine, camarade setiseur, tu sais de koa je parle...
 
j attends des conseils ... meme les plus petits seront les bien venues
 
P.s : je vais quand meme essayer de vous publier le sujet ...

Faciiiiiiiile !!!

Bah écoute ! je peux te donner la mienne si tu arrives à trouver le seul bug qui fait que ça marche pas :
 -le parseur marche nickel
 -les opérations marchent nickel
mais : parseur +opérations = segfault
 
En fait, j'ai beaucoup appris depuis et je pourrais la débugger mais ça fait chier.
 
Sinon c'est pour quand?
 
PS : Je vais chercher la méthode pour faire les multiplications en une seule passe (méthode croisée) si tu ne la connais pas, car elle est vraiment plus rapide.

Sinon, je dis aussi facile car je me suis tapé le SHELL tout seul et là j'en ai chier mais j'ai réussi!

Bon, on est un peu salauds, là, à dire Faciiiiiiiile !!! sans aider ce pauvre Bemixam...      
 
Bon, allez, je te donne un petit coup de main...
 
Bon, tout d'abord, il te faut un module de gestion de nombres à précision arbitraire (au fait, entiers ou flottants ?), et, par ailleurs, un analyseur d'expressions mathématiques (que tu peux implémenter et tester de façon indépendante, tu n'intègreras les 2 modules que quand tu les auras testés séparément, bien sûr).
 
Pour le gestionnaire de grands nombres, je peux te donner quelques idées (ça a été mon premier projet de formation en info... c'était le bon temps ! ).
On va faire comme si on ne devait gérer que des entiers, ce sera plus simple. Et de toute façon, le gestion de grands flottants se base sur celle de grands entiers, car grand flottant = grand entier (pour la mantisse) + grand entier (pour l'exposant).
 
La façon la plus simple de gérer des grands entiers est de découper ton grand entier en "tranches" (=> tableau C), chaque tranche (élément du tableau) étant facilement représentable en machine. Dans mon projet à moi, je ne représentais mes nombres qu'en base 10, donc j'avais choisi de représenter mon grand entier sous forme d'un tableau d'ints 32 bits, chaque int étant une "tranche" de 8 chiffres décimaux.
Si tu préfères des termes plus mathématiques, je représentais mon entier en base B=10^8, chaque "signe" étant en fait un int 32 bits. Ce qui donne : tout entier N est représenté sous la forme : somme(i=0 à n) (ai * B^i), ai étant la i-ème "tranche" du nombre.
 
J'avais aussi choisi la base 10^8 parce que cela me simplifiait la gestion de la retenue dans l'addition (voir posts suivants). Ceci étant, pour une plus grande compacité du nombre en mémoire, tu peux aussi choisir de représenter ton nombre en base 2^32, si tu veux.
 
Pour les algos, à suivre...

1 - Addition de 2 grands entiers.
 
Facile : pour chaque i entre 0 et n, tu prends la tranche de rang i de chacun des entiers, et tu les sommes. Le résultat te donne la valeur de la tranche de rang i du résultat. N'oublie pas d'ajouter 1 à ce résultat s'il y a débordement à l'itération précédente (ben oui, en base 2, 1+1=0, plus débordement), puis regarde s'il y a eu débordement cette fois-ci, pour t'en souvenir à la prochaine itération (un simple booléen suffit).
 
Attention, du fait de la gestion du signe, le débordement peut se faire par au dessus ou par en dessous (exemple en base 2 : 10 - 1 crée un débordement par en dessous pour le chiffre de rang zéro)
 
 
2 - Soustraction de 2 grands entiers.
 
Ben c'est une addition... Pour moins te faire suer, n'oublie pas de toujours te débrouiller pour que dans l'addition A + B, valeur absolue de A soit plus grande que valeur absolue de B. Si ce n'est pas le cas, tu les inverses (puisque l'addition est commutative). Comme ça, il n'y aura pas de surprise pour les soustractions.
 
 
3 - Multiplication de 2 grands entiers.
 
Là, ça commence à être un peu plus difficile, je te l'accorde.
L'idée est d'appliquer l'algorithme que l'on t'a appris à l'école pour poser les multiplications.
 
Ainsi en base 10:  
      5 6 7 8
    *   1 2 4
 -------------
    2 2 7 1 2    ( =  5678 * 4         )
  1 1 3 5 6 .    ( = (5678 * 2) * 10   )
  5 6 7 8 . .    ( = (5678 * 1) * 10^2 )
 -------------   ( on somme tous ces résultats partiels....)
  7 0 4 0 7 2    ( et voilà !)
 
Il est très facilement généralisable à la base B.
 
Le seul petit problème est la gestion des débordements (encore une fois). En base B=100, par exemple, 64 * 16 = 24, avec un gros débordement (10*B). Pour éviter cela, tu peux gérer la multiplication avec des tranches de taille moitié, ce qui simplifiera beaucoup le travail. Ainsi, avec B=10^8, tu poses C=10^4 (ou si tu préfères B=C^2), et les tranches ai = ai1 * C + ai2 et bi = bi1 * C + bi2. Alors :
   ai * bi
 = (ai1 * C + ai2) * (bi1 * C + bi2)
 = (ai1 * bi1) * B + ( (ai1 * bi2) + (ai2 * bi1) ) * C + (ai2 * bi2).
 
Ca a l'air un peu compliqué, mais en fait c'est une simple distribution de l'addition devant la multiplication, et en plus il y a aucun test à faire, ce n'est que du systématique, donc c'est très efficace.
 
 
4 - Décalage d'un grand entier.
 
Hein ? Quoi ça ?
 
OK, je prends 2 exemples, en base 10 : 15, décalé de 3 vers la gauche égale 15000. 123456, décalé de 2 rangs vers la droite égale 1234.
C'est tout.
 
C'est une opération très simple, mais je te conseile de l'implémenter, car elle est très utile pour l'ordinateur. En particulier pour la division à venir...
 
 
5 - Division (euclidienne) de 2 grands entiers...
 
Hé, hé... Là, ça devient vraiment difficile
Personnellement, j'ai mis 3 ans à trouver un algorithme vraiment efficace (bien après avoir rendu mon projet d'étudiant, donc. Mais ça m'a servi depuis... )
 
Du point de vue mathématique, le principe de la division euclidienne est : pour tous nombres A positif et B strictement positif, il existe toujours un couple unique de nombres positifs ou nuls (Q, R) tel que : A = Q * B + R, avec R compris entre 0 (inclusivement) et B (exclusivement). Evidemment, en français, Q s'appelle le quotient et R le reste de la division euclidienne. Le tout est donc de trouver Q et R.
 
De la définition ci-dessus, on peut déduire l'algorithme suivant. C'est l'algorithme le plus simple qui existe pour calculer une division :
 
    Q = 0;
    while (A >= B) loop
        Q = Q + 1;
        A = A - B;
    end loop;
    R = A;
 
A ma connaissance, c'est celui utilisé dans les processeurs pour la division entre 2 entiers.
 
Problème : pour de grands entiers, malgré le faible temps passé dans chaque itération, le nombre d'itérations est tellement gigantesque que cet algorithme devient inutilisable, car beaucoup trop lent.
 
Il faut alors améliorer l'algorithme comme suit :
 
    Q = 0;
    while (A >= B) loop
        C = <....>
        Q = Q + C;
        A = A - B * C;
    end loop;
    R = A;
 
Le tout est de trouver le C le plus grand possible, mais évidemment pas trop pour que A ne devienne pas négatif...
 
Maintenant accroche-toi un peu, parce que ça va se corser.
 
Pour mon projet, mon algorithme final était : je prends les 8 plus grands chiffres de mon dividende A (éventuellement à cheval sur 2 tranches), nombre que j'appelle A1. Je prends aussi les 4 chiffres les plus grands de mon diviseur B ; au nombre que j'obtiens, j'ajoute 1, et j'appelle ce second nombre B1. Tu remarqueras que A1 est un int 32 bits, et B1 est un int 16 bits, donc 2 entiers machines que le processeur sait très bien manipuler.
 
Pourquoi prendre ces nombres ? Essaie maintenant de décaler (voir section 4) correctement A1 et B1 vers la gauche pour qu'ils aient le même nombre de chiffres que (respectivement) A et B. On va appeler dA et dB le nombre de décalages nécessaires pour (respectivement) A1 et B1. Tu vois alors que A1 décalé est un minorant de A (puisqu'il est un peu plus petit), et que B1 décalé est un majorant de B (puisqu'il est légèrement plus grand).
 
Maintenant, reprenons nos A1 et B1 pas décalés. Calculons C1 = A1 / B1. Cela nous donne un troisième entier machine, forcément . Eh bien, tu verras que C1, décalé de dA-dB, est un très très bon candidat pour notre C au dessus. C'est même un des meilleurs qui soient...
 
Incroyable, non ?
 
 
6 - Autres opérations
 
Une fois que tu as une bonne multiplication et surtout une super division, tu peux t'amuser un peu : racine carrée entière, voire racine n-ième entière (on fait converger une petite suite et c'est dans la poche). Puissance n-ième (attention à utiliser un algorithme logarithmique et non linéaire de la puissance à calculer...). J'en passe et des meilleures...
 
 
Et voilà ! Une fois que tu as implémenté ça, tu as fait le plus difficile du point de vue algorithmique...
 
La calculatrice proprement dite se programmera de façon assez simple avec 2 piles (une pile d'opérateurs, une pile d'opérandes). De toute façon, tu peux l'implémenter de façon indépendante du module de gestion des grands nombres (ça aide quand il faut déboguer...)

Wow, impressionnant !
 

JWhy> Meuh non, meuh non...

et ça sert a quoi tout ça ?

C'est le genre d'exo qu'on te fait faire quand t'apprends l'info.
C'est pas utile en soi, mais ça permet de tâter les parseurs et le management de la mémoire.

recherche de nbre infinis dans les parseurs ? hum .......
 
mais qu'entend tu par management de la memoire ?  

Ben le projet à la base est de faire une calculatrice gérant les grands nombres (c'est à dire précision quelconque, on peut souhaiter 20,100 ou + décimales exactes).
Donc il faut un parseur pour analyser les expressions entrées et gérer les priorités d'opérations ( mult prioritaires sur add). (Avec éventuellement un module qui fait des simplifications algébriques)
Et, comme on doit pouvoir avoir une précision quelconque, la représentation des nombres en mémoire doit être adaptée (comme il a été dit par BifaceMcLEOD) et si on veut pas avoir des fuites de mémoires un peu partout lors du calcul de grosses expressions, faut être un peu soigneux.

Question stupide, très cher. Par définition, l'informatique ne sert à rien...

Oui, enfin, ce n'est pas un compilateur d'expressions mathématiques, non plus, seulement un interpréteur (cela dit, un compilateur math-ique, j'ai fait aussi, Bemixam ! )

merci beaucoup ...
voici des precisions :
 
L'expression arithmetique est composee denombres entiers.
Cette expression est donnee sous la forme d'une chaine de caracteres. Celle-ci
s'appelle "expr".
Exemple:
 
  char *expr = "234233*(2324244432+234243243/(234234243+23423423))";
 
 
  Ces nombres sont exprimes dans une base quelconque. Labase est donnee
sous la forme d'une chaine de caracteres nommee "base"
Exemple:
 
  char *base = "artye";
 
 
  Il y a 5 operateurs implementes, definis par des #define.
 
        #define OP_ADD     '+'
        #define OP_SOUS    '-'
        #define OP_MUL     '*'
        #define OP_DIV     '/'
        #define OP_MOD     '%'
 
  On trouve aussi un delimiteur de priorite.
 
        #define DEL_START  '('
        #define DEL_END    ''
 
  Au final, la machine affiche la representation du resultat de l'expression dans la
base.
  Bien evidement, la machine est capable est gerer les erreurs comme toute
calculatrice de notre epoque qui se respecte.

BifaceMcLeOD a écrit a écrit :   Oui, enfin, ce n'est pas un compilateur d'expressions mathématiques, non plus, seulement un interpréteur (cela dit, un compilateur math-ique, j'ai fait aussi, Bemixam ! )

 
Ouaisn enfin il peut être intéressant de pouvoir simplifier:
13 + (1000000000003 - 12)
ou  
4849965616 * 1
 
Mais bon ça commence à devenir compliquer

Si c'est juste une calculatrice, ce n'est pas nécessaire... Elle ne va pas simplifier, juste calculer (disons "évaluer" )...
 
Bemixam, est-ce que tu sais ce que c'est qu'une pile ? Parce que j'en ai parlé vite fait dans un précédent post, mais peut-être que tu ne sais pas....

Apparemment il entre les expressions à évaluer sous forme de chaînes de caractère, en notation classique.
Donc il doit directement construire son arbre, puis l'évaluer, non ?

A mon avis, pas besoin d'un arbre, tu peux évaluer en même temps que tu analyses, avec une gestion de piles correcte (il faut deux piles ici).
 
Les arbres, ça commence à être assez évolué, comme structure de données, je ne sais pas si c'est très facile d'accès pour Bemixam (je ne connais pas son niveau). C'est quand même les dernières structures de données qu'on apprend en algorithmique...

effectivement je debute en programmation ...( un peu moins de 4 semaines )
mais j ai droit a une formation assez rapide
c pour ca que c bien d etre dans une grande ecole d info parisienne ...
 
on m a parlé des piles et des arbres en me disant que ça
serais vachement pratique pour ma calculatrice
mais je vois pas trop comment ça fonctionne...

Tu pourras constater au cours de ta formation que les informaticiens adorent les métaphores. La structure de données de type pile est l'une d'entre elles.
 
Imagine une pile d'assiettes, dans un tiroir (qu'on ne peut voir que du dessus, donc). Tout ce que tu peux faire sur cette pile d'assiettes, c'est :
 - Ajouter une assiette au somment de la pile (on peut aussi en ajouter plusieurs d'un coup, mais cela revient à en ajouter une plusieurs fois). Appelons cela empiler.
 - Prendre une assiette du sommet de la pile (tu peux aussi essayer d'en enlever plusieurs d'un coup, mais un, attention à la casse, et deux, de toute façon, c'est comme si tu les enlevais une à une). Appelons cela dépiler.
 - Voir s'il y a des assiettes dans la pile (autrement dit, si la pile est vide ou pas).
Et c'est tout.
 
Et bien en informatique, c'est pareil ! Tu remplaces les assiettes par des données en mémoire, et le tour est joué.
 
Maintenant, pour l'implémentation, je ne pense pas qu'une super implémentation de-la-mort-qui-tue te soit nécessaire. A mon avis, une pile basée sur un simple tableau suffira amplement.
 
Je te propose donc la petite implémentation suivante :
 
/* Prototypes - à mettre dans Piles.h */
typedef int BOOL;  /* Juste pour avoir un type booléen en C. */
#define TRUE  1
#define FALSE 0
 
typedef void* OBJET;
 
typedef struct {
    OBJET*  liste;
    int     sommet;
} Pile;
 
Pile* creePile();
void  empile(Pile* pile, OBJET objet);
OBJET depile(Pile* pile);
BOOL  pileVide(Pile* pile);
void  detruitPile(Pile* pile);
/* Fin des prototypes. - Piles.h */
 
/* Début de Piles.c */
#include <stdlib.h>
#include <assert.h>
 
#define PROFONDEUR_MAX_PILE  20
 
Pile* creePile()
{
    Pile*  pile = (Pile*) malloc(sizeof(Pile));
 
    pile->sommet = -1;
    pile->liste  = (OBJET*) calloc(PROFONDEUR_MAX_PILE, sizeof(OBJET));
 
    return pile;
}
 
void empile(Pile* pile, OBJET objet)
{
    pile->sommet++;
 
    /* Si on essaie d'empiler plus d'objets que la pile */
    /* ne peut en contenir, on quitte le programme. */
    assert(pile->sommet < PROFONDEUR_MAX_PILE);
 
    pile->liste[pile->sommet] = objet;
}
 
OBJET depile(Pile* pile)
{
    OBJET  objet;
 
    /* Si on essaie de dépiler un objet d'une pile vide, */
    /* on quitte le programme. */
    assert(!pileVide(pile));
 
    objet = pile->liste[pile->sommet];
 
    pile->sommet--;
 
    return objet;
}
 
BOOL pileVide(Pile* pile)
{
    return (pile->sommet < 0);
}
 
void detruitPile(Pile* pile)
{
    /* Si on essaie de détruire une pile 2 fois, */
    /* on quitte le programme. */
    assert(pile->liste != NULL);
 
    free(pile->liste);
    pile->liste = NULL;
    free(pile);
}
/* Fin de Piles.c */
 
Bon, j'ai tapé ça vite fait en one-shot, donc il se peut qu'il y ait quelques petits soucis qui m'auraient échappés. Mais normalement, il n'y a pas de raison.
Avec ça en plus, une fois la gestion de pile isolée dans son fichier .c à part, tu n'as plus à te préoccuper de la cuisine interne de la pile, tu ne fais qu'utiliser les fonctions du fichier Piles.h.
Sinon, j'ai défini le type OBJET comme void*, car c'est le type le plus générique qui soit, mais tu peux sans doute le remplacer par autre chose.
 
Maintenant pour l'utilisation dans un évaluateur d'expressions mathématiques, je te donnerai quelques idées rapides dans un prochain post...

Quelques idées sur comment fonctionne un évaluateur d'expressions arithmétiques basé sur des piles.
L'idée d'un évaluateur (plus généralement un interpréteur, par opposition à un compilateur), et d'évaluer, ou d'exécuter une expression en même temps qu'il la lit. C'est le mécanisme que je vais décrire ici.
 
L'évaluateur d'expressions arithmétiques utilise généralement 2 piles, une pile d'opérateurs, et une pile d'opérandes. Il enregistre aussi à quelle profondeur de parenthèses il se trouve. J'appellerai la pile 1 celle des opérateurs, et la pile 2 celle des opérandes.
 
De façon générale, tant qu'il n'y a pas de problèmes de priorité, dès qu'on trouve un opérateur, on l'empile dans sa pile (la numéro 1), et dès qu'on trouve un nombre (un opérande, donc), on l'empile dans sa pile (le numéro 2). Et dès qu'on trouve 2 opérandes disponibles dans la pile 2, et un opérateur disponible dans la pile 1, on dépile ces 2 opérandes (n2, puis n1) et cet opérateur (op), on calcule n1 op n2 (attention à l'ordre, tous les opérateurs ne sont pas forcément commutatifs !), et on empile le résultat du calcul dans la pile des opérandes (numéro 2).
 
Maintenant prenons un exemple concret. Essayons d'évaluer l'expression (simple) : 2 + (5 + 3), et regardons comment un évaluateur peut fonctionner :
 
Caract.   Pile 1   Pile 2   Action
-----------------------------------------------
 2                        2       Empiler opérande
 +             +         2       Empiler opérateur
 (                                  Faire en sorte que le prochain opérande ne provoque pas d'évaluation.  
 5                        2 5     Empiler opérande.
 +             + +       2 5     Empiler opérateur
 3             + +       2 5 3   Empiler opérande
 )                                  Dépiler 2 opérandes et 1 opérateur, calculer, empiler le résultat 5 + 3 = 8
               +         2 8
FIN DE CHAINE                Dépiler 2 opérandes et 1 opérateur, calculer, empiler le résultat 2 + 8 = 10
                          10
 
Normalement, à la fin, la pile des opérateurs est vide, et la pile des opérandes ne contient qu'un élément : le résultat final de l'évaluation.
 
A toi de jouer, maintenant...    
 

--Message édité par BifaceMcLeOD--

encore une fois merci !!!!
 
normallement je pourrai commencer le projet dans 2 jours
( j aurais alors 2 semaines pour tout faire )
 
j ai lu tout ce que tu m as explique j ai compris les grandes lignes
mais j aurais surement a nouveau besoin d aide pour ce qui est de  
l aplication de la theorie
 
mais une chose reste floue pour moi... comment gerer les nombres  
infinis
j ai vu le type de valeurs avec lequel ils allait corriger et ce sont des chaines de caracteres qui font plusieurs pages a l ecran

Tu n'as pas à t'en préoccuper. L'important est de savoir transformer un grand nombre en sa représentation interne, et vice versa. Qu'il fasse 10 pages d'écran ou 10 caractères ne change rien... si la représentation le supporte (et celle que je t'ai suggérée le supporte). L'informatique, c'est la science du traitement de la représentation de l'information (et non la science du traitement de l'information, car tant qu'on ne sait pas représenter l'information, on ne peut rien faire. Une fois représentée linformation, elle peut alors être manipulée).
 
Attention : le nombre n'est pas infini, il est juste grand. La différence est peut-être faible, mais elle est importante.

titoine42> Pour tes pb de seg fault, il existe un utilitaire unix qui s'appelle "purify" qui permet de détecter précisement les bugs (c'est un utilitaire commercial mais je l'utilisait souvent pour mon projet de compilation).
à la compile il suffit de prefixer le compilo gcc.
Par exemple : purify gcc -g toto.c -o toto
Quand on lance "toto", purify se lance et récolte plein d'information pendant l'execution du programme.
 

Petite précision, dans le cas où le programme a plusieurs modules : Il n'est pas nécessaire d'appeler Purify à la compilation mais seulement à l'édition de liens.
 
Et je confirme que Purify est un outil (preque) magique pour détecter les erreurs mémoire de tous ordres : débordement de tableaux, de piles, lecture de mémoire non initialisée, mémoire allouée avec new et libérée avec free() (allouée avec malloc() et libérée avec delete) et aussi... toutes les fuites mémoire !
 
Par ailleurs, Purify est aussi disponible sur Windows NT. Il est aujourd'hui distribué par Rational Software (qui a racheté Pure Software).
 

--Message édité par BifaceMcLeOD--

oui en effet pas besoin de le faire à la compil puisque purify instrumente les fichiers objets (.o) mais il faut quand meme intégrer les infos de debugage pour qu'il reporte où se trouve l'erreur.
Pour ceux qui développent sous Visual C++, il existe un outil équivalent qui s'appelle "BoundChecker" (de NuMega, livré avec DevPartner Studio). C'est un peu moins bien que purify mais ça rend aussi des services inestimables (en temps de développement).
 
Autant dire qu'il vaut mieux utiliser purify que de chercher un bug dans une meule de code

Et bah chapeau les gars..  
Je suis littéralement bluffé...
 
J'ai tout lu avec grand intérêt, j'ai presque tout compris (bon, j'ai pas fait d'école d'ingé. mais plutot DUT+MIAGE), C très didacticiel et ca m'a rappelé quelques bons souvenirs d'Algo...  
 
Encore une fois merci pour cette lecon très intéressante....
(là je galère plutôt avec les EJB, RMI, Java et mister CORBA mais C vraiment sympa aussi..)
Vive Java !!!  

Up ! Pour ceux que ça intéresse...

Assez interessant mais un peut (beaucoup) complexe :| snif!
c'est la que on vois que il y a des petit géni parmits nous

ca y est ... j ai commence a bosser sur la bistro
mais je sais pas trop par ou commencer
par le parseur ??
ou toute la partie operation ??
 
je penche plutot pour le parseur...

[citation][nom] L'informatique, c'est la science du traitement de la représentation de l'information (et non la science du traitement de l'information, car tant qu'on ne sait pas représenter l'information, on ne peut rien faire. Une fois représentée linformation, elle peut alors être manipulée).
 
Attention : le nombre n'est pas infini, il est juste grand. La différence est peut-être faible, mais elle est importante.
 
[/citation]
 
 
Cela est fondamemtal
Bravo à toi, oh maître ...

Je suis aussi en epitech1 comme bemixam et je vous remercie tous et tout particulierement biface mcleod pour toutes ces aides precieuses pour la bistro

la bistromatique j'ai vru au départ que c'était un moyen de mesurer le degré de dépendance des personnes aux bistrots, mais apparement c'est pas ca

salut les filles je voudrais plus d'information svp
comment stocker les nombres dans un int de 32bits ?
et si possible un petit exemple  
 
merci d'avance
 
 
 
 
vive yifeng et epitech

Eh oh les pt'its qars, faudrait penser à brancher les neurones de temps en temps, ça fait pas de mal.
C'est quand même pas trop dur de trouver une structure de données pour ça (même si elle sera pas forcément très efficace). En plus tous le prog en dépend, donc vaut mieux que ce soit la votre et que vous y ayez refléchi un peu.
 
En plus Biface a donné une piste un peu plus haut.

Désolé, mais je ne comprends pas ta question. Quel type de nombre veux-tu stocker ? Des entiers, des réels ?
 
Parce que si ce sont des entiers, que je sache "int" veut dire entier, donc c'est déjà fait... A moins que tu veuilles savoir comment fait l'ordinateur pour stocker des nombres entiers dans un int32...

comment tu fais pour stocker une chaine de caracteres dans les entiers (int)... il faut que tu m'expliques d'avantage sur la
methode de 8bits de char dans 32 bits de int... en les decalants
afin de gerer les operations de base...
 
bon... pour tout dire donner moi des exemples please...

Slt,
Je vois que vs avez pas mal de connaissance en prog !
Pourrais je savoir votre niveau d'etude ?
Peut tu donner un exemple d' algo?
Merci de me repondre...
;+D

Tout cela m'a l'air bien confus...
Je n'ai jamais dit (en tout cas il ne me semble pas) qu'il fallait, ni même qu'on pouvait, stocker des chaines de caractères dans des entiers.
Simplement, pour représenter de façon exacte un entier de 120 chiffres décimaux, un entier 32 bits ne suffit pas, car il faut 400 bits. Eh bien OK, dans un tableau de 13 entiers 32 bits, tu les as, tes 400 bits. Bien sûr, après, pour faire une addition entre 2 tableaux, c'est pas aussi simple que "a + b", mais c'est le but du jeu...
 
Mais quel rapport avec les chars ? Ou "la methode de 8bits de char dans 32 bits de int... en les decalants " ?