Stocker des grands nombres

C'est pas de ma faute à moi si on nous fait faire des choses 'inutiles'. Moi je dois réaliser une calculatrice travaillant sur des nombres de l'ordre de 1000 chiffres (comme je l'ai déjà dit) et je dois pouvoir faire avec ces nombres un certain nombres d'opérations (+,-,*,/,racine, factorielle,...). C'est pour cela que je me demandais quel était le meilleur moyen pour stocker ces nombres, pour pouvoir ensuite les manier et faire ces opérations, sachant que ce projet est une application du cours et que notre cours portait principalement sur les listes chainées, c'est pourquoi j'avais voulu stocker mes nombres de cette manière.

j'ai bien compris, et si tu as lu, je mettais en cause le prof..

J'aimerais beaucoup que tu lui transmettes ce que j'ai mentionné dans mes 2 contre-exemples : taille de l'univers en milionnièmes d'angstroms, et nombre de bits équivalents, et j'aimerais vraiment beaucoup qu'il me justiife son choix... et la pertinence pour vous... (et d'ailleurs pour tout un chacun)..

Si tu peux et si il peut répondre, ce serait sympa..

Merci

souviron : la réponse est là :
Il est très probable que le prof répondra que c'est simplement un exercice sur les listes chaînées.

Citation:

---

Envoyé par TrexXx

sachant que ce projet est une application du cours et que notre cours portait principalement sur les listes chainées, c'est pourquoi j'avais voulu stocker mes nombres de cette manière.

---

j'aimerais juste comprendre porquoi on fait travailler des gens sur des nombres de chiffres absurdes.. et je dis bien "absurdes"...

S'arrêter à 41 , comme je le disais, donnerais déjà l'Univers au millionième d'Angstrom près...

Et je répète que cela ne fait qu'enfoncer de fausses notions dans la tête des jeunes...

Et j'aimerais avoir une explication du pourquoi un prof peut vouloir prendre un tel nombre, qui ne se retrouvera jamais (regarde plus haut : même en cryptage, en admettant que l'on veuille (et matériellement puiisse) crypter sur 512 bits, il suffirait de 160 chiffres....

Citation:

---

Envoyé par souviron34

j'aimerais juste comprendre porquoi on fait travailler des gens sur des nombres de chiffres absurdes.. et je dis bien "absurdes"...

---

À partir du moment où tes calculs sont exponentiels, tu peux avoir besoin de beaucoup de chiffres. L'exemple-type est le rendement global d'un système : 90% de 90% de 90% de 90% de 90%, ça fait 59%.

Dans le cas d'une progression géométrique, l'imprécision des derniers bits d'un nombre flottant peut se propager aux précédents à chaque itération.

Citation:

---

S'arrêter à 41 , comme je le disais, donnerais déjà l'Univers au millionième d'Angstrom près...

---

Donc, si on voulait mesurer le volume de l'univers, par exemple, il en faudrait déjà 123.

Citation:

---

Et j'aimerais avoir une explication du pourquoi un prof peut vouloir prendre un tel nombre, qui ne se retrouvera jamais (regarde plus haut : même en cryptage, en admettant que l'on veuille (et matériellement puiisse) crypter sur 512 bits, il suffirait de 160 chiffres....

---

Il n'y a pas que le chiffrement. Il y a le calcul de CRC, par exemple. Bon, je te l'accorde, la plupart du temps, ces calculs sont décomposés en unités de la largeur d'un type manipulable par le langage.

Le problème vient surtout du fait qu'il n'y a pas de demi-mesure. Soit ce que l'on fait tient dans les types natifs et il n'y a pas de problème, soit on dépasse et dans ce cas, on utilise une bibliothèque de manipulation de chiffres qui procède toujours de la même façon, qu'elle travaille sur 100 bits ou 10000.

Citation:

---

Envoyé par Obsidian

Donc, si on voulait mesurer le volume de l'univers, par exemple, il en faudrait déjà 123.

---

Et la notation scientifique, ça sert à quoi 10^123 ça marche pas (en C e+123, et on a même le droit de le prendre au carré, puisqu'on a le droit à e+308) ??

Et le sens ??

Quand on mesure des milliards d'années lumières, on n'est même pas à 1 année ou 10 000 années-lumières près...

(plus près de nous, il suffit de regarder les définitions des cycles terestres (Crétacé, époque quaternaire... : on n'est même pas à 10 millions d'années près :aie:)..

Citation:

---

Envoyé par Obsidian

Le problème vient surtout du fait qu'il n'y a pas de demi-mesure. Soit ce que l'on fait tient dans les types natifs et il n'y a pas de problème, soit on dépasse et dans ce cas, on utilise une biblithèque de manipulation de chiffres qui procède toujours de la même façon, qu'elle travaille sur 100 bits ou 10000.

---

Voilà à mon avis le fond du problème. Considérer des bits comme des chiffres... En unités décimales déjà on divise par 3, et en nombre encore une fois la signification d'une telle précision est absurde. Et de plus, encore une fois, à part pour écrire des bits pour du cryptage (et CRC en est une sorte) , qui se sert de ça ???

Je pense donc que le tout vient d'une profonde confusion entre nombre utilisable et représentation binaire d'un grand nombre...


C'est ça que je ne comprend pas... Qu'on l'enseigne dans un cours pour les futurs cryptographistes, ou en maths avancées en théorie des grands nombres, soit.. Mais je ne comprend vraiment pas , mais alors pas du tout, que, au vu du nombre de posts sur le sujet (et au vu des questions et dialogues lors des posts, on n'a pas affaire à des spécialistes de maths avancées) cela soit enseigné quasi "de base" (voir la remarque de droggo "presque basique") à des débutants...

Encore une fois, je trouve que cela perturbe l'appréhension de la notion de précision, de représentation normale d'un nombre, de calculs, etc etc... (voir mon exemple sur le volume de l'Univers)...

Citation:

---

Envoyé par souviron34

<...>Encore une fois, je trouve que cela perturbe l'appréhension de la notion de précision, de représentation normale d'un nombre, de calculs, etc etc... (voir mon exemple sur le volume de l'Univers)...

---

Tes considérations scientifico-philosophiques sont certes intéressantes, mais totalement hors-sujet. Un grand entier, c'est quand on dépasse ce que sait faire nativement la machine (unsigned long en C90, unsigned long long en C99).

Si j'ai besoin de 32-bit sur un PIC, j'ai pas le choix, je dois apprendre à faire des calculs 'grands entiers'.

Comme l'a fait remarqué quelqu'un, qu'on travaille ensuite sur 32, 100 ou 1000000 bits, c'est pareil. Il n'y a que le temps de calcul qui change.

L'usage qui en est fait ne nous regarde pas. J'imagine que si on veut compter le nombre d'électrons contenus dans l'univers, il va falloir plus que 1000 bits... si on cherche une précision absolue (ce qui est absurde, je te l'accorde).

Mais même en précision relative (réel codé en virgule flottante), un double serai-t-il suffisant (je ne sais pas si le C garantit les 1E308)

Jai,

@ souviron34 :

Bref, pour toi, seuls comptent les calculs liés à la physique, au monde réel.

En math en tout cas, en théorie des nombres, on a très fréquemment besoin d'une précision allant bien au-delà des types standards, en C ou autre.

La principale activité liée est la crypto, mais ce n'est pas la seule, comme tu l'affirmes systématiquement.

Que tu n'en aies jamais eu besoin dans ta carrière n'est pas un critère pour dire que ça ne sert à rien, ou si peu.

Ne serait-ce que : qui à envie de faire ça a bien le droit d'essayer, même s'il n'y a pas d'utilité immédiate, non ?

Citation:

---

Envoyé par souviron34

Et la notation scientifique, ça sert à quoi 10^123 ça marche pas (en C e+123, et on a même le droit de le prendre au carré, puisqu'on a le droit à e+308) ??

---

Ce n'est pas la question. Cet exemple était là pour montrer que même en considérant ce qui semble être une limite, on peut encore faire face à des calculs exponentiels qui augmentent d'autant le nombre de chiffres nécessaires. En l'occurence, ils le sont si tu tiens à garder ta précision en distance.

Citation:

---

Et le sens ?? Quand on mesure des milliards d'années lumières, on n'est même pas à 1 année ou 10 000 années-lumières près...

---

La mesure physique est un domaine précis, pointu, et très particulier des mathématiques. Un ordinateur sert à bien d'autres choses. J'irai même jusqu'à dire qu'un ordinateur sert précisément à faire les manipulations de données qui seraient humainement infaisables ou, à tout le moins, trop rébarbatives. Manipuler les nombres astronomiques en fait partie. Utiliser les ordinateurs uniquement pour faire ce que l'on peut faire sur papier reste pratique, mais en restreint de beaucoup l'intérêt.

Un cas d'école est le calcul de Pi, par exemple. C'est un bon exercice pour un étudiant, et il est souvent employé comme problème-type pour éprouver la puissance des super-calculateurs. Or, le nombre de décimales de Pi n'a pas de limites et il reste dans l'intérêt de la science d'en connaître le plus possible. C'est donc un cas où l'on a besoin d'allouer autant de chiffres que la mémoire le permet et de faire en permanence des calculs dessus, qui doivent être exacts.

Citation:

---

Voilà à mon avis le fond du problème. Considérer des bits comme des chiffres... En unités décimales déjà on divise par 3, et en nombre encore une fois la signification d'une telle précision est absurde. Et de plus, encore une fois, à part pour écrire des bits pour du cryptage (et CRC en est une sorte) , qui se sert de ça ??? Je pense donc que le tout vient d'une profonde confusion entre nombre utilisable et représentation binaire d'un grand nombre... C'est ça que je ne comprend pas... Qu'on l'enseigne dans un cours pour les futurs cryptographistes, ou en maths avancées en théorie des grands nombres, soit.. Mais je ne comprend vraiment pas , mais alors pas du tout, que, au vu du nombre de posts sur le sujet (et au vu des questions et dialogues lors des posts, on n'a pas affaire à des spécialistes de maths avancées) cela soit enseigné quasi "de base" (voir la remarque de droggo "presque basique") à des débutants...

---

Parce que si ça n'a pas de sens pour un physicien, cela en a en revanche énormément pour un informaticien, car c'est (censé être) lui le garant de la machine à calculer à laquelle les physiciens se fient. Il est donc vital d'en connaître les subtilités techniques.

Truc bête : prends un float en simple précision (sur 32 bits, donc). Si tu codes 1 000 000 000, tu ne peux pas coder 1 000 000 001. Pourtant, un milliard, ça n'a rien d'ésotérique. Voici un petit programme trivial pour mettre le phénomène en évidence. Essaie de décommenter une ligne puis l'autre, pour voir :-)

Le truc à ne surtout pas faire étant alors de se dire « on choisit dès le départ un format suffisamment grand pour ne pas être emmerdé ». D'abord parce qu'à ce moment, on ne fait plus le même métier, ensuite parce que les limites sont toujours atteintes beaucoup plus vite qu'on ne le croit (ex: domaine des adresses IPv4).

Code:

---

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

#include <stdio.h>   int main (void) { float x,y;   /* x = 1000; */ /* x = 1000000000; */   for (y = x ; y< (x+1000) ; y += 1.0) printf ("%f\n",(double)y);   return 0; }

---

C'est plutôt génant dans n'importe quel système embarqué.

Un rapport de 1 à 10^9, c'est peut-être négligeable en sciences, c'est plus chiant si tu tiens des comptes en banques, par exemple. Peu à peu, les centimes se perdent, c'est l'usure des temps modernes. Là encore, si on n'a pas mis le doigt dessus assez tôt, un programmeur essentiellement axé finances est capable d'utiliser un nombre à virgule flottante pour représenter le solde d'un compte à virgule fixe et s'exposer aux mêmes risques.

Mais là encore, il ne s'agit que d'exemples sporadiques. Je pense que le plus grand « danger » vient de ce que j'ai exposé dans mon précédent post : le cumul des imprécisions. Si tu multiplies n fois un nombre flottant par un autre dont l'imprécision est connue, alors celle-ci progresse jusqu'à gagner tous tes chiffres.

C'est génant quand tu fais de nombreux calculs, des itérations (calcul de suite, de progressions), mais également quand ton logiciel est amené à fonctionner très longtemps sans être réinitialisé (cas de l'embarqué). Imagine les conséquences de ces imprécisions sur le G.P.S., par exemple.

À contrario, manipuler mille chiffres est à la portée de n'importe quel microprocesseur, même limité en RAM.