Michaël a écrit 2935 commentaires

Mon coiffeur a une perspective différente sur cette question et une autre appréciation.

Tu résumes en une phrase la nature un peu trollesque (involontairement je pense) de ces deux journaux qui parlent des flottants: on ne peut pas faire l'économie des maths dès qu'on veut parler de la représentation des nombres en machine.

Vu la constance avec laquelle la plupart des livres de programmation généralistes passent sous silence ce type de subtilités on ne peut pas vraiment faire le reproche ce cette ignorance aux programmeurs en général. Que des programmeurs travaillent précisément dans le domaine de l'économat ou de la comptabilité d'entreprise ne semblent pas familiers avec celles-cis est plus surprenant. De façon rigolote on peut noter que la page Wikipedia pour Business Informatics ou Wirtscahftsinformatik n'a pas d'équivalent en français. :)

Exactement, et pour reprendre l'exemple de TeX, c'est parce qu'on ne calcule jamais de surface et plus généralement qu'on ne multiplie jamais entre elles deux mesures de longueurs, qu'on peut travailler avec des mesures entières. Pour l'économat on est dans une situation analogue (on ne calcule pas des euros au carré ou des litres de lait au carré) mais travailler en virgule fixe n'épargne de répondre à toutes les questions sur les arrondis, les pratiques de taux de change et de conversion d'unité – qui sont en pratique les problèmes qui “mettent dedans” les programmeurs qui ne sont pas conscients de toutes les décisions à prendre lorsqu'on programme ce genre de calculs.

Tu veux dire que dans les Éléments de Géométrie d'Euclide tu as une preuve de la trisection de l'angle ? Es-tu certain ou j'ai mal compris ?

Je suis très surpris aussi, si on considère les axiomes de Hilbert on est quand-même assez loin de pouvoir faire ce travail. Il y aurait deux approches à mon avis:

• Démonter que le cercle est rectifiable, mais pour cela je n'ai pas d'idée très maline pour majorer la somme des longueurs de cordes consécutives sur un cercle. Si on démontre que le cercle est rectifiable, on a une notion d'abscisse curviligne sur lui, ce qui nous permet de mesurer les angles et de les couper en parts égales.

  • Construire l'exponentielle complexe.

Dans un cas comme dans l'autre – si on a l'ambition de produire une démonstration rigoureuse à partir des seuls axiomes de Hilbert – il y a quand-même un travail considérable qu'on a aucune chance de retrouver ne serait-ce qu'esquissé chez les grecs. Je ne suis pas familier avec les éléments d'Euclide cependant, mais peut-être qu'ils admettent que le cercle est rectifiable? Cela serait cohérent avec la distinction faite entre les lignes droites et celles qu'on est en droit d'attendre si on croit bon de préciser que certaines lignes sont droites.

Heu, à bac+1, des étudiants plutôt forts (choisis parmi les 10% meilleurs d'une classe d'âge post bac S), sortis du bac, ne comprennent pas la définition formelle d'une limite qu'on donnait dans toutes les classes de première S il y a 20 an

Ah oui tiens, j'ai passé mon bac en 97. :D

l'existence de la mesure de Lebesgue sur R, c'est du lourd, et la mesure produit sur R2 en rajoute une couche

C'est vrai que c'est un sujet très technique, mais je pense qu'on l'apprend avec toutes cette technicité surtout parcequ'on a en vue la théorie des probabilités qu'on ne peut aborder sérieusement que si on est au point sur les notions de tribus engendrées, etc. – ou bien l'analyse fonctionnelle où l'étude des distributions demande de bien être au point sur les mesures et les théorèmes de représentation qui vont avec (au moins pour la raison que les distributions les plus célèbres comme “intégrale de a à b” et Dirac sont données par des mesures!).

Mais à Bac+1 on peut raisonnablement définir les ensembles mesurables d'un l'espace euclidien en utilisant “le critère d'Archimède”: Si la mesure extérieure et intérieure d'une partie F de l'espace euclidien coïncident (prises avec des petits pavés bien orthogonaux) et que les filtres (je dis filtre pour abréger) correspondant convergent vers la même valeur alors (définition) la partie F est mesurable et sa mesure est la valeur commune des mesures intérieure et extérieures. Cela marche raisonnablement bien pour démontrer les outils basiques (les ensembles mesurables sont une sigma-algèbre – le dénombrable vient du fait que dans une somme fini d'un nombre infini de termes, seule une quantité dénombrable de termes peuvent être non nuls) et c'est suffisamment compatible pour avec les méthodes d'intégration du style Riemann (par exemple sa version améliorée Henstock Kurzweil qui gère la convergence dominée, le théorème fondamental de l'analyse et tout et tout) pour que le lien entre intégration et calcule d'aire se démontre facilement.

Apparemment packetfence offre une solution plus complète qu'un simple pare-feu en ajoutant probablement des fonctions pour contrôler les périphériques qui peuvent ou non accéder au réseau, faire des tests (du genre est-ce que mon invité peut monitorer le traffic vers l'imprimante?) etc. À brûle-pourpoint je dirais que si les machines sont fixes et le réseau filaire c'est plutôt pas très utile, mais si tu veux pouvoir garantir à tes clients que les machines de ton entreprise où transitent leurs données ne sont pas accessibles pour tes invités WiFi (smartphone des employés, des clients, employés en jour d'essai, etc.) ou que tu as des exigences qui vont dans cette direction ce genre d'outil semble avoir une utilité.

C'est vrai qu'on peut se contenter de faire le calcul mais remarquer que la surface de quelque chose change en lorsque cette chose subit une homothétie de rapport est quand-même une remarque importante. ;) Et puis c'est vraiment un point de détail d'expression mais je pense que c'est quand-même plus satisfaisant si on se donne la peine de dire quelque part que “Pi est la surface d'un disque unité.”

À la fac on avait tout fait avec la fonction exponentielle, du genre “regardez ma belle fonction analytique” puis on déroule tout pour définir pi comme le premier zéro positif de la fonction sinus, puis on calcule le périmètre (facile) et l'aire en faisant le changement trigo adéquat dans ton intégrale. C'est très rapide mais tombe un peu du ciel. On peut aussi partir de la géométrie pour définir le sinus et cosinus comme les coordonnés d'une paramétrisation unitaire du cercle, etc. mais c'est nettement plus épique de démontrer toutes les propriétés “bien connues” de ces objets! (notamment par le bagage théorique nécessaire!)

On peut se servir de ce processus, en considérant deux cercles de même centre et en utilisant Thalès, pour prouver que le [périmètre] d'un cercle est proportionnel à son rayon; ce qui pourrait servir de définition au nombre 𝜋.

Pour le plaisir de digresser, je ne pense pas que qu'on puisse vraiment procéder de cette façon, parceque l'algorithme en question utilise déjà 𝜋 puisqu'on ne sait pas construire les polygones réguliers autrement qu'en disant que le polygone régulier à n côtés inscrit dans le cercle unité a pour sommets

ce qui utilise 𝜋 (même quand on le déguise en 360 degrés, ce n'est que grâce à la fonction exponentielle que l'on sait mesurer les angles). Si on veut se passer de l'exponentielle – si on dispose de l'exponentielle, autant définir 𝜋 en disant que c'est le premier zéro positif du sinus – en gardant l'approche par les périmètres on peut utiliser des polygones inscrits et circonscrits plus faciles à construire que les polygones réguliers (en faisant une construction récursive qui permet de calculer itérativement les périmètres).

En revanche, ce qui est très “facile” (il faut juste croire très fort que la théorie de la mesure c'est facile ;) ) est de voir que la surface d'un cercle ne dépend que du carré de son rayon: par translation on se ramène au cas où nos cercles sont de même centre et donc homothétiques de rapport le rapport des rayons. Les pavages (par des carrés) par excès ou par défaut de ces cercles se correspondent mutuellement et comme la surface d'un carré change dans une homothétie par le carré du rapport d'homothétie on peut conclure, en notant 𝜋 la surface du cercle unité, que la surface d'un cercle de rayon R est . Pour faire le lien avec le périmètre du cercle et l'exponentielle on utilise la formule de Green-Riemann (Stokes).

C'est coquin, un doigt.

Même dans le monde de la finance, tu as très rapidement besoin des floats. Le monde de la finance ne se contente pas d'additionner/soustraire des décimaux.

À ta liste on peut ajouter tout le domaine de la gestion de risque et du calcul de prix, qui sont des méthodes de calcul scientifique – voire par exemple la formule de Black-Scholes, le “LIBOR Market Model” ou “Hull-White Model” pour égratigner la surface du sujet.

c'est pour ça que ça n'est pas le cas, et c'est pourquoi quand on a besoin, dans de petits intervalles d'additionner ou soustraire des décimaux, on a conçu des librairies ad hoc.

Un exemple très connue est TeX, le logiciel typographe écrit par Knuth. Les quantités métriques manipulées par le logiciel ont un domaine bien déterminé puisqu'il s'agit d'imprimerie: de quelques mètres à pratiquement infiniment petit. De fait TeX utilise une unité de mesure minuscule en interne (le “scaled point” soit environ 1/(3*2¹⁶ mm), le 1/3 étant une approximation de la taille du point typographique américain) et procède à tous le calculs… en nombres entiers!

les maths n'étant qu'un outil purement inventé

Comme dans beaucoup de domaines du savoir, les mathématiciens s'intéressent à des notions qui permettent d'organiser et d'expliquer le savoir. Un nombre n'existe ni plus ni moins que les atomes, les particules élémentaires: ce sont des concepts qui permettent d'organiser les connaissances humaines.

On peut par ailleurs débattre beaucoup des rapports entre les mathématiques et le réel – et c'est déjà un parti pris trompeur d'opposer les deux dans la question! – mais dans une époque qui dans l'histoire de l'humanité n'a jamais autant été dépendante des outils mathématiques, considérer comme certains semblent parfois le faire que le discours mathématique est une forme d'exercice oulipien construit sur des définitions arbitraires n'est pas une attitude qui résiste à la confrontation au réel.

D'un côté comme de l'autre, il y a eu des mots un peu durs à mon avis. Mais bon, on est sur Internet… Ce qui me désole, c'est de tout ramener à des notions de mathématiques, en faisant abstraction du besoin de millions de codeurs.

Ce n'est pas la lecture que je fais des échanges précédents. Les nombres en virgule flottante sont le bon outil pour toute une classe de problèmes liés au calcul scientifique. L'analyse mathématique fournit des arguments pour évaluer les arbitrages faits (précision, vitesse, calculabilité, etc.). Et justement on ne fait pas abstraction du besoin de millions de codeurs, mais Python est un langage géneraliste, donc le modifier n'a de sens que si un ”mieux” se dégage pour toutes les applications, ce qu'aujourd'hui on ne sait pas faire: on peut ajuster beaucoup de choses mais pour gagner sur un point il faut perdre sur un autre et on ne peut pas parler de “mieux”.

Je veux un langage qui permette d'exprimer un litéral décimal. Et que ce soit la forme par défaut. Qu'il faille rajouter un "f" ou un "d" pour dire "ah non, là c'est un float/un double".

Voilà enfin une proposition concrète de comment changer un langage pour qu'il marche “mieux”! Cela soulève plein de questions:
- Comment sont représentées (dans le code) les opérations arithmétiques (+ - * /)?
- Comment sont traitées les opérations mixtes (mélangeant des floats et des nombres en arithmétiques exacte)?
- Comment se comportent les fonctions de calcul “scientifiques” si on les appelle sur un nombre rationnel?
- Comment faire la migration des anciens programmes vers le “nouveau style”?
- Comment faire la migration de compétence? (Comment garantir que tout le monde sache quel est le bon outil à utiliser – sachant que manifestement, même avant de changer la donne, c'est un problème irrésolu!)

Ce sont des questions de formes basiques mais elles sont très complexes à analyser parcequ'elles ont plein de réponses possibles et sont posées dans le contexte d;un langage et nécessitent de trouver des compromis entre la facilité d'utilisation, la cohérence avec le reste du langage, etc.

Mais de toutes manières ce que tu demandes n'est pas acceptable dans un langage généraliste parceque tu demandes de changer le comportement du langage au seul regard des besoins d'une application particulière: l'économat. De deux choses l'une: soit on trouve une solution meilleure pour tout le monde, qui arrive à arranger ceux qui font de l'économat sans rien faire perdre à ceux qui font du calcul scientifique – et toute l'ancienne discussion a donné des arguments pour montrer que c'était pour l'instant hors d'atteinte! – soit on déshabille Pierre pour habiller Paul – en foutant au passage, un gros bordel. Puisqu'une meilleure solution pour tout le monde n'existe pas aujourd'hui et que fournir beaucoup de travail pour changer l'aptitude du langage pour une application particulière au détriment d'une autre n'a pas d'intérêt du point de vue général, c'est le status quo qui prévaut.

C'est un texte intéressant, mais à mon avis il n'identifie pas clairement le problème.

As far as I can determine from my research, however, the address + length format was preferred by the majority of programming languages at the time, whereas the address + magic_marker format was used mostly in assembly programs. As the C language was a development from assembly to a portable high-level language, I have a hard time believing that Ken, Dennis, and Brian gave it no thought at all.

Ce n'est pas une bonne définition du C, qui est essentiellement un assembleur portable: un des buts est que les différents compilateurs puissent offrir de solides garanties sur la représentation mémoire des objets que l'on manipule. Ainsi, les struct permettent un adressage au bit près et de faire du padding, ce qui permet d'interfacer facilement le C et l'assembleur, et d'écrire en C ou principalement en C les pilotes pour plein de matériels. Les pointeurs sont aussi définis en pratique comme “la plus petite abstraction qui permet de parler de la mémoire de la machine sans dépendre de tel ou tel détail de telle ou telle machine.” C a été écrit pour faciliter l'écriture de systèmes d'exploitation, donc si dans le monde de l'assembleur la forme “donnée + marqueur magique” est dominante, c'est logiquement que le langage C a utilisé cette même représentation.

Le problème semblerait plutôt être que beaucoup de programmes écrits en C pourraient avantageusement être écrits dans un autre langage de programmation, qui ne soit pas un langage de bas niveau.

Il se peut que l'affichage se fasse en simple précision mais que les calculs se fassent en double – c'est une approche commune en calcul.

Wednesday a company called Bounded Floating Point announced a "breakthrough patent in processor design, which allows representation of real numbers accurate to the last digit for the first time in computer history. […]”

Traduction libre:

Mercredi une société nommée “Bounded Floating Point” a annoncé un “brevet innovant dans la conception des processeurs qui permet une représentation des nombres en virgule flottante qui soit exacte jusqu'en dernière position.”

Ce qu'il faut bien comprendre c'est que dans cette phrase, il ne s'agit pas de la représentation interne mais de la représentation affichée, c'est à dire que le système calcule toujours avec des erreurs mais garde trace de celle-ci.

La technique employée ressemble à l'arithmétique d'intervalles – modifiée avec un accumulateur de Kahan – et cette dernière est connue depuis bien plus de trois ans – elle est même évoquée dans le livre de Knuth, The Art of Computer Programming (Vol 2, 2nd edition, 4.2.2 C s'il traîne sur votre étagère) sous le nom de interval arithmetic ou range arithmetic. L'apport du brevet semble être de proposer une implémentation machine qui permettrait de réaliser les calculs directement avec des registres. Knuth conclut d'ailleurs son petit paragraphe par “The prospects for effective use of interval arithmetic look very good, however, and efforts should be made to increase its availability.”

Pour en revenir aux calculs de CE2, de type 2 - 1.8 - 0.2, l'arithmétique d'intervalle permet de connaître l'intervalle d'erreur sur le résultat, mais cela n'empêche pas l'affichage d'artefacts surprenants. Un moyen simple de transmettre la précision d'un résultat en l'affichant ou le saisissant est de pousser l'affichage ou la saisie jusqu'au premier chiffre faux, ici on aurait:

>>> 2 - 1.8 - 0.2
-0.6e-18

D'autres approches sont possibles mais cette première est probablement la plus simple. Pour les professionnels du calcul scientifique, cela fait depuis longtemps qu'ils peuvent utiliser l'arithmétique d'intervalle mais l'intérêt principal d'une implémentation “machine” ne me semble pas être la précision pour elle même. Une classe importantes d'algorithmes numériques sont les méthodes itératives issues des théorèmes de point fixe (par exemple la méthode de Newton), pour lesquels on obtient une erreur théorique bien plus faible que ce que peut prévoir l'arithmétique d'intervalle – mais ce ne sont pas les seules méthodes numériques où une analyse de l'erreur montre que l'algorithme livre un bien meilleur résultat que ce que peuvent laisser penser les majorations d'erreur pessimiste de l'arithmétique d'intervalle. L'intérêt majeur de mettre l'arithmétique d'intervalle dans le processeur serait à mon avis de pouvoir mettre un breakpoint matériel lorsque la précision se dégrade, ce qui permettrait au numéricien de détecter le plus rapidement les zones critiques de son calcul. (Aucune contrepèterie ne se cache dans cette phrase! :D)

mais c'est juste pour illustrer qu'on peut avoir des attentes différentes et qu'elles ne sont pas forcément idiotes

Dans le fil que tu cites, j'espère que personne n'a traité quelqu'un d'autre d'idiot, en tout cas pas pour l'expression d'attentes différentes. La discussion était par ailleurs largement orientée sur “à quoi sert la virgule flottante alors qu'on sait faire de l'arithmétique exact” et le fait qu'il y a plein de choses qu'on ne sait pas faire en arithmétique exacte – et qu'en plus cette arithmétique est lente.

Il y a aussi la méthode Diceware qui propose de le faire avec des dés (des vrais dés!). Des listes de mots pour cette méthode existent dans plusieurs langues et Matthieu Weber a compilé une liste en français.

Si tu m'avais dis ça il y a une semaine je t'aurais envoyé mon écran au lieu de le ramener au magasin pour qu'il le recycle!

Il y a ici des apôtres de la philosophie Unix "chaque outil fait une chose", mais c'est bon de questionner les dogmes, et le monde évolue :)

Ça n'a pas grand rapport avec la choucroute: le “chaque outil fait une chose” s'applique au programmes non interactifs qu'on peut utiliser en ligne de commande. Plutôt qu'un dogme, c'est un principe d'ingénierie logicielle: à la différence du dogme, ce principe ne sort pas de nulle-part mais formule une partie des l'expérience des créateurs de systèmes logiciels! Ce principe est d'ailleurs très répandu chez tous les programmeurs, pas les seuls programmeurs d'outils Unix! Qu'on appelle cela le “single responsability principle” en POO ou bien des formulations analogues pour les langages fonctionnels ou à procédures, il s'agit simplement de formuler l'observation empirique selon laquelle séparer un traitement complexe en fonctions élémentaires indépendantes facilite la mise au point (plus facile de tester que f calcule f(x) correctement que f(g(h(x)))) et la réutilisabilité.

Ce qui surprend c'est l'aveuglement [ici, linuxfr] à envisager que la situation puisse choquer quand on la compare à l'intuition habituelle du problème.

Le calcul est loin d'être quelque chose d'intuitif, mais bon, ce qui me chagrine le plus c'est le soi-disant aveuglement dont tu parles. Je suis loin d'avoir lu tous les commentaires dans cette discussion, mais il me semble que la surprise causée par le résultat affiché est plutôt consensuelle, ce qui coince c'est l'attitude face à cette surprise: ceux qui disent “il faudrait changer ça” n'entrent jamais dans ne serait ce qu'une esquisse de comment améliorer la situation actuelle face à ceux qui disent “la situation actuelle a ses défauts, mais pour l'instant personne ne sait faire quelque chose de vraiment mieux”.

Bon, bah c'est simple : "Madame/Monsieur, votre truc marche pas, il ne sait pas calculer (calculs habituels décimaux) aussi bien que ma calculatrice"

Si tu parles des calculatrices qui font du calcul symbolique, ce serait l'occasion de faire dévier la discussion sur le plan politique: à ma connaissance personne n'utilise ce genre d'outil hors du contexte scolaire, dès lors comment justifier l'investissement financier pour les élèves et l'effort d'apprentissage pour ce qui n'est finalement rien de plus qu'un gadget? Et plus sérieusement, ce serait l'occasion de découvrir la différence entre le calcul symbolique et le calcul approché.

Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.

C'est pas tellement une histoire de conditionnement mais plutôt le fait que le système actuel est facile à comprendre – quand on programme! – parcequ'il est prévisible: on sait facilement quand tel ou tel langage va utiliser des flottants, ou des entiers, et que dès qu'on veut s'éloigner de ces choses, il faut en gros utiliser une fonctionnalité spéciale. Ce n'est pas ce que ce soir forcément particulièrement agréable ou ébouriffant de confort mais ça marche et ça ne prend pas des décisions arbitraires. Voilà pour le status quo. Quant au status pas quo, c'est une chose de dire qu'un calcul de CE2 pourrait être traité exactement par la machine, et c'en est une autre d'essayer de délimiter les contours d'une fonctionnalité de langage généraliste qui traitent bien les problèmes de CE2 sans rien sacrifier à la simplicité, ni pour le programmeur ni pour l'implémenteur.

Merci pour cette correction, je me souvenais du contraire!

Malgré que l'embargo ne soit pas encore levé, connaît-on cet algo, et a-t-on compris la faille ?

C'est assez loin de mes préoccupations, mais si j'ai bien compris ce que j'ai lu, le principe est le suivant:

Il faut ce souvenir que les processeurs sont éloignés de la mémoire centrale et pour accéder à celle-ci rapidement, ils utilisent plusieurs niveau de cache. Le cache le plus rapide est dit de niveau L1, les autres caches sont plus lents, en enfin la mémoire centrale est la plus lente. En utilisant l'horloge interne du processeur pour estimer le nombre de cycles nécessaire à une opération de lecture, on peut deviner assez fiablement si une cellule mémoire est dans le cache L1 ou dans un autre système plus lent. L'astuce pour exploiter cette information consiste à écrire un programme du type

mov [base_kernel_memory + offset_que_je_veux_lire], bx
mov [base_user_memory + bx], ax

en s'arrangeant grâce à un saut conditionnel bien placé pour que l'approche spéculative du processeur lise la deuxième instruction et l'exécute avant de se rendre compte que l'accès à la mémoire dans la première instruction est interdit – car l'approche spéculative ne s'embrasse pas des règles de sécurité qui ne sont validées que lorsqu'on est sûr de la branche du programme qui doit être exécutée. L'état du processeur est rétablit… mais pas le cache: la vitesse à laquelle je peux lire dans la mémoire de mon processus me donne un petit indice sur la valeur de bx, alors qu'accéder à cette donnée est en principe interdit, car dans l'espace noyau.

Je crois qu'il y en a un ou deux qui sont à -7. Ce qui en soit mérite le respect.