Discussion :

[chemkacte]

Bonjour.

Cette question n'appartient pas strictement à l'algorithmie, mais comme je n'ai toujours pas choisi le langage dans lequel s'écrira le programme, c'est cette catégorie qui me semble la plus approprié.

Je dois écrire un programme qui manipulera des nombres immenses. Selon ce que j'ai vu, il y a toujours une limite de précision selon le type de variable (j'ai surtout regardé en C++). Est-il possible — et si oui : comment ! — d'écrire une variable sans limite ? J'ai entendu parler de variables « multi-précisions », comment on utilise cela dans un code ?

Merci.

Pour vous donner un ordre d'idée, les nombres que je dois manipuler sont compris entre 10^100'000'000 et 10^1'000'000'000, voir un peu plus, dépendamment des résultats!

Merci encore.

[chemkacte]

Je viens d'apprendre que la machine opère sous CentOS 6.4. Donc on oublie le C++!

[prgasp77]

Salut, ce que tu cherches est une bibliothèque de nombres à virgules flottante de précision arbitraire, ou en anglais : arbitrary precision floating point (google). La plupart des langages haut niveau permettent l’existence de telles bibliothèques, certains parmi leur biblio standard.

Question auxiliaire : pourquoi pas de C++ sachant que c'est du CentOS ?

[chemkacte]

Sauf erreur, le C++ est un langage windows. Il crée des exécutables .exe, qui, à ma connaissance, ne sont compatibles qu'à travers des programmes genre "wine" sous linux. Mon programme doit être optimisé au maximum (J'ai un temps limité sur le supercalculateur).

Pour l'instant, je considère Phython. Ceci-dit, je ne suis pas programmeur. Je n'ai eu que quelques cours de bases en delphi, en algo et en mathématique appliqué à l'informatique. Je travaille seul sur ce projet, donc, faute de moyen, je dois tout faire. Et à vrai dire, je rame un peu...

[chemkacte]

Question auxiliaire : quelle est la différence entre le "multi-précision" et le "précision arbitraire". Lequel devrait être le plus performant?

[nono_31]

Bonjour,

Le C++ n'est pas un langage windows, vous pouvez écrire des logiciels portables.
C++ est puissant et structuré, mais réputé difficile.
Python est plus souple, mais plus lent.

quelle est la différence entre le "multi-précision" et le "précision arbitraire".

Aucune

Lequel devrait être le plus performant?

À mon avis, vous vous posez les mauvaises questions en songeant dès à présent aux performances.
La priorité est d'écrire un programme à peu près correct en un temps fini.

Si vous n'avez pas de grandes compétences en Info et que votre programme reste "petit", je vous conseillerais python.

Une dernière remarque concernant vos nombres ? Combien de chiffres significatifs ont-ils ? Est-ce qu'il n'y a pas une astuce pour les compresser ?

Cordialement.

[Obsidian]

Bonjour à tous,

J'arrive après la bataille, pardonnez-moi d'avance si je suis redondant sur certains points mais c'est un débat qui me fait réagir moi-aussi…

Je viens d'apprendre que la machine opère sous CentOS 6.4. Donc on oublie le C++!

Le C++, comme le C, est un langage normalisé qui est aujourd'hui très bien pris en charge par g++. À dire vrai, ca fait un certain temps maintenant que je n'ai plus touché à Visual C/C++ mais beaucoup de gens se plaignent encore sur les forums de son respect tout relatif de la norme. Tu confonds peut-être avec C# qui, lui, est en quelque sorte le Java de Microsoft.

A part pour exercices, et pour de la crypto, il est humainement et physiquement IMPOSSIBLE d'avoir à manipuler des opérations sur de tels nombres nécessitant des bibliothèques spéciales !!!!!!!!!!!!!

Oui, mais souviens-toi que c'est une discussion que l'on a déjà eue : http://www.developpez.net/forums/d66...rands-nombres/

Autant je suis entièrement d'accord avec le fait qu'il faut toujours commencer par réfléchir à un problème et pas se lancer d'emblée dans une consommation de ressources inutile, autant il faut se souvenir qu'un ordinateur SERT à effectuer les manipulations de données humainement infaisables.

Il faut bien garder à l'esprit, également, que l'homme pratique les mathématiques depuis l'antiquité, mais n'utilise les ordinateurs de manière sérieuse que depuis une cinquantaine d'années, et que l'explosion de la puissance de calcul disponible à tous n'est une réalité que depuis 20 ans (le PC sur lequel j'écris ces lignes était considéré comme un super-calculateur à cette époque).

Cela signifie que l'on a toujours pris l'habitude de pratiquer ces mathématiques en ramenant un problème à ce qui était humainement faisable et surtout humainement appréhendable, faute de quoi le calcul ne se faisait tout simplement pas. Du coup, soit le problème était très simple et on en profitait pour explorer la théorie un peu plus loin, soit il était très compliqué en soi et là, on le ramenait à une approximation plus abordable, rendant un résultat approximatif humainement acceptable lui-aussi. C'est très bien comme cela mais l'esprit humain doit-il forcément être la référence en matière de complexité de calcul ?

Quand on fait de la thermodynamique, par exemple, on ne s'amuse pas à calculer l'interaction de chacune des particules avec la totalité de ses voisines. Par contre, quand on fait de la météo aujourd'hui, il est utile de pouvoir collecter et traiter rapidement une multitude de données simples pour obtenir un résultat précis. Ça n'aurait jamais été possible sur papier. On a donc aujourd'hui admis l'utilité de traiter un nombre astronomique de petites données. Traiter une petite quantité de nombres astronomiques l'est tout autant à mon avis.

PS: et utiliser des logs, c'est pas possible ???

Justement, dans le cas de « 10¹ ⁰⁰⁰ ⁰⁰⁰ ⁰⁰⁰ », le logarithme binaire de ce nombre dépasse les 32 bits ! :-) Il faut donc commencer à envisager un système pour le prendre en compte. Alors effectivement, il tient toujours dans un double. Mais justement, moi j'ai longtemps été « en guerre » contre les gens qui utilisaient systématiquement « double » plutôt que « float » dans leurs programmes, pour les mêmes raisons que toi.

Mais même sans aller jusque là, il y aura bien un moment où tous les calculs symboliques étant résolus, il faudra déterminer la valeur de ce log. Et le calcul du logarithme — au moins pour les logarithmes à base entière, comme log₁₀ — est justement l'exemple-type de calcul purement arithmétique mais qui réclame une quantité de nombres qui explose très rapidement : si je veux déterminer le logarithme décimal d'un nombre, même entier pour simplifier la chose, je dois l'encadrer entre 10ⁿ et 10ⁿ⁺¹, puis le diviser par 10ⁿ, c'est qui est facile : on déplace la virgule et on conserve exactement le même nombre de chiffres initiaux, puis à l'élever à la puissance 10. C'est très simple aussi en soi, surtout si on fait une exponentiation rapide du style « x² = x × x ; x⁴ = x² × x² ; x⁵ = x⁴ × x ; x¹⁰ = x⁵ × x⁵ » ;

Donc, quand on utilise le logarithme de sa base de travail (le décimal, la plupart du temps), il est donc techniquement faisable d'obtenir un log parfaitement exact jusqu'à une précision arbitrairement donnée puisqu'il ne s'agira toujours que de faire des multiplications et des décalages de virgule et que leur développement décimal sera donc toujours fini. Par contre, comme on se fait suer à calculer une table justement pour s'épargner de fastidieux calculs par la suite, le logarithme a intérêt à être le plus exact possible.

Essayez de calculer simplement log₁₀(60), au hasard, jusqu'à la septième décimale, sans faire d'approximation, et regardez combien de chiffres atteignent vos opérandes à partir de la troisième décimale.

Autre exemple, le développement décimal des inverses des nombres premiers, ou de tout nombre rationnel en général : http://www.developpez.net/forums/d13...nombre-premier

On est bien loin de la crypto, et cela reste un cas il est typiquement très confortable de disposer de formats à largeur arbitraire.

Je n'ai pas vraiment d'explication, mais comme je l'ai dit dans le post où je m'autocitais, écrire la taille de l'Univers en angstrom ne prend QUE 24 décimales, et en fait la précision de la mesure la ramène à 4 ou 6 au max.. Je ne vois pas très bien quoi dans la vie et les calculs en général peut nécessiter 40 ou 60 décimales - et avoir un sens ... En général une précision relative du milliardième est bien le grand maximum, et souvent du millième.. Mais du milliardième de milliardième ??? (avoir un milliard 1/2 d'euros, on n'arrondi pas à l'euro près, hein ?)

C'est vrai mais c'est un exemple qu'il faut savoir abandonner parce qu'il introduit justement le biais inverse. Si on suit ce raisonnement, même le PPM (donc une précision en décimal à six chiffres) est un rapport inutilement précis : ça correspondrait à un écart d'un mètre sur la distance Calais-Perpignan !

Par contre, 1 PPM, c'est également le rapport qu'il y a entre 1 cm³ et 1 m³, soit à peu près le volume d'un dé à coudre dans une petite cuve d'eau. Retrouver un dé à coudre dans un tel réservoir est à la portée de tout le monde et en matière de toxicologie, par exemple, c'est largement suffisant pour le contaminer.

Alors certes, on peut exprimer cela avec des ordres de grandeur, donc avec un logarithme qui tient sur les doigts d'une main mais ce n'est pas l'objet : la pertinence d'une précision dépend du contexte et de certains facteurs parmi lesquels la multiplication du nombre de dimensions et surtout le temps ! les erreurs qui se cumulent sur une longue durée peuvent être catastrophiques.

Enfin, quand on est à l'école primaire, on apprend justement à faire de l'arithmétique, donc des calculs sur des nombres de taille arbitraire. Autant je peux admettre qu'un physicien dont les ordinateurs ne sont pas le métier doive savoir s'en tenir à des formats à la précision déjà très généreuse, autant je pense qu'il est vital pour un informaticien de savoir efficacement manipuler les données de sa machine.

[souviron34]

Cela signifie que l'on a toujours pris l'habitude de pratiquer ces mathématiques en ramenant un problème à ce qui était humainement faisable et surtout humainement appréhendable,

Ce n'est pas exactement ce que je dis :

ce que je dis c'est que la signification n'en est pas une lorsquon atteint une certaine échelle..

Quand on fait de la thermodynamique, par exemple, on ne s'amuse pas à calculer l'interaction de chacune des particules avec la totalité de ses voisines.
Par contre, quand on fait de la météo aujourd'hui, il est utile de pouvoir collecter et traiter rapidement une multitude de données simples pour obtenir un résultat précis. Ça n'aurait jamais été possible sur papier. On a donc aujourd'hui admis l'utilité de traiter un nombre astronomique de petites données. Traiter une petite quantité de nombres astronomiques l'est tout autant à mon avis.

Si, on peut... En astrophysique, les calculs de simulation de collisions de galaxies se font de cette manière-là avec 2 ou 3 galaxies à 1, 10, ou 100 millions d'étoiles...

MAis là tu parles du nombre de données, pas du nombre représenté par ces données...

Donc, quand on utilise le logarithme de sa base de travail (le décimal, la plupart du temps), il est donc techniquement faisable d'obtenir un log parfaitement exact jusqu'à une précision arbitrairement donnée puisqu'il ne s'agira toujours que de faire des multiplications et des décalages de virgule et que leur développement décimal sera donc toujours fini. Par contre, comme on se fait suer à calculer une table justement pour s'épargner de fastidieux calculs par la suite, le logarithme a intérêt à être le plus exact possible.

Sauf que justement on a calculé ce log parce que l'échelle initiale était trop grande...

On a donc l'illusion que l'on a de la précision, précision qui en fait a été perdue.. C'est ce dont je parlais avec la Masse de la Terre... Que tu n'utilises qu'une échelle log où ton max sera 24, avoir 500 décimales sur ce log ne changera rien au fait que , ré-exponentié, la précision ne sera que de 10^21, et donc seulement 3 décimales seront nécessaires.. Donc une plage simple de 1000... Parce que ré-exponentié, ton log à 500 décimales aura la même valeur, puisqu'il sera tronqué, que si il avait été calculé seulement avec 5 ou 6...

Autre exemple, le développement décimal des inverses des nombres premiers, ou de tout nombre rationnel en général : http://www.developpez.net/forums/d13...nombre-premier

On est bien loin de la crypto, et cela reste un cas il est typiquement très confortable de disposer de formats à largeur arbitraire.

Voir ce que dit Wiki..

"Esprit ludique et de compétition pour publication"..

Je l'admet, mais je vois trop de posts sur ce sujet pour croire que tous les mathématiciens des équipes mondiales travaillant sur le sujet ont pris des stagiaires francophones posant des questions sur DVP

Alors certes, on peut exprimer cela avec des ordres de grandeur, donc avec un logarithme qui tient sur les doigts d'une main mais ce n'est pas l'objet : la pertinence d'une précision dépend du contexte et de certains facteurs parmi lesquels la multiplication du nombre de dimensions et surtout le temps ! les erreurs qui se cumulent sur une longue durée peuvent être catastrophiques.

Encore une fois, tu cites toi-même la limitation : que tu aies X dimensions, que la pertinence dépende du contexte, et que la précision est relative..

Ce n'est pas en ayant par exemple une échelle de temps à la micro-seconde que tu décriras l'évolution de le Terre depuis sa naissance..

Autant je peux admettre qu'un physicien dont les ordinateurs ne sont pas le métier doive savoir s'en tenir à des formats à la précision déjà très généreuse, autant je pense qu'il est vital pour un informaticien de savoir efficacement manipuler les données de sa machine.

A condition qu'il connaisse les limites.. Les exemples que j'ai donné sur les GPS, et sur d'autres calculs (il y a eu sur ce forum un post sur les calculs aéronautiques des ailes d'avion) montrent que ces exercices / pratiques font perdre la notion de précision réelle, et d'utilité...

Qu'un infomaticien stocke dans une BD une donnée GPS à 14 ou 17 décimales est tout simplement une aberration.. Quand en plus il la relit et ne l'arrondi pas à la préicison initiale, il propage des erreurs... Multiplié par le nombre d'opérations, cela génère des erreurs énormes... (j'ai eu le cas de lignes droites (une piste de saut à ski) devenant pire qu'un ruban de Moebius, simplement à cause de ça).

Qui peuvent nécessiter un travail énorme de la part d'autres utilisateurs (correction d'intersections, vérifications des formes, etc).

Tout ça parce que l'infrmaticien connaissait la précision de sa machine, mais n'avait pas pris en compte celle de la donnée qu'il devait stocker..


C'est pour ça que je proteste régulièrement : cela ne doit pas se faire au détriment de l'ordre de grandeur et de la réalité..

Quand tu cites les PPM, on peut même aller jusqu'aux PPMM... Il n'empêche que ton unité de mesure est le PPM. Par 1 ou 100000..

De manière générale, je ne pexu que réaffirmer : en dehors de la crypto et des personnes/équipes interess"es par l'aspect ludique ou de compétietion sur la publication, utiliser des calculs soi-disant exacts est SANS AUCUNE SIGNIFICATION....

Si je me met à te demander ton CV à la micro-seconde sur ta vie professionnelle, tu vas m'envoyer balader. A juste titre.. C'est exactemnt la même chose : toute quantité à son échelle, qui peut différer suivant l'usage, mais qui ne nécessite que peu de décimales (en tous cas suffisamment peu pour rentrer dans l'infirmatique "normale"), par construction...

On peut avoir l'illusion d'un calcul exact, mais cette exactitude est contrebalancée par l'incertitude sur la valeur...


Dans le post que tu cites, je n'avais pas répondu à ton dernier post :

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.

Là encore tu mélanges un peu il me semble... La monnaie de se fbrique ni ne s'établit pas, physiquement à moins de 1 centime.. Qu'on y adjoigne 3 décimales de plus (pour tenir compte des .333 ou autres) ne changera rien au fait que l'unité la plus basse - la précision la plus basse de la monnaie - est le centime...

Stocker une somme à 10^-9 centime est illusoire...

Quant aux calculs "en suite", c'est équivalent.... Comme je l'avais dit dans la discussion sur les ailes d'avions, si ton échelle est le mm, tu as le micron à 10^-3. En utilisant des doubles, tu as droit à 2^13 opérations par point avant de perdre la précision du micron...

Bref, si ton échelle est bonne, les imprécisions de calculs ne sont pas à prendre en compte....

Quant au GPS, j'ai donné le lien de la NASA...

[Obsidian]

Si, on peut... En astrophysique, les calculs de simulation de collisions de galaxies se font de cette manière-là avec 2 ou 3 galaxies à 1, 10, ou 100 millions d'étoiles...

Oui, mais pas sur papier. Pas avec 100 millions d'étoiles.

MAis là tu parles du nombre de données, pas du nombre représenté par ces données...

Et j'ai surtout ajouté : « On a donc aujourd'hui admis l'utilité de traiter un nombre astronomique de petites données. Traiter une petite quantité de nombres astronomiques l'est tout autant à mon avis. ».

Sauf que justement on a calculé ce log parce que l'échelle initiale était trop grande...

C'est le « on a » qui est important. Comment ces logarithmes ont été calculés, par qui et avec combien de chiffres dans leurs calculs ? Les ordinateurs n'utilisent pas les tables de Neper originales pour les déterminer. Ils le font à la volée avec une précision arbitraire parce que c'est simple à faire et qu'itérer sur des grands nombres est précisément le rôle d'un ordinateur. Plus précisément, il sert à le faire à la place de l'homme.

Écrire la calculatrice qui trône sur le bureau de ton O.S. préféré est une tâche importante qui, pourtant, est très éloignée de la cryptographie.

On a donc l'illusion que l'on a de la précision, précision qui en fait a été perdue.. C'est ce dont je parlais avec la Masse de la Terre... Que tu n'utilises qu'une échelle log où ton max sera 24, avoir 500 décimales sur ce log ne changera rien au fait que , ré-exponentié, la précision ne sera que de 10^21, et donc seulement 3 décimales seront nécessaires.. Donc une plage simple de 1000... Parce que ré-exponentié, ton log à 500 décimales aura la même valeur, puisqu'il sera tronqué, que si il avait été calculé seulement avec 5 ou 6...

On est bien d'accord, sauf que seules 3 décimales sont nécessaires justement parce qu'on a perdu de la précision, ce qui n'est pas forcément souhaitable. C'est précisément parce que ces logarithmes divergent facilement quand ils sont ré-exponentiés qu'il est important qu'ils soient précis au départ.

Encore une fois, tu cites toi-même la limitation : que tu aies X dimensions, que la pertinence dépende du contexte, et que la précision est relative..

Et on n'a pas dit le contraire.

Ce n'est pas en ayant par exemple une échelle de temps à la micro-seconde que tu décriras l'évolution de le Terre depuis sa naissance..

Même problème qu'au départ. Il s'agit d'une échelle linéaire.

A condition qu'il connaisse les limites.. Les exemples que j'ai donné sur les GPS, et sur d'autres calculs (il y a eu sur ce forum un post sur les calculs aéronautiques des ailes d'avion) montrent que ces exercices / pratiques font perdre la notion de précision réelle, et d'utilité...

C'est normal dans une certaine mesure et, effectivement, il faut ramener tranquillement les gens à la réalité dans ce cas.

Qu'un infomaticien stocke dans une BD une donnée GPS à 14 ou 17 décimales est tout simplement une aberration.. Quand en plus il la relit et ne l'arrondi pas à la préicison initiale, il propage des erreurs... Multiplié par le nombre d'opérations, cela génère des erreurs énormes...

Oui, mais c'est le même argument que j'utilise en faveur des grands chiffres : le cumul des imprécisions.

Dans ce cas précis, cela devient une troncature et il est important, surtout en cas d'exponentiations successives, que ces erreurs ou ces arrondis se compensent mutuellement.

(j'ai eu le cas de lignes droites (une piste de saut à ski) devenant pire qu'un ruban de Moebius, simplement à cause de ça).

Sur le plan sportif, ça peut être intéressant ! :-)

Tout ça parce que l'infrmaticien connaissait la précision de sa machine, mais n'avait pas pris en compte celle de la donnée qu'il devait stocker..

Ça, c'est un vrai problème. Tout le monde colle du double à toutes les sauces même pour les indices de boucle, surtout en Java où ça devient une maladie. À ce stade, il est bon de reprendre l'éditeur hexadécimal et d'aller leur montrer en mémoire ce que représentent huit octets successifs à chaque fois.

Quand tu cites les PPM, on peut même aller jusqu'aux PPMM... Il n'empêche que ton unité de mesure est le PPM. Par 1 ou 100000..

Non, justement : je parlais bien de précision dans ce cas précis et montrait qu'en prenant systématiquement l'exemple des distances (qui est donc le mauvais, à mon avis), on arrive à montrer que même le PPM est inutilement précis. Contexte, toujours.

De manière générale, je ne pexu que réaffirmer : en dehors de la crypto et des personnes/équipes interess"es par l'aspect ludique ou de compétietion sur la publication, utiliser des calculs soi-disant exacts est SANS AUCUNE SIGNIFICATION....

On avait parlé du CRC, que tu as aussitôt classé dans la cryptologie. Admettons, mais alors la crypto devient vraiment très vaste à ce stade.

On a aussi cité un post qui voulait étudier le développement décimal périodique des inverses des nombres premiers, ou celui de la calculatrice du bureau d'un système d'exploitation. Dans le premier de ces deux cas, c'est quand même dommage d'utiliser un tableau ou une liste chaînée pour coder une séquence que l'on pourrait enregistrer avec « x = 10x + n » et imprimer à l'écran avec les fonctions habituelles. Il existe justement des trucs comme BigDecimal en Java pour ce genre de cas.

Là encore tu mélanges un peu il me semble... La monnaie de se fbrique ni ne s'établit pas, physiquement à moins de 1 centime.. Qu'on y adjoigne 3 décimales de plus (pour tenir compte des .333 ou autres) ne changera rien au fait que l'unité la plus basse - la précision la plus basse de la monnaie - est le centime...

Ce que j'entendais par là, c'est que le calcul doit être exact au delà de la précision de référence si tu veux qu'il soit parfaitement exact en fin de processus sur cette précision.

De toutes façons, on est d'accord sur le fond. Ce que j'entends en fait se résume en quelques points simples :

• Il est important de vérifier si un tel besoin ne cache pas, en réalité, une erreur de conception, mais que :
• On évite de recourir aux grands nombres principalement pour raisons historiques : parce qu'ils sont inutilement fastidieux à calculer et à maintenir. Le côté fastidieux disparaissant avec les ordinateurs ;
• Qu'à partir du moment où on touche de près ou de loin à l'arithmétique, ils deviennent très utiles ;
• Qu'un physicien peut se passer d'avoir à les manipuler, mais qu'un informaticien doit savoir le faire ;
• Qu'il n'est pas forcément plus intéressant de changer de repère en utilisant des log ou autres moyens de représentation s'ils ne sont pas moins coûteux en ressources en temps de calcul de rajouter des chiffres si nécessaires, surtout si le domaine exploré reste proche des limites originales, pour éviter les débordements de type, même si en matière de nombres entiers, il est difficile aujourd'hui de dépasser 2⁶⁴.

[souviron34]

On est bien d'accord, sauf que seules 3 décimales sont nécessaires justement parce qu'on a perdu de la précision, ce qui n'est pas forcément souhaitable. C'est précisément parce que ces logarithmes divergent facilement quand ils sont ré-exponentiés qu'il est important qu'ils soient précis au départ.

Sauf que , ce que visblement tu n'arrives à comprendre, ou je m'exprime mal, c'est que la QUANTITE dont on prend le log est imprécise.. DONC que le log d'une valeur imprécise soit précis, ça ne veut rien dire de plus...

Oui, mais c'est le même argument que j'utilise en faveur des grands chiffres : le cumul des imprécisions.

Voir plus haut : avoir 200 décimales sur un chiffre obtenu avec une donnée à 3 décimales ne t'avancera en rien.. ça te donne l'illusion que c'est plus précis, mais ça ne l'est pas..

Dans ce cas précis, cela devient une troncature et il est important, surtout en cas d'exponentiations successives, que ces erreurs ou ces arrondis se compensent mutuellement.

Encore une fois, c'est une précision IMAGINAIRE...

Que tu calcules avec 10000 décimales n'y changera rien, même en faisant 10000 fois l'opération...

Ça, c'est un vrai problème. Tout le monde colle du double à toutes les sauces même pour les indices de boucle,

ça faut être franchement con, mais j'ai jamais vu ça... Faut croire que t'es entouré de zombies, alors

Non, justement : je parlais bien de précision dans ce cas précis et montrait qu'en prenant systématiquement l'exemple des distances (qui est donc le mauvais, à mon avis), on arrive à montrer que même le PPM est inutilement précis. Contexte, toujours.

Je ne l'ai pas compris comme ça.. Pour moi, une fois que tu as mis en PPM (ce que j'indiquais plus hait comme étant une échelle "normale", 10-6), en dehors d'ajouter 2 chiffres après la virgule ça n'a aucun sens d'afficher (et de calculer) des "PPM de PPM"...

On a aussi cité un post qui voulait étudier le développement décimal périodique des inverses des nombres premiers,
ou celui de la calculatrice du bureau d'un système d'exploitation.

Encore une fois, le premier exemple : A QUOI SERT-IL ??????

Comme le dit Wiki, aspect ludique et de compétition : forcément temporare, et forcément, toujours, et de manière certaine, incomplet...

Ce que j'entendais par là, c'est que le calcul doit être exact au delà de la précision de référence si tu veux qu'il soit parfaitement exact en fin de processus sur cette précision.

Encore une fois, je conteste cette position : comment un calcul peut-il être EXACT avec précision PLUS FORTE que celle de la donnée entrée ????

Que tu additionnes 500 000 fois des sommes, ces sommes (d'argent) ne sont chacune précise qu'au centime près... Que tu rajoutes 30 000 décimales n'y changera rien..

Et si tu fais une division, la seule chose que tu peux espérer, c'est l'arrondi correct.... Il est illusoire - mathématiquement - d'espérer avoir 8 décimales SIGNFICATIVES sur des nombres qui n'en ont que 2... Alors tu peux faire du virtuel...

Mais faire 1 euro / 3 ne t'avanceras de toutes façons qu'à 0.33 (et tu peux garder un 3 si tu veux pour la première opération suivante, mais la propagation de l'incertitude est INSTANTANEE , pas à la fin... : si tu fais 1000 opérations : addtionner 2 nombres à 10-2 d'incertitude réelle t'améneras toujours à 10-2 au premier coup... Ce n'est pas en ayant 30 décimales sur ton tiers que tu gagneras en précision... Tu ne gagnes strictement rien, sauf du virtuel... car la fraction de centime n'existe pas... Donc tu arrondis TOUJOURS à 10^-2.... Que tu fasses 0 ou 500 000 opérations.... Entre chacune de ces opérations la valeur DEVRAIT être arrondie, sinon c'est de l'argent virtuel - et donc une opération irréelle, et donc fausse...

De toutes façons, on est d'accord sur le fond. Ce que j'entends en fait se résume en quelques points simples :

Je ne crois pas tout à fait qu'on soit d'accord sur le fond

• On évite de recourir aux grands nombres principalement pour raisons historiques : parce qu'ils sont inutilement fastidieux à calculer et à maintenir. Le côté fastidieux disparaissant avec les ordinateurs ;

Je ne suis pas d'accord... On évite de recourir aux grands nombres CAR ILS NE SONT D'AUCUNE UTILITE : soit ils sont précis et ponctuels (comme les nombres premiers), et alors ils ne peuvent servir QUE à des listes, soit ils sont des nombres réels quelconques, et LE NOMBRE DE CHIFFRES SIGNFICATIFS EST FAIBLE.......

Avoir 500 000 000 000 000 000 000 1 est absurde et n'a stictement aucun sens dans AUCUN domaine....

• Qu'à partir du moment où on touche de près ou de loin à l'arithmétique, ils deviennent très utiles ;

Encore une fois, pas d'accord... Quelle arithmétique ??? Celle des concours de geeks - ou de chercheurs - qui veulent publier plus que le voisin, ou la vraie arithmétique ????

Dans la vraie arithmétique, on s'en tamponne comme de l'an 40, de la valeur numérique.... Et dans l'informatique industrielle (méthodes de convergence, numériques, etc) la précision des phénomènes/mesures/coeffs limite la précision...

Alors il y a la crypto - et si tu veux les CRC.. Très très très très petit domaine, et pas des maths - ni de l'arithmétique - pure.

• Qu'un physicien peut se passer d'avoir à les manipuler, mais qu'un informaticien doit savoir le faire ;

Je ne peux pax être d'accord... Un informaticen fait des programmes.. L'utilité des grands nombres est extrêmement restreinte. Pourquoi quelqu'un qui n'est pas du domane devrait-il les connaitre spécifiquement ??

Tu passes ton permis, tu conduis une voiture. Est-ce que ça veut dire que quand tu passes le permis tu devrais savoir conduuire un semi 35 tonnes 18 essieux sur une route de montagne enneigée à 14% par temps de brouillard ????

Un infomaticien doit apprendre à ne pas utiliser le Charles de Gaulle pour faire décoller un CESSNA ou un ULM... Il doit donc strictement avoir la même base qu'un physicien, un chimiste, ou n'importe qui: le bon sens pour chosiir l'échelle et l'outil adapté...

• Qu'il n'est pas forcément plus intéressant de changer de repère en utilisant des log ou autres moyens de représentation s'ils ne sont pas moins coûteux en ressources en temps de calcul de rajouter des chiffres si nécessaires, surtout si le domaine exploré reste proche des limites originales, pour éviter les débordements de type, même si en matière de nombres entiers, il est difficile aujourd'hui de dépasser 2⁶⁴.

Je me fous des logs... Un changement d'échelle est TOUJOURS nécessaire pour manpuler la bonne échelle, sinon les décimales - ou les unités - n'auront aucuns sens ..... QUELLE QUE SOIT la puissance informatique disponible..




Le fond de notre désaccord c'est que tu penses que la précision informatique EST une précision réelle... C'est FAUX... : suivant qu'on utilise tel ou tel algo (cablé ou non) , tel ou tel processeur, on n'aura pas le même résultat... Mais, fondamentalement, l'informatique traite - hors cas particuliers comme la recherche des nombres premiers - des nombres représentants des élements du monde (modélisés ou non) et/ou devant être lus/interprétés/compris par des humains (et même des machines).

La "granularité" de l'humain, d'une monnaie, d'une machine-outil, des données qui ENTRENT et SORTENT du soft LIMITENT la précision...

Les décimales "artificielles" n'ont AUCUN sens, elles sont purement virtuelles..

Pour expliquer, je reviens sur l'exemple d'aile d'avion que j'avais eu ailleurs dans un aure thread sur ce forum: l'argument avancé était de dire que puisqu'on avait besoin d'une précision du micron sur une orientation de facette, que puisque qu'on avait plus de 1000 opérations par point, ALORS il était nécessaire d'utiliser des grands nombres puisque la limite des doubles était dépassée... Ben non... Si tu prends l'unité comme le mm et non pas le mètre, le micron relève du 10^-3, et en ayant des doubles tu as le loisir de faire plus de 10^10 opérations par point en étant toujours en dessous du micron... Qu'on utilise 17 décimales n'empêchent pas que ton beau maillage sera mis en oeuvre par une machine qui coupera de l'acier au mieux au micron, et normaleemnt au 1/10 mm. . Basta.. Chaque point est donc au micron... Que tu te sois servi d'un point pour construire le suivant, tu as toujours cette limite.. Que donc tu utilises 18 décimales ou 500 ou 9 ne changera stirictement rien..

Tu dois donc calculer ta tolérance max (le plus petit mouvement que peut faire la machine-outil)... Et ça te donne la précision limite...

Mais ne t(y trompe pas.. Utiliser 10 ou 30 ou 500 décimales ne changera strictement rien.... Tex calculs ne seront pas "plus exacts" pour autant...

C'est je crois, le fond : il y a une illusion persistente que "l'exactitude' des décimales de la machine réprésente une exactitude du nombre , et donc du résultat : non c'est une exactitude du chiffre, de manière ex-nihilo et purement ponctuelle... l'exactitude du nombre et du résultat ne dépend que très peu de l'exactitude du chiffre, si on est à la bonne échelle et qu'on atteint au minimum la précision limite...


Ouuufffffffff.....


Ce n'est pas juste un débat philosophique, c'est un débat dans lequel, je pense, il y a vraiment une incompréhension des mécanismes de calculs et des significations des nombres et des décimales...

[Obsidian]

Sauf que , ce que visblement tu n'arrives à comprendre, ou je m'exprime mal, c'est que la QUANTITE dont on prend le log est imprécise.. DONC que le log d'une valeur imprécise soit précis, ça ne veut rien dire de plus...

On est bien d'accord encore une fois, mais tu prends systématiquement ce cas en exemple comme s'il s'agissait de quelque chose d'universel ! Tout le monde ne passe pas sa carrière à faire de la mesure physique, quand même !

Il y a une vieille blague sur les scientifiques que tu dois déjà connaître :

Question : les nombres impairs sont-ils tous premiers ?

— Le mathématicien : faux ! 9 n'est pas premier ;
— Le physicien : 1 est premier, 3 est premier, 5 est premier, 7 est premier, 9 euh… n'est pas premier, 11 est premier, 13 est premier… Bon bah aux erreurs expérimentales près, c'est bon !
— L'informaticien : 1 est premier, 3 est premier, 5 est premier, 7 est premier, 9 n'est pas premier, 9 n'est pas premier, 9 n'est pas premier, 9 n'est pas premier…

ça faut être franchement con, mais j'ai jamais vu ça... Faut croire que t'es entouré de zombies, alors

Tu n'imagines même pas ce que l'on peut voir…

Seulement, à l'usage, il y a deux catégories de personnes : d'un côté ceux qui ne veulent pas être informaticiens (c'est leur droit) et qui ne touchent à la programmation que comme spécialisation supplémentaire. Ceux-là, aujourd'hui, s'orientent surtout vers le Java. Et d'autre part, il y a les gens qui font d'énormes erreurs simplement parce qu'ils débutent. Là, en général, on leur montre la voie une seule fois et ils y restent d'eux-mêmes toute leur carrière.

Encore une fois, le premier exemple : A QUOI SERT-IL ??????

Il se trouve que ce n'est pas un cas inventé pour en débattre mais un post véritable et une vraie question de la part du demandeur. « À quoi ça sert » est hors sujet. La vraie question ici est « comment t'y prendrais-tu pour obtenir le résultat » ?

Après, tu peux arguer qu'il ne s'agit que de cas marginaux qui ne justifient pas la mise en place de classes dédiées mais pourquoi s'en priver quand on en a besoin ?

Encore une fois, je conteste cette position : comment un calcul peut-il être EXACT avec précision PLUS FORTE que celle de la donnée entrée ????

Ah ben dans le cas du développement décimal ci-dessus, la question ne pose pas ! la précision est forcément absolue puisque la donnée initiale n'est pas une mesure mais une définition mathématique. Même si le développement est infini, il s'agit bien d'écrire un algo qui le perpétue jusqu'au bon plaisir de l'utilisateur. Et il se trouve que cet algo est le même que sur papier.

Mais faire 1 euro / 3 ne t'avanceras de toutes façons qu'à 0.33 (et tu peux garder un 3 si tu veux pour la première opération suivante, mais la propagation de l'incertitude est INSTANTANEE , pas à la fin...

Encore une fois, ce n'est pas du tout l'objet de la discussion. Personne ici ne cherche à calculer la valeur d'un tiers d'euro et il n'y a pas du tout non plus d'incertitude sur 1÷3. Ça donne forcément « 0,333333… » jusqu'à l'infini. Dans l'exemple précédent, le demandeur cherche à connaître l'emplacement et la longueur de la séquence de chiffres qui se répète ensuite (en l'occurence, c'est un seul chiffre).

Voici encore un exemple trivial mais qui, pour le coup, est utilisé en permanence par nos ordinateurs lorsque l'on dialogue avec eux : la conversion de base, et typiquement le décimal vers le binaire et réciproquement. Quand tu convertis un unsigned long long binaire, donc 2⁶⁴ vers du décimal affichable à l'écran, tu obtiens 80 bits en BCD ou 20 caractères en ASCII, soit 160 bits. Il s'agit donc typiquement de faire de l'arithmétique sur des formats qui dépassent la longueur des types natifs standard.

Ce n'est pas du tout une question anodine parce qu'elle est récurrente sur les forums et qu'on s'aperçoit que même lorsqu'il ne s'agit que de passer d'une base à l'autre, très peu de gens pensent d'emblée à itérer sur « modulo du nombre par la base puis division entière par la base ».

Or, réécrire printf() ou strtol(), c'est bien plus qu'un cas d'école : c'est à la fois simple et fondamental, et tout le monde ne travaille pas sur PC. Programmer un micro-contrôleur, par exemple, nécessite de savoir comment ça marche.

: si tu fais 1000 opérations : addtionner 2 nombres à 10-2 d'incertitude réelle t'améneras toujours à 10-2 au premier coup... Ce n'est pas en ayant 30 décimales sur ton tiers que tu gagneras en précision...

Personne n'a dit le contraire (pour peu que les incertitudes soient uniformément réparties et qu'elles se compensent).

Je ne crois pas tout à fait qu'on soit d'accord sur le fond

Bien sûr que si. Tu nous expliques depuis le début que — en pratique — les cas où on a réellement besoin de grands nombres sont rares et qu'il faut donc résister à la tentation d'y recourir dès le départ, avant même de s'être penché sur son problème. Personne n'a dit le contraire, encore une fois.

Ce que l'on a dit en revanche, c'est que ce n'est pas la peine de s'en passer et encore moins d'en être privés lorsqu'ils sont à la fois simples à mettre en place et qu'ils facilitent les calculs. Seulement, à chaque fois qu'on présente un exemple, tu nous réponds « oui mais ça, on s'en fiche » ou « ça ne sert rien ». C'est peut-être vrai dans ton domaine, ça ne l'est pas systématiquement. Et tout le monde n'est pas « utilisateur final » non plus, surtout ici.

Calculer Pi, c'est intéressant. Calculer un logarithme jusqu'à une précision arbitraire RÉCLAMÉE par l'utilisateur, c'est intéressant (et c'est surtout intéressant de savoir le faire), calculer une fonction de conversion de base, c'est intéressant.

Je ne suis pas d'accord... On évite de recourir aux grands nombres CAR ILS NE SONT D'AUCUNE UTILITE : soit ils sont précis et ponctuels (comme les nombres premiers), et alors ils ne peuvent servir QUE à des listes

Ok. Qui calcule ces listes et comment les stocke-t-on ? Parfois, c'est quand même plus intéressant de les recalculer.

Encore une fois, pas d'accord... Quelle arithmétique ??? Celle des concours de geeks - ou de chercheurs - qui veulent publier plus que le voisin, ou la vraie arithmétique ????

L'arithmétique des concours de geeks, ce n'est pas de la vraie arithmétique ?

Dans la vraie arithmétique, on s'en tamponne comme de l'an 40, de la valeur numérique.... Et dans l'informatique industrielle (méthodes de convergence, numériques, etc) la précision des phénomènes/mesures/coeffs limite la précision...

Mais n'oublie pas que, bien souvent, quand tu passes une donnée de précision fixe à une fonction et que celle-ci te renvoie un résultat à la même précision (et au même format), celle-ci est obligée de travailler sur un format plus grand et de tronquer le résultat avant de te le renvoyer. Et partir du moment ou tu dépasses le format natif standard, travailler sur deux éléments ou travailler sur mille, c'est le même boulot.

Je ne peux pax être d'accord... Un informaticen fait des programmes.. L'utilité des grands nombres est extrêmement restreinte. Pourquoi quelqu'un qui n'est pas du domane devrait-il les connaitre spécifiquement ??

C'est là que nos avis divergent, à mon avis : un informaticien n'est pas un pupitreur qui se contente de nourrir une machine tombée du ciel avec des données pré-machées par les physiciens et pour leur compte. C'était peut-être vrai dans un premier temps avec les batchs et lorsque les premiers ordinateurs centralisés ont remplacé les bureaux de calcul, mais même là, il a bien fallu que quelqu'un les conçoive et les fabrique.

Pour moi, l'informaticien est précisément la personne qui doit — sinon concevoir — être au fait du fonctionnement de sa machine.

C'est une question que j'avais posé à un élève ingénieur en informatique à qui les cours d'architecture des ordinateurs et d'électronique numériques ne parlaient pas et qui considérait de façon assez ostentatoire que ce n'était pas leur rôle d'étudier ces choses-là. Je lui avais demandé « c'est le métier de qui, alors, de concevoir les ordinateurs, si ce n'est celui des ingénieurs en informatique ? ». Il m'avait répondu pudiquement « — Quelqu'un au dessus de moi… » en souriant.

À ce stade, des gens au-dessus de lui, il en reste mais pas beaucoup.

Tu passes ton permis, tu conduis une voiture. Est-ce que ça veut dire que quand tu passes le permis tu devrais savoir conduuire un semi 35 tonnes 18 essieux sur une route de montagne enneigée à 14% par temps de brouillard ????

Non, et ce n'est pas l'objet non plus ici. Mais on t'apprend quand même comment fonctionne en gros un moteur à explosion et une boîte de vitesse, même si tu ne les dépannes pas toi-même. Manipuler des chiffres comme on le fait à l'école, c'est plutôt de cet ordre-là.

Un infomaticien doit apprendre à ne pas utiliser le Charles de Gaulle pour faire décoller un CESSNA ou un ULM... Il doit donc strictement avoir la même base qu'un physicien, un chimiste, ou n'importe qui: le bon sens pour chosiir l'échelle et l'outil adapté...

L'aviation, c'est typiquement le mauvais exemple aussi, puisqu'on n'y passe pas un permis de voler mais un authentique brevet de pilote, qui demande d'avoir des connaissances et une perception globale de la chose bien plus vaste que la simple exploitation de son appareil.

Les formations de pilotes de ligne, elles, sont pour ainsi dire de vraies formations d'officier.

Et puisque tu parles du Charles de Gaulle, les pilotes de chasse s'y posent mais le navire est exploité par des marins. Pas par des pilotes. Ce que tu nous dis en l'occurrence, c'est à peu près : « tout ce qui m'intéresse, c'est : est-ce que le Charles de Gaulle peut voler ? ».

D'autre part, toute ta réflexion part du principe que soit tu utilises des logiciels de calcul, soit tu utilises des langages qui proposent des le départ des types suffisamment larges pour les besoins quotidiens des scientifiques. Mon premier ordinateur, lui, était un huit bit sous BASIC. Les types entiers étaient forcément des short, et les autres formats numériques étaient des nombres flottants en simple précision (32 bits) ou double précision (64 bits) comme aujourd'hui.

Or, il n'y avait pas de FPU à l'époque et même les ordinateurs nativement 32 bits ont pris un certain temps avant de se démocratiser. Comment faisait-on alors pour effectuer les opérations en virgule flottante fondamentales sur 64 bits, si ce n'est en itérant sur les 7 octets de sa mantisse ? En plus, les multiplications pouvaient se faire à l'octet près, mais les divisions et les racines carrées, par exemple, se faisaient au niveau du bit.

Tu ne me feras pas croire qu'en physique, tu n'utilises jamais la racine carrée, par exemple. Qui est chargé d'écrire la fonction sqrt() que tu utilises et à quel niveau d'étude ou à quel rang professionnel peut-on être chargé de l'implémenter dans une machine ?

Le fond de notre désaccord c'est que tu penses que la précision informatique EST une précision réelle... C'est FAUX...

Mais bien sûr que non. Où va tu chercher une chose pareille ? Tout le monde connaît les pièges inhérents aux calculs en virgule flottante.

suivant qu'on utilise tel ou tel algo (cablé ou non) , tel ou tel processeur, on n'aura pas le même résultat...

Ça, par contre, c'est fondamental : un résultat peut être non-significatif mais il sera toujours déterministe, sur une plateforme donnée. La manière dont le calcul va être mené jusqu'au dernier bit est normalisée, que ce bit ait du sens au final ou pas.

La "granularité" de l'humain, d'une monnaie, d'une machine-outil, des données qui ENTRENT et SORTENT du soft LIMITENT la précision...

Tu te répètes ! :-)

Tout le monde ne fait pas de la mesure physique ni des mathématiques appliquées. Prend le problème à l'envers : si quelqu'un a l'envie de faire des calculs sur des chiffres très grands, alors l'ordinateur est l'outil idéal pour le faire et donc, c'est sur les forums comme les nôtres plus que partout ailleurs que tu trouveras les sujets qui en traitent.

Pour expliquer, je reviens sur l'exemple d'aile d'avion que j'avais eu ailleurs dans un aure thread sur ce forum: […] Que donc tu utilises 18 décimales ou 500 ou 9 ne changera stirictement rien..

Mais tout le monde a compris, bon sang. Tout le monde ici sait ce qu'est une précision numérique.

C'est je crois, le fond : il y a une illusion persistente que "l'exactitude' des décimales de la machine réprésente une exactitude du nombre , et donc du résultat : non c'est une exactitude du chiffre, de manière ex-nihilo et purement ponctuelle... l'exactitude du nombre et du résultat ne dépend que très peu de l'exactitude du chiffre, si on est à la bonne échelle et qu'on atteint au minimum la précision limite...

Tu nous l'a déjà dit avec l'exemple du G.P.S. : une distance au nanomètre, non seulement ne sert à rien, mais est forcément inexacte puisqu'elle est noyée dans le bruit de la mesure.

Mais il faut vraiment sortir de ce référentiel, à la fin.

Ouuufffffffff.....

Comme tu dis… :-)