Michaël a écrit 2929 commentaires

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.

Oui mais pas au même tarif si je me souviens bien
Les mêmes caractéristiques coûtaient très cher sur PC si tu voulais approcher le niveau de l'Amiga

C'est clair, en 1987 un Amiga 500+ coûtait 700 USD, avec 1 Mo de RAM, un lecteur de disquette 3 1/2, une puce motorola cadencée à plus de 7 Mhz, qui était capable de protéger les tâches, et flanqué d'une unité graphique rapide et programmable et d'une unité sonore descente. En comparaison, le Tandy 3000 HL coûtait environ 1500 USD (la numérisation de la pub est pas terrible, mais je crois arriver à bien lire!) avec une puce 286 (qui est incapable de protéger les tâches, ce qui n'est arrivé qu'avec le 386) pas d'unité sonore, une unité graphique bien inférieure à celle de l'Amiga et un lecteur 5 1/4… :) Si on ajoute la complexité de l'utilisation de MS-DOS en comparaison au Work-Bench de l'Amiga, la comparaison est douloureuse.

C'est vrai mais les inconvénients à mentionner est que les ressources nécessaires vont être plus importantes et qu'il faut probablement de surcroit utiliser un reverse proxy (comme haproxy par exemple) pour connecter les serveurs apache à l'hôte. Dans le cas décrit (avec 3 utilisateurs) c'est certainement une très bonne solution et il n'est pas très difficile de configurer haproxy pour ce cas de figure. Il faut cependant noter que cela ne se redimensionne pas très bien.

Mais de toutes façons on sort du CE2 et des soustractions (sujet du journal, vous divergez).

En fait ce qui rendrait la discussion potentiellement intéressante ce serait que tu prennes un peu de hauteur et essaie d'organiser les changements qu'il serait nécessaire de faire pour que Python puisse sortir le résultat attendu du calcul de CE2 dont tu parles puis peser les avantages et les inconvénients de ces changements. Ce serait très intéressant et il y a plein de points très différents à aborder, comme par exemple les modifications à faire dans la syntaxe du langage, dans la représentation mémoire des objets, dans l'écriture de bindings avec le C++ (un des points forts de Python est de faciliter au maximum cette écriture). Il pourrait il y avoir plein d'échanges fructueux, de problèmes à résoudre, une discussion stimulante. Mais tout ce qui tu nous donnes c'est du “vous n'êtes pas de mon avis, mon avis est bon, donc vous êtes…” Quel dommage!

Je te parle exactitude, tu me réponds affichage. C'est pénible.

Pour la machine un nombre flottant est un nombre entier fois une puissance de deux et si on veut afficher cela en base 10 il faut déterminer les chiffres à afficher… ce qui se fait avec une certaine précision!

Je reviens à ce que je dis : s'il-te-plait, donne moi un avantage du float par rapport au Decimal mis à part la perfo.

Je l'ai déjà écrit ailleurs mais apparemment cela mérite d'être répété: en calcul scientifique on ne sait en général que faire du calcul approché, et la plupart des nombres ne sont pas décimaux, ni même rationnels, on ne travaille qu'avec des nombres qui ne sont pas représentables exactement dans la machine (sauf si on se contente de leur donner un nom, mais, sans surprise, on ne sait pas faire grand chose de ce nom). Du point de vue strictement spéculatif, puisqu'on peut représenter un flottant par un décimal et les utiliser dans les calculs mais ce faisant on ne va pas très loin. Par exemple dans une simulation de type LIBOR Market Model pour simuler la “zero curve” pour les 25 prochaines années on va faire un calcul du type u[i][0] = donné initiale pour i et u[i][j+1] = whatever * exp(whatever* u[i][j] + whatever) + whatever où les divers whatever désignent tous des expressions distinctes. Quelle taille τ(x) peut bien avoir un nombre décimal x sortant d'un tel système? Mettons qu'on calcule l'exponentielle en sommant les N = 20 premiers termes de la série (ce qui est une très mauvaise façon de calculer l'exponentielle loin de zéro!), on a (Sterling) τ(n!) ∼ n log(n) et τ(xⁿ⁾ ∼ n τ(x) du coup vite fait τ(exp x) ∼ N (log(N) + τ(x)) / 2 et quand j'utilise plus de 9000 itérations (au moins un point par jour pour les 25 prochaines années) de la formule avec les whatever on se retrouve avec un terme dominant τ(final) en N log⁹⁰⁰⁰ (N) et en se souvenant qu'un gigabit c'est à peine 2⁹ octets, on voit qu'on aurait le mal plus fou à ne stocker qu'un résultat de ces itérations… mais on veut en calculer des centaines de milliers! Si on peut tout faire tenir sur 64 bits, c'est pas plus mal!

Donc pour récapituler: les nombres rationnels en machine permettent de faire de l'arithmétique exacte, mais sont lents et prennent beaucoup de place et on ne peut rien calculer d'autre que des fractions rationnelles, tandis que les floats ne savent rien calculer exactement mais sont rapides et petits.

Il existe des systèmes qui peuvent utiliser indifféremment les floats et les rationnels, comme par exemple Common Lisp (depuis au moins 1984!), Maple, etc. mais ils ne sont pas faciles à manier – ce qui est précisément l'inverse du but que tu sembles poursuivre.

Tout ça pour calculer une somme de 3 termes du CE2. Et quand je dis "tiens on pourrait utiliser un autre type que float pour représenter les litéraux par exemple" on me demande "mais pourquoi faire".

On pourrait mais ce n'est pas le choix qui a été fait par la plupart des langages, mais au lieu d'argumenter réellement en cherchant à faire une liste des avantages et des inconvénients que pourrait introduire ce changement, par exemple Python, tu te bornes à dire “regardez les floats ne marchent pas comme l'arithmétique exacte” – ce qui est loin d'être une nouveauté – et à jouer les incompris – ce qui est pénible.

Par ailleurs l'égalité est fausse. ce qui est vrai, c'est (2.0 +/-e) - (1.8 +/-e) - (0.2 +/-e) == (0.0 (+/-4*e))

Ce n'est pas la bonne égalité, en notant φ(x) = μ(x) 2^τ(x) (avec 0<= μ(x) < 1) le flottant représentant la représentation de x en virgule flottante ce qui est garanti c'est que |φ(x) - x | <= ε 2^τ(x) donc du coup (en tenant compte du fait que 2 est bien représenté!) on a plutôt un truc du genre

4(0.5) - 2(0.9 +/- ε) - (0.2 +/- ε)

pour aller plus loin dans l'estimation il faudrait considérer l'arbre effectivement utilisé pour faire le calcul!