Moi je suis complètement pommé là ^^'

heureux de savoir que je ne suis pas le seul.

(Ce n'est pas compliqué non plus. La gestion de la mémoire est déportée sur les vecteurs, et les algorithmes correspondants, on les voit ... au primaire!)

Huhu, on reconnaît les Zéros :-) Et j'en suis hein honte à toi lmghs lol!
Je rigole bien évidemment, mais faut que je me creuse la tête... Ca à l'aire tellement normale, logique pour toi lmghs que s'en ait vexant

ps: Oui, je sors.

oui mais je n'ai pas encore étudié les vecteurs, j'ai les algos a chaque fois en tete, mais je me dis ca sert a rien ca va faire un code de 1000 lignes.

Je dois dire que je bloque également...

J'ai suivi le conseil de lmghs disant de stocker les nombres en base 2^(sizeof(type)*8), mais rien que pour l'addition je bloque...
Comment gérer le dépassement ?

Ne faudrait-il pas plutôt utiliser une base 2^(8*sizeof(type) - 1), pour que l'addition se fasse sans problème ?

A la limite, admettons, mais dans ce cas se pose également le problème de la multiplication...

Si on raisonne de la même manière, il faudrait alors stocker les nombres en base 2^(4*sizeof(type)) pour éviter tout problème de débordement.

Mais bon, je sais qu'en général les conseils de lmghs ne sont jamais donnés au hasard (et sont pertinents), je voudrais donc bien avoir quelques conseils quant à la manière de gérer les débordements (et je pense ne pas être le seul ).

Pour gérer les débordements, utilisez un tableau dynamique, par exemple un vector, ou un tableau "dynamique" alloué via new, comme le fait M@teo21 dans sa classe Zstring. L'avantage du vector c'est que tout sera plus simple puisque vous n'aurez pas à gérer vous-même la mémoire.

Je proposais de mettre dans chaque case du tableau un chiffre entre 0 et 9 (compris), comme on le fait quand on écris un nombre sur une feuille, chaque poisition correspond à l'unité, la dizaine, la centaine...

lmghs proposait, à très juste titres, une optimisation qui consistait à ne pas remplir les cases avec les chiffres entre 0 et 9 mais entre 0 et 2^(sizeof(type)*8) (non-compris). Ceci permet de stocker des nombres 800 (enfin ca dépend de votre implémentation) fois plus grand environ.

Dans tous les cas, la taille du tableau devra varier, il y aura dépassement quelquesoit la base choisie.

Pour des chiffres entre 0 et 9, l'addition ne pose aucun problème, le résultat le plus grand qu'on puisse obtenir étant 18, ce qui, je pense, ne dépasse pas le nombre maximal pouvant être stocké par un unsigned int .

Par contre, 2^(sizeof(type)*8) + 2^(sizeof(type)*8), ça ça déborde de beaucoup le nombre le plus grand pouvant être stockant par type.

Bon, je crois que je vais me rabattre sur une base décimale, ou au plus une base 2^(4*sizeof(type)).

Merci quand même !

Citation : Cyprien_

Pour des chiffres entre 0 et 9, l'addition ne pose aucun problème, le résultat le plus grand qu'on puisse obtenir étant 18, ce qui, je pense, ne dépasse pas le nombre maximal pouvant être stocké par un unsigned int .

Oui mais quand tu fais une addition à la main, chaque "case" ne contient que des chiffres entre 0 et 9 à la fin. C'est aussi le but ici. Il faut chaque fois ramener le nombre dans la plage [0,9], comme on le fait à la main.

Pour le stockage optimal, comme je l'avais dit sur ma première intervention, c'est pour l'exo en avancé. Car effectivement, il y a le problème de détecter le dépassement.

Il y a certainement des façons beaucoup plus intelligentes de le résoudre, en attendant une façon de procéder peut consister à tester si la différence std::numeric_limit<unsigned int>::max() - nombre1 > nombre2 -- + penser à une deuxième passe pour la retenue.

Il peut y avoir deux difficultés dans l'exo:
1- gérer la mémoire
2- convertir en algo une recette que vous avez apprise au primaire.

<parenthèse suite à un autre fil>
Celle qui est importante de savoir faire au début, c'est la 2- : savoir pondre des algos et les mettre en oeuvre. Une fois que cela est compris, vous pourrez vous occuper des rouages internes de la mémoire. En attendant, il y a un tableau redimensionnable: le vecteur.
</>

Est-ce qu'il s'agit d'algo qui sont encore trop compliqués? Aucune idée.

non c'est pas trop compliqué
Mais c'est très long a faire.

Disons que c'est relativement long à faire. Il n'y a que très peu de code à produire. En gros, il suffit de coder:

==
<=
+=
*=
/=

et le reste est "trivial".

EDIT :plus d'actualité j'ai finalement trouvé un algorithme pour diviser (un peu tiré par les cheveux mais il marche)

Comme pour les matrices, je soupçonne qu'il sera plus simple d'écrire *=() à partir de *() que le contraire.
Pour la division, je serai tenté de créer une fonction interne (privée) qui retourne simultanément résultat et modulo. A partir de là, il devient facile de coder les 4 opérateurs /(), /=(), %() et %=()

Citation : lmghs

Comme pour les matrices, je soupçonne qu'il sera plus simple d'écrire *=() à partir de *() que le contraire.

Tout à fait.

Citation : lmghs

Pour la division, je serai tenté de créer une fonction interne (privée) qui retourne simultanément résultat et modulo.

On peut aussi exprimer le modulo a partir de la division comme:

a % b = a - (a/b)*b

si la division représente la division entière (ce qui devrait être le cas dans ce contexte).

Ce que je veux dire, c'est qu'à partir du moment où tu mets en oeuvre l'algo que l'on apprend au primaire, on obtient reste et résultat en même temps.

je sais pas pour vous mais l'algo que jai appris en primaire ne permet pas de créer une division sur les Bigint mais une division de Bigint par int. Alors il faut en trouver un autre qui est à peine différent de celui appris en primaire.

Disons que l'algo appris en primaire permet de faire la division de BigInt a par BigInt B, sous la condition a>b.
Dans le cas contraire, on obtient de toute façon 0.

Tiens alors j'ai pas appris le même algo en primaire :D. Dans le miens on prend tel chiffre de a assez grand pour etre plus grand que b, on divise on fait le reste etc. Mais b lui on peut pas en prendre qu'un bout. Donc si b est trop grand pour etre un int aie.
Ok je suis le seul à m'être compris mais bon.

Tout à fait, c'est le même algo. Je vois pas où est le problème. Je peux très bien mettre le nombre "1" dans un BigInt.

La seule condition est, comme tu le dis, que le dividende soit plus grnad que le diviseur.

Mais lorsque tu divise 123453434255162663734/342526374488585783 par exemple le deuxieme est trop grand pour être stoqué comme un int donc tu peux pas diviser le nombre juste assez grand pour etre plus grand que 342526374488585783 par 342526374488585783 vu que tu est en train de coder la division de bigint et que 342526374488585783 est trop grand pour être converti en int. Je sais pas si je me suis fais comprendre.

Pourquoi mettre dans un int?

ben si on met pas dans un int comment on divise pour avoir le reste ? A moins que ..... au lieu de diviser on soustrer un certain nombre de fois ca peut aussi marcher comme ca.

ça c'est à toi de le faire. Avec cette fameuse technique apprise il y a longtemps. Lis les posts précédent, tu trouveras suffisamment d'info.

Cependant, dans l'algorithme de division que tu apprends en primaire, tu ne viens qu'après à la technique qui consiste à diviser directement par le diviseur tout entier une partie du dividende.
Au début, tu opères par soustractions successives .

EDIT : arf, j'arrive à la bourre, tu as donné la réponse toi-même .

ok je me suis pas mal compliqué pour faire mon algo lol.Mais comme ca si j'envoie l'exo a nanoc il aura un peu de changement

Bonsoir à tous.

Juste une petite question.
Combien d'années de quelles études faut-il pour bien programmer en C++?

Je demande parce que j'ai fait une formation par le CNFDI sur 1 an que j'ai payé assez cher et je n'ai pas l'impression en voyant les exercices d'ici de savoir grand choses

Je pense que je me suis fais avoir sur la formation bien qu'ayant appris la base de la programmation (le langage) et surtout l'analyse !

Je vais cependant m'essayer à ces exercices et persévérer pour faire de mon mieux et réussir à progresser...

(N'oubliez pas quand même de répondre à ma première question et je dirais même en RP pour ne pas gêner le bon déroulement de ce topic ... Merci d'avance)

J'ai une autre question hors sujet de ce topic...
Je suis nul en maths, est-ce que sa va m'empêcher de bien programmer ?
Car dans vos posts vous parlez de formules & co...

ben : je vais répondre 1 par 1

TiPouss : il faut compter 2 ans(pour certains ca peut aller plus vite) de formation pour assez bien maitriser le C.
Je te conseille de pratiquer pour gagner de l'experience et devenir plus fort(a force de trainer sur les fofo sur sdz, je commence a comprendre certains points encore mystérieux du C)

Lecureuil : justement si t'est nul en math , je te conseille de faire de la programmation ! C'est idéal, car tu verras au début ca sera un peu plus dur que pour un génie des maths mais après tu augmentera ton niveau de logique et donc +de logique = + d'aisance en maths.

C'est idéal la programmation.Mais c'est un peu dur a le faire en parallèle avec les cours, il faut etre assez a l'aise en classe pour avoir suffisamment de temps pour programmer le soir. Bref faut apprendre rapidement ses lecons.

Merci beaucoup, sinon, je programmerais plus pendant les grandes vacances (28 mai, je suis en 2nde).
J'aimerais avoir l'avis d'autres personnes sur ma question : "Je suis nul en maths, est-ce que sa va m'empêcher de bien programmer ?".