Journal Le retour de la vengeance de la virgule flottante

Posté par Dring le 21 janvier 2018 à 23:29. Licence CC By‑SA.

Étiquettes : aucune

jan.

2018

Salut 'nal,

Alors, y'a pas longtemps on s'est étripé sur le sujet de la virgule flottante. Pour ceux qui auraient raté le journal concerné, il est là, et il portait notamment sur le fait qu'on introduise de temps en temps des erreurs (ou des approximations - selon le camp dans lequel vous êtes).

Et bien il est possible qu'à un horizon indéterminé mais réel, ce problème soit réglé ou sensiblement atténué et qu'on puisse travailler sur des nombres à virgule flottante sans erreur et sans perte majeure de performance. C'est Slashdot qui rapporte le cas, mais mentionne aussi que des solutions antérieures (et similaires) avaient déjà été identifiées il y a au moins 3 ans voire plus.

On est dimanche, vendredi est loin, mais je voudrais quand même agrémenter ce journal avec une petite fiction, afin d'éviter que ma prose ne se retrouve trop rapidement catégorisée de bookmark.

1978, dans un labo top secret. Réunion au sommet, un développeur se plaint de la façon dont les chaînes de caractères sont gérées par son compilateur C.

Bob: non mais les gars, sérieux, c'est pas possible. A chaque fois que je veux calculer la longueur d'une chaîne, cet abruti part du début de la chaîne, et compte les octets jusqu'à croiser un zéro
Mitchell: et alors ? on a toujours fonctionné comme ça. Tu voudrais quoi ?
Bob: ben je sais pas, on pourrait stocker la longueur de la chaîne, et la tenir à jour ?
Mitchell: mais t'es complètement débile ou quoi ? Tu te rends compte du temps que ça prendrait ? Ce serait une catastrophe en terme de performance ! La troisième guerre mondiale ! La fin du règne de l'être humain sur terre !
Bob: bah oui, mais ce serait pratique, on arrête pas d'avoir des bugs avec ce truc. Pour les développeurs débutant on pourrait au moins mettre ça comme comportement par défaut, et garder l'autre méthode pour les fois où la performance est importante
Mitchell, accompagné de John, Lewis et Cindy: t'es vraiment complètement idiot ; t'as pas entendu ce qu'on vient de te dire : c'est trop dangereux pour les performances ! Ah mais quel relou ce Bob !

Bon, le stockage de la longueur de la chaîne existait depuis longtemps en 78 (notamment c'est le comportement standard en Pascal), mais c'est juste pour illustrer qu'on peut avoir des attentes différentes et qu'elles ne sont pas forcément idiotes. Désormais, une très (très, très, très) grosse quantité du code s'appuie sur des classes qui encapsulent la chaîne de caractère rajoutant un overhead conséquent, mais largement bienvenu.

Je sais, je sais, le journal précédent parlait de virgule flottante, ça n'a strictement rien à voir. Ou pas.

Allez, à vendredi, et bises à tous !

L'auteur décline la responsabilité de tout troll qui se serait glissé dans ce journal.

# Toi Tu vas avoir des problèmes avec le corps enseignant ;)

Posté par .Nicolas. le 21 janvier 2018 à 23:51. Évalué à -10.

Bloub
- [^] # Re: Toi Tu vas avoir des problèmes avec le corps enseignant ;)
  
  Posté par Dr BG le 22 janvier 2018 à 09:51. Évalué à 7. Dernière modification le 22 janvier 2018 à 09:55.
  
  Marrant, mais mon « corps enseignant », faisait déjà des choses similaires il y a fort longtemps : http://frederic.goualard.net/software/gaol-4.2.pdf
- [^] # Re: Toi Tu vas avoir des problèmes avec le corps enseignant ;)
  
  Posté par snowball (site web personnel) le 22 janvier 2018 à 15:19. Évalué à 9.
  
  Parfois je me dis que certains mériteraient d'avoir des problèmes avec leur corps en saignant.
  - [^] # Ah nan, ça c'est de la biologie !
    
    Posté par .Nicolas. le 22 janvier 2018 à 17:48. Évalué à -10.
    
    Plop
# Liens

Posté par ®om (site web personnel) le 22 janvier 2018 à 00:34. Évalué à 4.

Commentaires reddit

À propos de ta fiction : The Most Expensive One-byte Mistake

blog.rom1v.com
- [^] # Re: Liens
  
  Posté par Michaël (site web personnel) le 22 janvier 2018 à 10:29. Évalué à 8.
  
  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.
  - [^] # Re: Liens
    
    Posté par freem le 22 janvier 2018 à 12:01. Évalué à 8.
    
    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.
    
    Ou alors, on pourrait considérer que le C pourrait fournir un minimum de support pour les chaînes de caractères dans le modèle length+data. Sauf que l'on s'expose alors à un autre problème, qui n'est pas si simple qu'il n'y paraît: dans l'article, l'auteur indique
    
    Using an address + length format would cost one more byte of overhead than an address + magic_marker format
    
    Traduction grossière: «Utiliser un format adresse + taille ne coûterait qu'un octet de plus par rapport au format adresse + valeur_magique».
    C'était vrai à une époque donnée, sur un CPU donné, mais dans la pratique, les CPUs n'utilisent pas la même taille de mots, du coup, cette assertion est fausse dans pas mal de cas aujourd'hui. Accessoirement, ça limiterait la taille des chaînes de caractère à 65535 octets. Difficile, avec des fichiers de log ou des données XML un peu volumineux (avec UTF8, ça passera encore, mais en unicode 32, on a moins de 17000 caractères)…
    
    Du coup, même si c'est vrai que ça pose des problèmes de sécurité quand on ne fais pas gaffe, et que c'est facile de ne pas faire gaffe, je pense que c'est un sacré raccourcis que de dire que c'est l'erreur la plus coûteuse.
    Le C n'est pas juste fait pour tourner sur du matériel grand public, mais pour écrire du code portable (et pas forcément porté), efficace et puissant. Avec ces contraintes, le choix «null-terminated» était plus logique que celui d'utiliser des tailles: la taille des mots change avec les processeurs et le temps, les besoins aussi.
    Du coup, le choix avec le moins d'impact sur les conceptions futures est bien le marqueur de fin: ce mécanisme marche juste sur la totalité des architectures sans la moindre modification de code, est indépendant du compilateur (quelle est la taille standard de size_t? Sur n'importe quel compilo ou CPU?).
    Si l'on à besoin de manipuler beaucoup de chaînes de caractère, on prend un outil fait pour, quitte à introduire une dépendance (qui aurait éventuellement pu être incluse dans le standard, depuis, mais passons).
    - [^] # Re: Liens
      
      Posté par pulkomandy (site web personnel, Mastodon) le 22 janvier 2018 à 16:13. Évalué à 4.
      
      Je te dis pas les problèmes quand tu lis un fichier depuis un disque ou le réseau pour savoir si la longueur est sur 8, 16 ou 32 ou 36 bits, et dans quel endianness, aussi.
# Un doute...

Posté par Tonton Th (Mastodon) le 22 janvier 2018 à 00:54. Évalué à 9.

Quand je lis dans /. : « When the calculated result is no longer sufficiently accurate the result is so marked, as are all further calculations made using that value. », je sens venir du Kamoulox :)

ce problème soit réglé ou sensiblement atténué et qu'on puisse travailler sur des nombres à virgule flottante sans erreur et sans perte majeure de performance.

Effectivemt, si à ce système de détection de dépassement de borne, on ajoute un peu d'exécution prédictive, on peut recommencer le calcul à la volée avec une…

… Oh wait…
# 1986

Posté par harlock974 le 22 janvier 2018 à 05:12. Évalué à 1.

Comme j'avais loupé le précédent échange, un grain de sel ici :
Sur mon ordinateur de poche SHARP PC-1262 de 1986, si je tape :
2 - 1.8 - 0.2 = 0
Le résultat est bien 1
Comme quoi, quand on veut…
;)
- [^] # Re: 1986
  
  Posté par Michaël (site web personnel) le 22 janvier 2018 à 10:07. Évalué à 3.
  
  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.
- [^] # Vade retro satanas
  
  Posté par .Nicolas. le 22 janvier 2018 à 18:17. Évalué à -6.
  
  Ouai mais si tu utilises un ordinateur quantique aussi…
# Il faut bien lire ce qu'on lit!

Posté par Michaël (site web personnel) le 22 janvier 2018 à 10:01. Évalué à 10. Dernière modification le 22 janvier 2018 à 10:02.
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.
- [^] # Re: Il faut bien lire ce qu'on lit!
  
  Posté par kantien le 22 janvier 2018 à 15:01. Évalué à 8.
  La technique employée ressemble à l'arithmétique d'intervalles
  
  C'est bien ce qu'il me semblait. Et en plus il y a un troll caché sur les brevets d'algorithmes (que ce soit logiciel ou matériel, accepter un brevet sur des algorithmes faut vraiment pas être centré :-/).
  
  Sinon, depuis l'autre journal je suis tombé sur une approche des plus intéressantes : la représentation par fractions continues. :-) Elle est décrite dans ce rapport de recherche INRIA : Arithmétique Réelle Exacte par Fractions Continues de Jean Vuillemin (il date tout de même de 1987 ;-). L'idée étant de représenter une fraction continue, possiblement infinie, de manière finie via une continuation : vive la programmation fonctionnelle ! :-)
  
  L'article décrit la théorie : le corps des fractions continues et deux algorithmes pour les fonctions algébriques (fractions de polynômes) et les fonctions transcendantes (exponentielle, logarithme, fonctions trigonométriques et hyperboliques) basées sur des formules de Gauss, Legendre et Lambert. C'est une approche géométrique (un réelle comme produit d'homographies) particulièrement élégante, dont voici le résumé :
  
  Nous étudions une représentation des réelles calculables par fractions continues, qui prend en compte l'infini ∞ = 1 / O et l'indéfini ⊥ = 0 / 0. Deux algorithmes généraux sont introduits pour effectuer les opérations. L'Algorithme Algébrique, qui se particularise aux sommes et produits de fractions continues, opère de façon positionnelle, en produisant un terme du résultat par termes des paramètres. L'Algorithme transcendant, fondé sur la fraction continue de Gauss, permet le calcul d'une vaste classe de fonctions spéciales (exp, log …). Ces algorithmes ont été implantés en LeLisp, avec des performances très satisfaisantes.
  
  « God gave us the integers. All the rest is man's work. » Leopold Kronecker
  
  À l'époque Vuillemin en avait fait une implantation en LeLisp, mais il en existe une en Haskell présentée dans cette vidéo. Tu peux commencer par la vidéo, qui présente d'abord une autre bibliothèque Haskell basée sur une approche par intervalle en base 2 à la Cauchy¹, puis décrit plus en détail l'approche par fractions continues.
  
  Le code Haskell est assez court (cf le lien au-dessus). Il utilise des listes plutôt que des continuations car il tire partie de l'évaluation paresseuse de Haskell. Mais avec la bibliothèque Sequence de c-cube (qui a une approche par continuation) qui vient de sortir en version 1.0 combinée avec la bibliothèque Zarith, on doit pouvoir faire cela facilement en OCaml.
  1. j'ai d'ailleurs été étonné que l'orateur ait du expliquer à son auditoire ce qu'était une suite de Cauchy. :-o ↩
  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par snowball (site web personnel) le 22 janvier 2018 à 16:40. Évalué à 3.
    
    Sympa !
    PS
    Pourquoi écris-tu un "réelle" plutôt qu'un "réel" ?
    - [^] # Re: Il faut bien lire ce qu'on lit!
      
      Posté par kantien le 22 janvier 2018 à 23:47. Évalué à 5.
      
      Pourquoi écris-tu un "réelle" plutôt qu'un "réel" ?
      
      Erreur de frappe, j'ai pensé réel et mes doigts ont écrit réelle. Mes doigts ils sont libres, un peu comme les pinceaux : l'autre jour je voulais peindre des enfants nus qui couraient dans un champ, à la fin je regarde la toile, et j'avais peint un pingouin ! :-P
      
      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 00:25. Évalué à 1.
        
        Je te demandais ça parce que tu l'as écrit plusieurs fois du coup j'ai cru que c'était volontaire.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 23 janvier 2018 à 00:38. Évalué à 3.
        
        Ah oui, j'avais même pas vu. Comme l'article parle d'arithmétique réelle, mes doigts ont du continuer sur leur lancée. :-P
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 23 janvier 2018 à 16:06. Évalué à 3.
        
        C'est coquin, un doigt.
- [^] # Re: Il faut bien lire ce qu'on lit!
  
  Posté par Dring le 22 janvier 2018 à 21:51. Évalué à 5.
  
  J'avoue que la référence à l'article était juste un prétexte pour placer ma petite fiction à deux sous.
  
  Tiens, un petit commentaire à propos des "mathématiques de CE2". En CE2, point de nombre à virgule. Et même en CM1, on découvre surtout les fractions ; les virgules n'apparaissent que plus tard. Je me base sur la scolarité de mes enfants (donc les programmes actuels) - je ne me souviens hélas plus du programme de mon enfance.
  
  j'espère que personne n'a traité quelqu'un d'autre d'idiot
  
  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.
  
  Et puisque je prends un ton sérieux, je peux relancer de 2 et le fer à repasser sur le croissant à la rue du genou gauche.
  
  Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.
  
  Je serai bien en peine de dire ce que ça représente sur l'informatique mondiale (comparé à toute l'informatique système, mathématique, recherche, graphique, jeux, …), mais je ne pense pas que ce soit négligeable, et je ne suis pas sûr que ce soit minoritaire.
  
  Dans les années soixante, on avait un langage qui était conçu pour tout ça : le COBOL. Depuis, plus rien. Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.
  
  A quand un nouveau langage spécialisé pour ces usages ? Où une expression litérale genre "123.50" serait interprété comme un type décimal, et pas un float ? Même l'autoboxing de Java, implémenté longtemps après que ce langage soit sorti de la niche de l'embarqué pour lequel il avait été conçu, ne supporte pas le BigDecimal qui reste cloîtré dans son package.
  
  Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !". Je m'en fous des intervalles ; je manipule des sous. Un centime, c'est un centime. Je veux pas qu'il prenne son indépendance même si "il y a une bonne raison mathématique" derrière. Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
  
  J'en ai marre de corriger toujours les mêmes bugs après toutes ces années, du code qui génère une facture dont le total n'est pas égal à la somme des lignes qui la compose, et provoque la consternation de nos clients, et crée des problèmes de réconciliation qui font perdre du temps, et créent parfois des paniques (rigolez, mais quand deux lignes de plusieurs centaines de millions d'euros ne correspondent pas exactement, et qu'en plus il n'y a pas de seuil de tolérance, y'a de la sueur sur les claviers avant de comprendre d'où ça vient).
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par freem le 22 janvier 2018 à 22:32. Évalué à 5.
    
    Permets-moi de t'arrêter (enfin, rétrospectivement, et j'ai une bonne raison physique pour ça) sur ce point:
    
    Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.
    
    Je doute qu'aucune erreur ou bug ne filtre dans «l'embarqué» pour ça. Les convertisseurs analogue-digital (et vice-versa) ont une résolution, et dans leurs specs (enfin, mon souvenir remonte à y'a longtemps) leurs règles sont claires.
    Pourquoi dans les CPU on en chie à avoir un calcul exact, sachant qu'au final ça serai juste des 1 et des 0? Je n'en sais trop rien, sûrement parce qu'on a voulu imposer une représentation finie sans limitations d'un truc potentiellement infini (les nombres réels. Au final, c'est un peu comme la taille maximale d'une chaîne de caractère, mais pensé sur 64 bits je crois? Diantre! Et ça semble contraire à tout ce que j'ai vu à l'école, de préciser aucune information de façon explicite et simple sur la résolution des résultats finaux des calculs…)?
    
    Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.
    
    Ici, je ne vois pas le problème.
    Pour ce type de fonctionnalités, il me semble évident que le modèle objet prend tout son sens. Ce qui me dérange le plus, à la rigueur, c'est que le float natif, lui, ne soit pas un objet, alors que justement, il s'agit d'un type pour lequel l'opérateur == devrait être illégal. D'ailleurs, mon compilo me colle un warning, soigneusement transformé en erreur par mes réglages perso, quand je fais ça.
    
    Tu parles de règles légales, et un des problèmes est bien là: de la même manière que les chaînes de caractères ne devraient pas être considérées comme un type natif (ben oui: quel encode qu'il veut, le bon monsieur? Et comment que le programme il doit le savoir nativement? Ben il peut pas, mon bon monsieur…) ce genre de chose nécessite (au niveau financier du moins) un système pour que le comportement change selon les LOCALES de l'utilisateur.
    
    Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !".
    
    Alors il te faut soit cesser d'utiliser un langage généraliste, soit implémenter un jeu de classes (une lib, quoi) qui fasse ce que tu veux suffisamment bien pour que tous les comptables autour du monde puissent s'en servir.
    La tâche est ardue, mais avec assez d'argent à la clé, quelqu'un le fera sûrement.
    
    me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
    
    Tu lis dans mes pensées. Et pas pour de la compta & co: même pour du système, j'aimerai que mon compilo râle.
    Bon, comme il est évident que ça serait hyper lent de vérifier chaque calcul, je me suis contenté de me faire un remplaçant pour static_cast<>() nommé safer_cast<>().
    Ça ne gère malheureusement que le transtypage d'un entiers vers un autre, ça ne peux que faire un gros assert() de la mort qui tue en cas de dépassement en mode debug (et rien en release, mais je pense corriger ça en permettant le lancement d'exception ou un abort, le tout configurable via le template), mais ça reste nettement mieux que ce que le C++ me propose de manière native.
    Cela dis, un langage comme Rust pourrait proposer mieux, vu que l'accent n'est pas mis sur les performances mais la fiabilité.
    
    En tout cas, ne crois pas que le problème des dépassements et des arrondis est limité au tertiaire. Tous les programmes, sans exceptions, y sont soumis.
    - [^] # Re: Il faut bien lire ce qu'on lit!
      
      Posté par Dring le 23 janvier 2018 à 00:36. Évalué à 1.
      Pour ce type de fonctionnalités, il me semble évident que le modèle objet prend tout son sens.
      (…)
      La tâche est ardue, mais avec assez d'argent à la clé, quelqu'un le fera sûrement.
      
      Les librairies existent, elles sont là, mais non, ça ne suffit pas. Il y a encore plein de monde qui privilégie les floats, doubles et autres. Notamment parce qu'un litéral représentant un nombre décimal, c'est directement interprété comme un float ou un double.
      
      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".
      
      Le pire (enfin, en Java), c'est les gens qui écrivent ça :
      
      BigDecimal bd = new BigDecimal(5.5);
      
      Bref, qui initient un BigDecimal avec une valeur double ou float, quand le mal est déjà fait. Et alors, on fait quoi ? Ben on passe par une chaîne de caractère, pour dormir sur ses deux oreilles…
      
      BigDecimal bd = new BigDecimal("5.5");
      
      Le truc super économique… Surtout que si on utilise pas une chaîne, il faut préciser séparément le nombre de décimales qui nous intéresse. Si au lieu d'un taux de TVA on manipule un montant, avec une chaîne je précise directement le nombre de chiffres de précision. Avec un double, sachant qu'en plus BigDecimal est immutable, je me tape un :
      
      BigDecimal bd = new BigDecimal(100000); BigDecimal amount = bd.setScale(2); // ...vs... BigDecimal bd = new BigDecimal("100000.00");
      
      Quand je vous dis que les décimaux sont le parent pauvre, et que c'est au détriment de nou'z'aut', les développeurs financiers.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 23 janvier 2018 à 00:45. Évalué à 4.
        
        Je veux un langage qui permette d'exprimer un litéral décimal.
        
        Utilise Haskell, avec son mécanisme de type classes il a de la surcharge sur l'interprétation des littéraux.
        
        bd = 5.5 :: Decimal
        
        Par défaut (sans l'annotation de type) c'est de la base deux, mais avec une annotation tu peux l'interpréter dans n'importe quel type qui implante l'interface fractionnal.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 00:59. Évalué à 5.
        
        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.
        
        On a besoin de diviser par autre chose que des puissances de 10 (par 3, par 7 etc).
        
        On utilise le logarithme (dans toutes les situations où on applique un taux répété, donc dans toutes les situations à progression exponentielle).
        
        On a également besoin d'utiliser des régressions linéaires nécessitant des méthodes de moindres carrés où la racine carrée arrive au bout de deux ou trois lignes).
        
        Pour toutes ces opérations l'ensemble des décimaux n'est pas stable (i.e dès que tu appliques l'une de ces opérations à un type décimal tu n'obtiens plus un type décimal)
        
        Le cadre naturel de ces opérations n'est pas l'ensemble des décimaux: quand bien même les données en entrée seraient décimales, les résultats ne le sont plus dans 99.999999% des cas et donc exiger, par défaut, de travailler chez les décimaux est absurde (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.
        
        Tout cela a déjà été discuté dans le journal précédent.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 23 janvier 2018 à 15:54. Évalué à 6.
        
        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!
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 18:57. Évalué à 1.
        
        Bien vu pour TeX. Je n'y avais pas du tout pensé.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par freem le 23 janvier 2018 à 01:16. Évalué à 2.
        
        Du coup, la question que je me pose, c'est est-ce que la «nouvelle» (déjà 7 ans maintenant, hein, le coup de vieux…) façon de faire de C++ ne colle pas à ça?
        
        Je suis quasi sûr que ça a été repris d'un autre, mais ça n'empêche pas que ça puisse être être adapté, potentiellement?
        
        Pour ton bout de code Java, je suis désolé, mais c'est un problème de gens qui ne savent pas que l'on peut construire un même objet de plusieurs façons différentes. Enfin, je vais pas trop critiquer, en C++ standard certains points sont compliqués à paramétrer par les constructeurs classiques aussi.
        D'où, d'ailleurs, l'idiome des constructeurs nommés: on utilise une méthode statique avec un nom lisible pour construire l'objet, au lieu de son constructeur par défaut, lequel reste par défaut.
        Ça peut servir à pleins de trucs, mais dans mon cas, je me sert aussi de ça dans mes libs pour avoir des classes avec allocation dynamique que l'on peut construire en échouant sans pour autant envoyer d'exception: un constructeur par défaut est du coup considéré comme invalide et est retourné si un truc tourne mal pendant l'init de l'objet (manque de mémoire, paramètre invalide, etc, etc). Manque de peau, le you pay for what you use de C++ à oublié la STL…
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 23 janvier 2018 à 10:05. Évalué à 5.
        
        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.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par j_m le 28 janvier 2018 à 09:01. Évalué à 5. Dernière modification le 28 janvier 2018 à 09:04.
        
        Le pire (enfin, en Java), c'est les gens qui écrivent ça :
        
        BigDecimal bd = new BigDecimal(5.5);
        
        Ce genre de choses il doit y avoir moyen d'en faire une regle dans un coding style checker. Puis d'utiliser le style checker dans un outils d'integration continue de maniere a ce que ces erreurs ne passent pas inapercues.
        
        Ca ne suffit pas? Les developpeurs de l'equipe ne sont peut-etre pas d'accord sur les bonnes pratiques a mettre en place.
        
        Mais c'est vrai que ca aide quand ces bonnes pratiques sur le type des donnees sont plus ou moins forcees par le compilateur
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par kantien le 22 janvier 2018 à 23:53. Évalué à 6. Dernière modification le 22 janvier 2018 à 23:53.
    
    Ce qui me désole, c'est de tout ramener à des notions de mathématiques, en faisant abstraction du besoin de millions de codeurs.
    
    Pas le temps de développer, mais on est bien obligé de tout ramener à des notions mathématiques : l'informatique ce n'est que des maths dans le fond. Cela étant, on ne fait pas abstraction du besoin de millions de codeurs : il existe des bibliothèques de calcul à virgule fixe ou virgule flottante en base 10 pour la plupart des langages. On dit juste que si tel est son besoin alors il faut les utiliser et non passer par des flottants en base 2.
    
    J'en ai marre de corriger toujours les mêmes bugs après toutes ces années, du code qui génère une facture dont le total n'est pas égal à la somme des lignes qui la compose, et provoque la consternation de nos clients, et crée des problèmes de réconciliation qui font perdre du temps, et créent parfois des paniques (rigolez, mais quand deux lignes de plusieurs centaines de millions d'euros ne correspondent pas exactement, et qu'en plus il n'y a pas de seuil de tolérance, y'a de la sueur sur les claviers avant de comprendre d'où ça vient).
    
    Si le programmeur n'a pas utilisé les bons outils pour la tâche qui lui est assignée, c'est une faute professionnelle : il mérite une bonne volée de bois de vert de la part de ses supérieurs hiérarchiques (vu les conséquences de son erreur).
    
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
    - [^] # Re: Il faut bien lire ce qu'on lit!
      
      Posté par freem le 23 janvier 2018 à 01:20. Évalué à -3.
      
      l'informatique ce n'est que des maths dans le fond.
      
      Non. L'informatique, c'est juste de l'électronique, l'électronique étant une application de la physique, les maths n'étant qu'un outil purement inventé (j'attend de voir une expérience physique qui démontre l'existence de la non-existence aka le 0, voire des nombres négatifs ou imaginaires…) pour comprendre (entres autres) cette dernière.
      
      Pour le reste, je suis d'accord.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 01:59. Évalué à 6.
        
        L'informatique est une branche des mathématiques. On peut faire tourner un programme avec sa tête, à la main, avec un boulier, avec de l'électronique etc. On peut faire de l'informatique sans ordinateur. L'ordinateur n'est qu'une moyen technique de pratiquer du calcul rapidement. Une citation que j'aime à ce sujet:
        
        "La science informatique n'est pas plus la science des ordinateurs que l'astronomie n'est celle des télescopes" (Hal Abelson)
        
        Quant aux mathématiques, elles n'ont ni plus, ni moins de réalité tangible que l'informatique. Ce que tu vois à l'écran, tu pourrais le voir sur une feuille en dessinant ou en écrivant ou même en pensant; ce que fait l'ordinateur est du calcul que tout humain peut faire (en théorie) dans sa tête.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par rewind (Mastodon) le 23 janvier 2018 à 10:24. Évalué à 6.
        
        L'informatique est une branche des mathématiques.
        
        Ça, c'est la conception française de l'informatique (qui me convient bien). Mais en anglais, on ne dit pas «information science», on dit «computer science». Et dans le monde anglo-saxon, les départements d'informatique des universités ont été (ou sont encore) des émanations des départements d'électronique. En France, le plus souvent, l'informatique est accolé aux maths (appli), même si on trouve des endroits où l'informatique est accolé à l'électronique (mais c'est plus rare).
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Axioplase ıɥs∀ (site web personnel) le 23 janvier 2018 à 15:35. Évalué à 3.
        
        Mais en anglais, on ne dit pas «information science», on dit «computer science»
        
        Ça dépend vraiment d'où tu vas. J'étais dans la faculté d'« Information Science » de l'école de « Génie », et mon labo faisant de la preuve. Difficile de faire plus "l'informatique c'est des maths" que ça. Et à côté, l'école de « Sciences » avait un autre labo bossant sur des sujets très proches. Et deux équipes faisaient des compilateurs, dans deux écoles différentes de l'université.
        
        Au final, ça dépend beaucoup de quel département avait de l'argent quand le programme a été fondé, plus que de la réponse subjective à la question "l'info est elle une branche des maths ?".
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par gouttegd le 23 janvier 2018 à 10:41. Évalué à 6.
        
        "La science informatique n'est pas plus la science des ordinateurs que l'astronomie n'est celle des télescopes" (Hal Abelson)
        
        Tiens, je la connaissais celle-là mais je pensais qu’elle était de Dijkstra…
        
        J’ai voulu aller voir sur Wikiquote pour en avoir le cœur net et fin de compte je ne suis pas beaucoup plus avancé …
        
        « Le problème d’Internet, c’est qu’on est jamais sûr de la validité des citations. » — Abraham Lincoln, lui-même citant Platon à l’occasion de la Nuit des Longs Couteaux
        
        /HS
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 10:52. Évalué à 0.
        
        Lol !!!!
        Ils l'ont peut-être dit tous les deux sans savoir que ni l'un ni l'autre l'avait déjà dit :)
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 23 janvier 2018 à 10:43. Évalué à 8.
        
        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.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 23 janvier 2018 à 15:37. Évalué à 10. Dernière modification le 23 janvier 2018 à 15:41.
        
        Non. L'informatique, c'est juste de l'électronique
        
        Non, l'électronique c'est juste le domaine de l'ingénierie utilisé de nos jours (rien de ne dit qu'il en serait toujours de même) pour construire des machines à calculer.
        
        L'informatique, c'est juste de l'ébenisterie :
        
        ah, non, en fait l'informatique c'est juste de la mécanique :
        
        ou peut être bien de l'électronique :
        
        ou en fait, comme le disent les anglais c'est la science du calcul ou des calculateurs (computer science). Ce qui impliquent deux choses : les principes généraux pour traiter du calcul en soi (c'est à dire les mathématiques) et les principes pour fabriquer des machines à calculer (c'est ici qu'intervient l'électronique). La première partie est une science rationnelle (i.e. non empirique) qui n'a rien à craindre de l'épreuve du temps, la seconde n'appartient que de manière contingente aux traitements automatiques de l'information (elle dépend de notre connaissance des lois de la nature — de la physique — et demain un autre champ du savoir physique pourra prendre le relais¹).
        
        D'ailleurs le choix privilégié de la base 2, de nos jours, dans l'informatique est lié à l'électronique : ce n'est pas pour les propriétés mathématiques intrinsèques de cette base, mais pour la façon dont sont conçues les machines basées sur l'électronique que l'on utilise cette base. La pascaline, qui était mécanique, fonctionnait en base 10.
        
        Maintenant revenons sur la représentation des nombres, avec les polygones réguliers inscrits dans un cercle :
        
        on voit là, sur le dessin, un processus, un algorithme qui construit des polygones avec de plus en plus de côté qui se rapprocheront de plus en plus du cercle. 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 diamètre d'un cercle est proportionnel à son rayon; ce qui pourrait servir de définition au nombre $\Pi$ ². Mais on pourrait tout aussi bien appelé $\Pi$ le processus, l'algorithme ou le programme lui-même. C'est cette dernière solution (avec un autre processus que celui de la construction des polygones réguliers, mais l'idée est la même) qui a été retenue par Jean Vuillemin avec le développement en fractions continues dans l'article que j'ai donné en lien plus haut³. L'étude de la totalité de ces processus calculatoire, de leurs propriétés, du fait que les deux (voire trois) définitions de $\Pi$ sont équivalentes, voilà en quoi consiste la science du calcul que l'on nomme mathématique.
        
        à l'époque de Turing certaines mémoires machines étaient acoustiques, par exemple, et il y a eu un journal récemment sur le sujet. ↩
        
        en considérant conjointement la série des polygones réguliers circonscrits au cercle, on aurait là une approche à la Cauchy. ↩
        
        un nombre réel, du moins ceux calculables par machine (ou à la main, c'est bonnet blanc et blanc bonnet), c'est un membre d'une classe particulière de programmes : certains s'arrêtent et d'autres non, voir la vidéo lorsqu'il lance l'affichage de $\Pi^{10}$ (la commande cfString n'est qu'un interpréteur, une évaluation (possible) du programme). Chercher à comprendre ce qui est invariant par variation, ce qui est commun à toutes les interprétations possibles de ce genre de programme, voilà en quoi consiste l'art du mathématicien. :-) ↩
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 15:49. Évalué à 4.
        
        Très sympa ton com'.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 23 janvier 2018 à 16:59. Évalué à 3. Dernière modification le 23 janvier 2018 à 17:04.
        
        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 $\pi R^2$ . Pour faire le lien avec le périmètre du cercle et l'exponentielle on utilise la formule de Green-Riemann (Stokes).
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 18:25. Évalué à 2.
        
        Allez, j'y mets mon grain de sel pour rester niveau bac+1. Comme le LaTeX passe assez mal chez certains lecteurs: https://i.imgur.com/MhtPmwt.png
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 23 janvier 2018 à 22:46. Évalué à 3.
        
        C'est vrai qu'on peut se contenter de faire le calcul mais remarquer que la surface de quelque chose change en $\lambda^2$ lorsque cette chose subit une homothétie de rapport $\lambda$ 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!)
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 23:19. Évalué à 2.
        
        C'est vrai qu'on peut se contenter de faire le calcul mais remarquer que la surface de quelque chose change en \lambda² lorsque cette chose subit une homothétie de rapport \lambda est quand-même une remarque importante. ;)
        
        Bin le calcul illustre l'homothétie de rapport r le long des deux axes (dx devient r dt par homothétie sur les abscisses, et f(rt)=rf1(t) montre l'homothétie sur les ordonnées). Avec la mesure produit issue de la mesure de Lebesgue sur R^2, tu fais finalement la même chose. Certes, je te l'accorde, mon papier c'est plus artisanal (je précise au début que c'est volontairement niveau bac+1) et ça évite de sortir l'artillerie lourde (l'existence de la mesure de Lebesgue sur R, c'est du lourd, et la mesure produit sur R² en rajoute une couche). Avec l'âge, j'évite de sortir le marteau piqueur pour écraser une mouche, sûrement pour économiser mes lombaires :)
        
        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é.”
        
        Dans mon papier, si tu regardes bien, je précise dès le début que Ar est la surface du disque de rayon r (et je note pi celle du disque de rayon 1).
        
        À 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.
        
        Oui !!! C'est le développement proposé par W.Rudin dans son (génial) Analyse Réelle et Complexe. De mémoire, ça constitue les 2 première pages: il définit l'exponentielle complexe e^z via la complétude de C et la convergence normale de la série des , il en déduit les fonctions trigo usuelles et les formules de développement usuelles (en se servant la série produit et des propriétés de convergence commutative par convergence absolue de la série définissant ). Il définit alors pi comme le double du plus petit réel >0 annulant la fonction cosinus. Ce bouquin est une merveille de clarté, propose des exercices super intéressants (mais difficiles et non corrigés) et va quand même très loin en moins de 300 pages, avec des preuves très belles et très efficaces: un must !
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 01:57. Évalué à 2.
        
        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.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 02:32. Évalué à 2.
        
        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 ans, ne savent pas dériver une composée, ne savent pas manipuler les ensembles (confondent éléments, parties, même dans les cas les plus simples), ne se souviennent pas souvent de la formule permettant de calculer un produit scalaire dans un r.o.n, n'ont jamais vu la définition d'une rotation, et j'en passe. Ils savent que l'aire sous la courbe entre a et b correspond à une intégrale de a à b. A bac+1, après quelques mois, ils savent faire des changements de variables linéaires et apprennent ce qu'est une somme de Riemann. C'est pour ça que j'ai autant limité mon papier (j'ai fait un effort d'accessibilité bac+1).
        
        Imagine un peu si tu t'amuses à construire l'aire d'une partie A de R2 par le sup en e>0 des inf des séries de terme les aires des disques de diamètre au plus e dont la réunion recouvre A !!!! La notion de sup, tu oublies (inf, idem), la notion de série tu oublies, la notion de recouvrement dénombrable les achève définitivement et la tentative de comprendre l'ensemble de la construction les enterre :) :) Et puis il faudra leur faire admettre l'additivité d'une telle mesure (pas facile du tout. Même l'invariance par translation leur demanderait un effort monstrueux alors l'homothétie qui multiplie les aires par le carré du rapport, t'imagines !!!) Surtout si à la fin tu leur dis fièrement avoir démontré que l'aire d'un disque de rayon r est $\pi r^2$ !! :) :)
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 02:46. Évalué à 3.
        
        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
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 12:30. Évalué à 2.
        
        Espèce de jeunot va ! :)
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 17:00. Évalué à 3.
        
        Mon coiffeur a une perspective différente sur cette question et une autre appréciation.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 24 janvier 2018 à 00:56. Évalué à 3. Dernière modification le 24 janvier 2018 à 00:59.
        
        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 e^(2i𝜋 * k / n).
        
        Il y a méprise sur ce que je voulais dire : c'est ainsi que l'on démontre, d'après les principes de la géométrie euclidienne, que dans celle-ci le périmètre d'un cercle est proportionnel à son diamètre. C'est-à-dire par triangulisation (les grecs anciens triangulaient tout et dans ce cas découpaient les polygones réguliers en autant de triangles que nécessaires) puis en appliquant le théorème de Thalès à chaque étape de la construction : les polygones réguliers des deux cercles sont semblables à chaque étapes et leurs périmètres sont dans la même proportion que les diamètres des cercles, il en est donc de même des périmètres des cercles. Ergo, le périmètre d'un cercle est dans un rapport constant avec son diamètre que l'on appellera $\Pi$ . Il y a là un passage à la limite qui n'était pas totalement justifié par les anciens et qui ne fut correctement formalisé que par Cauchy (via sa notion d'espace complet) ou par Dedekin (via ses coupures). Ceci étant ce processus est (partiellement ?) constructible à la règle et au compas, donc par des procédés algébriques bien que sa limite soit transcendante.
        
        Je ne voulais pas dire par là que cette approche fournit un algorithme effectif de calcul de $\Pi$ implantable sur machine. C'est un peu comme quand les pythagoriciens on découvert l'irrationnalité de $\sqrt{2}$ (ce qui foutu un sacré bordel dans leur conception du monde) et que plus tard Socrate fit résoudre le problème de la duplication du carré à un esclave ignorant dans le dialogue du Ménon : si tu n'arrives pas à décrire une procédure qui te donne la solution, montre moi la ligne qui résout le problème, à savoir la diagonale du carré :
        
        SOCRATE — Combien de pieds a donc cet espace ?
        L’ESCLAVE — Huit pieds.
        SOCRATE — De quelle ligne est-il formé ?
        L’ESCLAVE — De celle-ci.
        SOCRATE — De la ligne qui va d’un angle à l’autre de l’espace de quatre pieds ?
        L’ESCLAVE — Oui.
        SOCRATE — Les savants appellent cette ligne diamètre. Ainsi, supposé que ce soit là son nom, l’espace double, esclave de Menon, se formera, comme tu dis, du diamètre.
        L’ESCLAVE — Vraiment oui, Socrate.
        
        Ménon
        
        Là on a du Socrate cité par Platon cité par kantien sur un forum linuxfrien, mais il me semble bien que Lincoln est d'accord sur l'origine de la source. ;-)
        
        Si tu vas lire le début du dialogue, tu verras qu'au début l'esclave propose de doubler le côté du carré, puis tente le ratio 3/2 (on se rapproche de la bonne valeur) mais voyant qu'il n'y arrivera pas, Socrate l'oriente vers la bonne réponse.
        
        Sinon toujours dans le rapport géométrie-mathématique-informatique, l'interprétation des géométries hyperboliques dans la géométrie euclidienne par Poincaré :
        
        Considérons un certain plan que j’appellerai fondamental et construisons une sorte de dictionnaire, en faisant correspondre chacun à chacun une double suite de termes écrits dans deux colonnes, de la même façon que se correspondent dans les dictionnaires ordinaires les mots de deux langues dont la signification est la même :
        
        Espace. . . . . Portion de l’espace située au-dessus du plan fondamental.
        
        Plan. . . . . Sphère coupant orthogonalement le plan fondamental.
        
        Droite. . . . . Cercle coupant orthogonalement le plan fondamental.
        
        Sphère. . . . . Sphère.
        
        Cercle. . . . . Cercle.
        
        Angle. . . . . Angle.
        
        Distance de deux
        points. . . . . Logarithme du rapport anharmonique de ces deux points et des
        . . . . . . . . intersections du plan fondamental avec un cercle passant par ces deux
        . . . . . . . . points et le coupant orthogonalement.
        etc… etc…
        
        Prenons ensuite les théorèmes de Lobatchevsky et traduisons-les à l’aide de ce dictionnaire comme nous traduirions un texte allemand à l’aide d’un dictionnaire allemand-français. Nous obtiendrons ainsi des théorèmes de la géométrie ordinaire.
        
        Par exemple, ce théorème de Lobatchevsky : « la somme des angles d’un triangle est plus petite que deux droits » se traduit ainsi : « Si un triangle curviligne a pour côtés des arcs de cercle qui prolongés iraient couper orthogonalement le plan fondamental, la somme des angles de ce triangle curviligne sera plus petite que deux droits ». Ainsi, quelque loin que l’on pousse les conséquences des hypothèses de Lobatchevsky, on ne sera jamais conduit à une contradiction. En effet, si deux théorèmes de Lobatchevsky étaient contradictoires, il en serait de même des traductions de ces deux théorèmes, faites à l’aide de notre dictionnaire, mais ces traductions sont des théorèmes de géométrie ordinaire et personne ne doute que la géométrie ordinaire ne soit exempte de contradiction.
        
        La Science et l'hypothèse, Henri Poincaré.
        
        Bah voilà, son dictionnaire c'est analogue à un schème de compilation : il traduit les primitives d'un langage dans les primitives d'un autre avec préservation de la sémantique et, à partir de là, tous les énoncés de l'un se traduisent en un énoncé de l'autre. :-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 01:31. Évalué à 2.
        
        Ceci étant ce processus est (partiellement ?) constructible à la règle et au compas,
        
        Il n'est quasiment jamais constructible (sauf quand n est un produit d'une puissance de deux par des nombres premiers de Fermat c'est à dire de la forme $1+2^{(2^m)}$ ).
        C'est justement la remarque de Michaël: le raisonnement s'appuie (inutilement) sur une figure non constructible règle et compas. Si on y pense bien, la preuve de l'existence de n points uniformément répartis sur le cercle n'a rien d'évident à l'aide des théorèmes de la géométrie euclidienne classique.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 24 janvier 2018 à 02:06. Évalué à 3.
        
        Il n'est quasiment jamais constructible (sauf quand n est un produit d'une puissance de deux par des nombres premiers de Fermat c'est à dire de la forme 1+2^{{(2^m)}).}
        
        C'est bien ce qu'il me semblait, mais je ne me souvenais plus de la condition (d'où le partiellement). Cela étant cela suffit pour avoir un processus constructif (on n'a pas besoin de tous les termes), même si ce n'est pas essentiel à mon propos.
        
        Si on y pense bien, la preuve de l'existence de n points uniformément répartis sur le cercle n'a rien d'évident à l'aide des théorèmes de la géométrie euclidienne classique.
        
        Ah bah si ça l'est, c'est ainsi que les géomètres grecs (dont Euclide) démontraient que le périmètre d'un cercle était proportionnel à son diamètre : par passage à la limite de Thalès sur les polygones réguliers inscrits et circonscrits au cercle. Mais n'ayant pas de moyen rationnel ou irrationnel pour évaluer le rapport, on lui donna le nom de $\Pi$ . De mémoire (ça fait un moment que je n'ai pas lu les Éléments de Géométrie), on prouve qu'un angle est toujours subdivisible dans les proportions entières que l'on veut, puis on considère les points d'intersections avec la circonférence (par contre c'est là qu'ils admettaient inconsciemment la complétude au sens de Cauchy de leur espace).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 09:15. Évalué à 1.
        
        On prouve qu'un angle est toujours subdivisible dans les proportions entières que l'on veut
        
        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 ?
        
        Quel théorème classique de la géométrie euclidienne utilises-tu pour démontrer l'existence de n points uniformément répartis sur le cercle ?
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 10:37. Évalué à 3.
        
        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.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 24 janvier 2018 à 16:26. Évalué à 4.
        
        mais peut-être qu'ils admettent que le cercle est rectifiable?
        
        Oui et cela sans aucun soucis, voir cette proposition d'Archimède :
        
        Un cercle quelconque est égal à un triangle rectangle dont un des côtés de l'angle droit est égal au rayon de ce cercle, et dont l'autre côté de l'angle droit est égal à la circonférence de ce même cercle.
        
        Dans le même traité, il donne une approximation de $\Pi$ par la fraction 22 / 7 (proposition 2).
        
        Ils admettaient (pour des raisons de complétude) que toutes les proportions étaient réalisables, mais ils n'en proposaient par pour autant une construction effective (il y a même là impossibilité pour la trisection de l'angle).
        
        Du côté de chez Euclide, dans son livre IV, où il traite des polygones inscrits et circonscrits, il ne fournit que la construction effective pour le triangle, le carré, le pentagone, l'hexagone et le quindécagone. Le dernier cas est une bonne illustration de la façon dont le géomètres grecs pratiquaient le raisonnement par analyse-synthèse, où la solution est obtenue par combinaison de celle du triangle équilatéral et du pentagone régulier.
        
        Par contre, des livres disponibles sur ce site, je n'ai pas trouvé la preuve du fait que tous les cercles sont semblables (et donc que la circonférence est proportionnelle au diamètre). Il manque la livre V qui traite de la théorie des proportions (en langue moderne, cette partie fait abstraction de la nature des objets dont on considère les proportions et se retrouve proche d'une théorie qui ferait des proportions un corps et des objets un espace vectoriel sur ce corps). S'ensuit le livre VI où il traite de la similitude (de nos jours on incorpore ce concept dans l'axiomatique même des espaces vectoriels), on y trouve bien la preuve du théorème de Thalès mais toujours pas celle de la similitude des cercles. En revanche, au livre XI, on a bien un théorème sur la proportion des surfaces de polygones semblables inscrits dans des cercles, ainsi que celui de la proportion entre la surface d'un cercle et la carré de son diamètre.
        
        Mais l'approche que je voulais souligner chez les anciens et le recours à la méthode d'exhaustion ancêtre du calcul infinitésimal. D'après Wikipédia, Archimède l'aurait utilisée avec pour séries les polygones réguliers avec 2ⁿ côtés : il part du carré inscrit puis procède par bisection de chaque angle entre des sommets consécutifs et le centre (la bissectrice c'est une construction effective).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par Obsidian le 23 janvier 2018 à 00:52. Évalué à 3.
    
    A quand un nouveau langage spécialisé pour ces usages ? Où une expression litérale genre "123.50" serait interprété comme un type décimal, et pas un float ? Même l'autoboxing de Java, implémenté longtemps après que ce langage soit sorti de la niche de l'embarqué pour lequel il avait été conçu, ne supporte pas le BigDecimal qui reste cloîtré dans son package.
    
    Parce que dans la majorité des cas, cela n'a en fait aucun intérêt.
    
    Les problèmes d'arrondi sont les mêmes en binaire qu'en décimal : 1÷3, ça fait 0,33333333333… et il y aura donc une perte dans toutes les bases de calcul où ce nombre ne tombe pas rond (ça fait pile poil 1,3 en base 9, en revanche).
    
    Même en utilisant un type « financier » avec un nombre de décimales fixes après la virgule (en général 2, parfois 3), ça ne te permettra pas de faire toutes les divisions possibles. Si tu veux répartir équitablement 1,43 € entre deux personnes, tu vas forcément perdre 1 centime dans l'opération. Ce ne sera pas mieux avec un type de longueur arbitraire comme un BigDecimal Java ni avec une bibliothèque telle que GMP parce que tu serais toujours confronté aux mêmes problèmes de division si leur développement décimal est infini.
    
    Si, enfin, tu te restreins à des langages où le nombre de décimales est fixe et dans lesquels on ne peut faire que des additions, des soustractions ou des multiplications, alors il suffit de travailler en virgule fixe avec les formats habituels : au lieu de compter en euros, tu comptes en centimes et toutes tes valeurs sont alors des nombres entiers. Il devient alors trivial de les manipuler, même en binaire.
    - [^] # Re: Il faut bien lire ce qu'on lit!
      
      Posté par snowball (site web personnel) le 24 janvier 2018 à 11:15. Évalué à 3.
      
      C'est tout à fait juste. Je mettrais juste un bémol quand tu dis ça:
      
      Si, enfin, tu te restreins à des langages où le nombre de décimales est fixe et dans lesquels on ne peut faire que des additions, des soustractions ou des multiplications, alors il suffit de travailler en virgule fixe
      
      Pour les multiplications ça marche pas (à moins que tu fasses un entier fois un décimal et que ça ne sorte pas de la plage). Pour les matheux, la structure algébrique qui sous-tend la virgule fixe c'est le $\mathbb{Z}$ -module pas l'anneau.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 11:25. Évalué à 5.
        
        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.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 11:55. Évalué à 3.
        
        […] les programmeurs qui ne sont pas conscients de toutes les décisions à prendre lorsqu'on programme ce genre de calculs.
        
        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. Ça a l'air évident, mais ça ne l'est pas pour tout le monde vu que beaucoup de programmeurs (la grande majorité ?) est fâchée avec ces concepts difficiles mais doit faire face au quotidien à des difficultés qui viennent justement de ce manque de compréhension fine des concepts.
        
        Quand je dis ça, j'ai bien conscience que ça peut "blesser" certains mais ce n'est absolument pas mon but. C'est un constat qui n'est absolument pas un jugement méprisant de ma part. Je précise car je sens parfois une certaine animosité contre ce genre de propos. Kantien avait cité un texte très juste sur l'autre fil pour parler de cet affrontement absurde entre "théorie et pratique" où la pratique (associée inconsciemment au pragmatisme et à la réalité) l'emporterait sur la théorie (associée inconsciemment au rêve ou à l'hypothétique). La pratique informatique ne peut, dans certains cas, passer outre la théorie (typiquement sur ce genre de sujet).
        
        Il est difficile pour beaucoup de comprendre que les mathématiques ont fait le tour de ces sujets et que l'implantation choisie par défaut dans la plupart des langages est le choix le plus judicieux, non par choix arbitraire, mais par démonstration que c'est ce qu'il y a de moins mauvais avec les machines dont on dispose.
        
        PS1
        Je suis franchement agréablement surpris par le niveau remarquable de beaucoup d'intervenants sur ce site (que ce soit sur le plan mathématique et/ou informatique). Mis à part un cas pathologique que chacun aura identifié, je découvre quasiment à chaque commentaire quelque chose auquel je n'avais pas pensé, soit sur le fond, soit sur la forme et c'est vraiment un plaisir.
        
        PS2
        Le système "d'auto-modération" des fils (karma, masque des commentaires horribles) participe à la bonne lecture du sujet du journal. Certains forums devraient en prendre de la graine :)
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 12:18. Évalué à 5.
        
        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. :)
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 12:26. Évalué à 4.
        
        Tout à fait. Dans l'école où je bosse, j'ai monté de toute pièce un module d'enseignement où l'on traite de ces sujets délicats (je dis vraiment merci à deux amis ingénieurs qui m'ont convaincu que c'était important). Les retours des étudiants qui ont poursuivi leurs études sont assez éloquents: c'est un enseignement qu'ils jugent à posteriori indispensable.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Blackknight (site web personnel, Mastodon) le 24 janvier 2018 à 14:07. Évalué à 5.
        
        beaucoup de programmeurs sont fâchés avec ces concepts difficiles mais doivent faire face au quotidien à des difficultés qui viennent justement de ce manque de compréhension fine des concepts
        
        Oui alors bon, on va quand même être plus circonspect, on (les informaticiens) a beaucoup d'autres problèmes techniques à résoudre dans la majeure partie des cas avant d'en arriver à se poser des questions d'analyse numérique :D
        
        PS: Je me suis permis une petite correction de conjugaison sur la citation, "la grande majorité" se trouvant entre parenthèses, j'espère que tu ne m'en voudras pas :D
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 24 janvier 2018 à 14:19. Évalué à 2.
        
        La grande majorité des profs de math aurait-elle un problème avec le français ? :) :)
        
        Et oui, je suis d'accord avec toi, je parlais bien des programmeurs qui sont confrontés souvent aux problèmes de calcul avec des flottants. Je suis conscient que beaucoup de programmeurs font face à des problèmes tout aussi complexes (certainement plus complexes d'ailleurs) qui n'ont rien à voir avec IEEE754 (je peux te citer en exemple puisque je te connais irl :) )
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par snowball (site web personnel) le 23 janvier 2018 à 01:43. Évalué à 5.
    Un centime, c'est un centime. Je veux pas qu'il prenne son indépendance même si "il y a une bonne raison mathématique" derrière. Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
    
    Si tu veux un langage qui répond à tes besoins, il va falloir les spécifier précisément ces besoins. Commençons donc par quelques questions basiques:
    1. Quand tu augmentes un employé qui gagne 2101.35€ de 10%, tu veux que ton langage te donne quoi comme résultat ? 2311.49€ ou 2311.48€ ?
    2. Quand tu dois répartir 100€ d'augmentation de façon égale sur 3 employés, tu veux que ton langage te donne quoi comme résultat ?
    3. Quand tu as effectué une remise de 10% à un client sur toute une série de produits puis que que le mois d'après il faut annuler cette remise, tu attends quoi de ton langage si tu ne lui autorises que des décimaux ?
    (exemple: je pars de 13.55, j'applique la remise et j'obtiens 12.195, je la stocke comment déjà ? avec deux décimales ? Si oui je garde quoi 12.20 ou 12.19 ? Et quand bien même on aurait gardé 3 décimales (en coupant des centimes en deux), comment le langage va faire pour annuler la remise initiale puisque qu'il faudrait multiplier par 10/9 mais que ce nombre n'est pas un décimal et que de toute façon il n'a pas de représentation exacte en machine ? Dans quoi le langage va t-il stocker ce 10/9 ? Si on fait des approximations au décimal le plus proche, sur 10 unités ça se verra pas trop, mais sur 100 000 unités, ça va faire un sacré écart…
    
    Comment répondait le COBOL à tous ces problèmes ? Aucun langage ne peut deviner comment arrondir ce qui ne tombe pas juste. Ce n'est pas au langage de décider des règles d'arrondi mais à l'utilisateur.
    
    De toute façon, il y a une solution à toutes questions si tu veux rester le plus juste possible: tu calcules tout en float (donc tu ne perds qu'à 1e-17 près en erreur relative) et tu arrondis en sortie au décimal le plus proche. Tu auras ainsi exactement ce que tu voulais. C'est d'ailleurs ce que fait une calculatrice.
    - [^] # Re: Il faut bien lire ce qu'on lit!
      
      Posté par Dring le 24 janvier 2018 à 22:07. Évalué à 4.
      
      Tes exemples sont intéressants, mais je ne vois pas où tu veux en venir.
      
      En général, si tu appliques une remise, dans une application de gestion, soit :
      - tu stockes le montant initial, le taux, et tu recalcules à chaque fois
      - tu stockes le montant initial et le montant de la réduction
      - tu stockes les 3 informations
      Tu ne cherches pas la réversibilité de l'opération ; tu dois juste garder le détail de ce qui a mené au résultat. Pour que ta piste d'audit soit recevable juridiquement et exploitable, entre autres.
      
      Si tu dois couper 100 € en 3, tu divises en 3, et tu fais 100 - (les 3 montants), et soit le reliquat (0,01) va dans un compte spécial, soit il est réaffecté à un des 3 montants suivant une règle pré-déterminée.
      
      Sans cela, je me retrouve avec 3 lignes à 33,33, donc 99.99 et un total à 100, ce qui pose un problème comptable, fait échouer la réconciliation, gueuler le client, pleurer le comptable.
      
      Quand tu fais ton arrondi sur les résultats finaux, tu as régulièrement un problème à l'affichage, avec une incohérence entre le détail et le total. Quelque chose que le client ne comprendra pas ; et quand tu as des milliers de clients, tu ne veux pas avoir à expliquer cette différence.
      
      Mettre l'exactitude mathématique comme but ultime, ce n'est pas toujours ce qui est attendu du programme informatique.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 22:13. Évalué à 3.
        
        Mettre l'exactitude mathématique comme but ultime, ce n'est pas toujours ce qui est attendu du programme informatique.
        
        Je crois que le but des exemples n'est pas d'insister sur l'exactitude ou pas des calculs mais sur le fait qu'il y a plein de décisions arbitraires à prendre (arrondir quoi, comment, etc.) au delà des calculs proprement dits et que, qu'on utilise des flottants des rationnels ou encore autre chose ne change rien au fait que le comportement du programme doit être soigneusement spécifié par le programmeur.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 25 janvier 2018 à 00:59. Évalué à 2.
        
        Comme dit Michaël, mes exemples avaient juste pour but de montrer que le langage ne peut décider à la place du programmeur comment arbitrer les arrondis.
        Si la spécification est complète, alors je ne vois pas en quoi le type float apporterait plus de problèmes que le type décimal.
        Pour y voir clair, peut être que tu pourrais nous donner un bout de code avec flottants et qui pose problème puis donner le même bout de code avec le type décimal que tu voudrais et pour lequel il n'y aurait plus de problème, indépendamment des entrées.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 25 janvier 2018 à 09:57. Évalué à 5.
        
        Si la spécification est complète, alors je ne vois pas en quoi le type float apporterait plus de problèmes que le type décimal.
        
        Non, il y a des domaines métiers pour lequel les flottants binaires ne sont pas une solution recevable, d'où le besoin de flottants (j'insiste bien sur l'aspect flottant et non fixe) décimaux.
        
        What problems are caused by using binary floating-point?
        
        Une erreur à 5 millions de dollars par an pour une compagnie de téléphone (voir exemple 2, et le benchmark telco associé à ces problématiques métiers), ça fait cher les erreurs de calcul sur l'émission de factures (sans parler des contraintes légales : le législateur fixe les règles et algorithmes en base 10 et il vaut mieux les respecter ;-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 25 janvier 2018 à 10:42. Évalué à 1.
        
        Pour un flottant décimal comme évoqué dans ton lien, que va provoquer l'affectation $x=10^{10}+0.01$ sinon de l'absorption ? (un exposant augmenté de 1 multiplie l' ulp par 10 ). Alors bien évidemment, en augmentant la taille de la mantisse on peut, dans la plupart des cas, éviter ce genre de situation. Mais est-ce la bonne approche ?
        
        Dans le contexte donné par ton lien, ce dont on a besoin, c'est de pouvoir représenter avec un ulp constant (le centième), tous les nombres de la forme $n 10^{-2}$ contenus dans un intervalle fixe (du genre $[-10^{{10};10^{10}]).} Le contexte est donc celui de la virgule fixe non ?
        
        Les langages qui proposent de la virgule fixe, l'implantent en utilisant des floats en arrière boutique. C'est pourquoi je disais que si les choses sont correctement spécifiées, on peut toujours faire avec les floats. Et bien évidemment, mieux vaut utiliser un langage qui fait de la virgule fixe out of the box (comme Ada avec des déclarations de type du genre:
        
        type my_decimal is delta 0.01 range -10_000_000_000 .. 10_000_000_000;
        
        PS
        Je ne sais pas si on s'est bien compris
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 25 janvier 2018 à 12:32. Évalué à 3.
        
        Pour un flottant décimal comme évoqué dans ton lien, que va provoquer l'affectation $x=10^{10}+0.01$ sinon de l'absorption ?
        
        Le résultat escompté en base 10
        
        >>> from decimal import Decimal as D >>> D('10e10') + D('0.01') Decimal('100000000000.01')
        
        soit $10000000000001 \times 10^{-2}$ .
        
        Le contexte est donc celui de la virgule fixe non ?
        
        Pas spécialement, la dynamique apportée par les flottants peut s'avérer nécessaire, ainsi que le contrôle du mode d'arrondi qui va différer, pour des raisons législatives, selon les régions du monde.
        
        How much precision and range is needed for decimal arithmetic?
        What rounding modes are needed for decimal arithmetic?
        
        ou plus simplement la conclusion de la première question de la FAQ
        
        Both problems (the artifacts of binary floating-point, and the limitations of decimal fixed-point) can be solved by using a decimal floating-point arithmetic. This is now available in both hardware and software, as described on the General Decimal Arithmetic page, and is standardized in the IEEE Standard for Floating-Point Arithmetic (IEEE 754).
        
        Dis-toi que si la norme IEEE-754 a été révisée en 2008 pour y ajouter une standardisation de l'arithmétique flottante en base 10, ce n'est pas sans raison mais parce qu'il y a un besoin métier derrière.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par Michaël (site web personnel) le 23 janvier 2018 à 10:13. Évalué à 6.
    
    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”.
    - [^] # Re: Il faut bien lire ce qu'on lit!
      
      Posté par Dring le 24 janvier 2018 à 22:23. Évalué à 2.
      
      J'ai l'impression que ton commentaire porte uniquement sur la deuxième partie de la citation ; corrige-moi si je me trompe.
      
      Cela étant dit : note bien que de mon côté je ne proposerai jamais de modifier un langage avec un changement d'une telle ampleur : je pense plutôt au choix fait à la création du langage. Pourquoi tous les nouveaux langages fonctionnent avec, à chaque fois, une interprétation des litéraux à virgules comme étant des floats ou des doubles ?
      
      Pourquoi aucun langage "orienté business" n'est apparu depuis le début du déclin du COBOL ? Et pourquoi on se contente de librairies/paquetages pour supporter les décimaux sur des langages dits généralistes ?
      
      Pourquoi même PHP fonctionne ainsi ? Il y a plus de gens qui font du calcul "scientifique" en PHP que de personnes qui font des calculs "comptables" ? Je ne pense pas - ou alors je vis dans un monde parallèle.
      - [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 24 janvier 2018 à 23:59. Évalué à 3.
        
        J'ai l'impression que ton commentaire porte uniquement sur la deuxième partie de la citation ; corrige-moi si je me trompe.
        
        Tu as raison, ma citation est un peu “bizarre par excès” si on peut dire. :)
        
        Pourquoi tous les nouveaux langages fonctionnent avec, à chaque fois, une interprétation des litéraux à virgules comme étant des floats ou des doubles ?
        
        Je pense qu'un aspect important est que soit “interpréter les litéraux à virgules comme étant des décimaux” est une idée tellement géniale que tous les langages vont adopter cette convention dans les 5 ans, soit le langage qui fait ce choix va rester durant toute son existence le cousin un peu bizarre avec qui tout le monde se prend les pieds dans le tapis parcequ'il fait les choses un peu différemment. (Déjà que certains langages se paient le luxe d'avoir des opérateurs égal ==, vraiment égal === et physiquement égal ;) )
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 25 janvier 2018 à 11:05. Évalué à 2.
        
        A bien y réfléchir, je pense que ce que voudrait Dring c'est de la virgule fixe façon COBOL comme le propose Ada, qui permet de ranger directement dans des "décimaux" des littéraux et qui le prévienne dès qu'on sort des bornes ou qu'on descend en dessous du delta spécifié
        
        type my_dec is delta 0.01 range -100.0..100.0;
        
        Alors si tu écris
        
        s : my_dec; begin s := 0.001; [...]
        
        tu te prends une erreur de compilation 'value has extraneous low order digits'
        
        Si ça arrive au runtime, ça te lève une exception que tu peux intercepter et gérer.
        Idem si tu sors de la plage de my_dec. Si maintenant tu écris
        
        s,t : my_dec; begin s := 1.8; t := 0.2; s := 2.0 - s - t; -- L'affichage de s écrit 0.00 comme attendu dans son domaine d'application [...]
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Dring le 25 janvier 2018 à 22:00. Évalué à 2.
        
        J'avoue que c'est pas mal cool, et avec une syntaxe moins barbare.
        
        Le truc chiant avec les devises, c'est qu'elles n'ont pas toutes 2 décimales. Du coup, est-ce que dans ce code la valeur du delta peut être une variable ? Je crains que non.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 26 janvier 2018 à 00:51. Évalué à 2.
        
        Du coup, est-ce que dans ce code la valeur du delta peut être une variable ?
        
        Tu peux faire des packages génériques (en gros des templates dans le monde C++) qui prennent en argument des types delta.
        Comme le nombre de devises existantes est assez limité, tu peux déclarer si tu veux , par exemple une centaine de devises différentes, dans un fichier, et les envoyer en paramètres dynamiquement à ton générique sans avoir à recoder toutes tes procédures ou fonctions et ça répond à ton souhait.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 26 janvier 2018 à 15:02. Évalué à 3.
        
        A bien y réfléchir, je pense que ce que voudrait Dring c'est de la virgule fixe façon COBOL
        
        Sauf que COBOL propose des décimaux à virgule flottante. ;-)
        
        Typically a precision of 25-30 digits is used, though the ISO COBOL 2002 standard requires 32-digit decimal floating-point for intermediate results.
        
        source
        
        D'où la question de Dring pour avoir un exposant (un delta) variable. ;-)
        
        Il y a une raison à ton obsession pour le décimal en virgule fixe et la virgule flottante uniquement en binaire ?
        
        Le standard IEEE-754 pour les décimaux à virgule flottante définit trois types de base avec leur précision :
        
        decimal32 sur 32 bits avec 7 chiffres significatifs;
        
        decimal64 sur 64 bits avec 16 chiffres significatifs;
        
        decimal128 sur 128 bits avec 34 chiffres significatifs.
        
        Il vaut voir que l'ingénieur IBM qui est l'auteur de la norme a passé toute sa vie à développer des outils et langages pour les besoins métiers de Dring. Pourquoi insistes-tu pour l'envoyer sur de la virgule fixe ?
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 26 janvier 2018 à 16:16. Évalué à 1. Dernière modification le 26 janvier 2018 à 16:18.
        
        Il y a une raison à ton obsession pour le décimal en virgule fixe et la virgule flottante uniquement en binaire ?
        
        Par exemple parce que Dring a émis le souhait de disposer d'un type où le compilateur le prévient d'opérations qui pourraient poser problème. A part les cas d'overflow, un type décimal flottant ne répond pas à sa demande alors que la virgule fixe le fait.
        
        Par contre, il y a quelque chose qui m'échappe. Autant je comprends qu'un type flottant décimal réponde parfaitement à un problème du genre : appliquer un taux décimal à un nombre décimal sans perte de précision (sauf si dépassement de la taille de la mantisse); autant je ne vois que très peu de cas où cette situation arrive concrètement puisque les taux qu'on manipule sont presque toujours calculés à partir de quotients et donc sont très rarement décimaux.
        
        Du coup, les seuls cas intéressants pour le flottant décimal sont les cas où le taux provient d'une saisie décimale fournie par l'utilisateur. C'est ce genre d'exemple fourni par le lien que tu as donné où effectivement on comprend l'intérêt du calcul décimal (flottant ou non) mais ce genre de cas n'est pas celui qui se présente le plus souvent dans l'économat.
        
        C'est pour ça que je demandais à Dring de fournir des exemples de code montrant précisément où résidaient ses problèmes.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 26 janvier 2018 à 16:30. Évalué à 2.
        
        Un autre point que je trouve étrange dans le lien que tu as donné (http://speleotrove.com/decimal/decifaq1.html#inexact). Je cite le passage:
        
        Using double binary floating-point, the result of 0.70 x 1.05 is 0.73499999999999998667732370449812151491641998291015625; the result should have been 0.735 (which would be rounded up to $0.74) but instead the rounded result would be $0.73.
        
        Ils veulent le bon arrondi au centième et ils s'y prennent bizarrement je trouve. Le float qu'ils obtiennent 0.734999[…] s'arrondit au millième le plus proche en 0.735 sans aucun soucis. On applique alors la convention bancaire et on obtient bien 0.74. Ils font ça dans tous leurs exemples et argumentent ainsi en faveur du décimal flottant.
        
        En plus ils ne mentionnent pas que la plupart du temps, les taux proviennent du résultat d'un quotient ( $\Delta y / \Delta x$ ) et donc ne se stocke quasiment jamais de façon exacte (dans quelque base que ce soit).
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 26 janvier 2018 à 18:53. Évalué à 3.
        
        Ils veulent le bon arrondi au centième et ils s'y prennent bizarrement je trouve. Le float qu'ils obtiennent 0.734999[…] s'arrondit au millième le plus proche en 0.735 sans aucun soucis. On applique alors la convention bancaire et on obtient bien 0.74. Ils font ça dans tous leurs exemples et argumentent ainsi en faveur du décimal flottant.
        
        Non, ce n'est pas cela qu'il cherche à illustrer mais l'arrondi d'une opération à la deuxième décimale.
        
        >>> round(0.70 * 1.05, 2) 0.73 >>> round(1.30 * 1.05, 2) 1.37 # comparé à >>> from decimal import Decimal as D >>> DELTA = D('0.01') >>> (D('0.70') * D('1.05')).quantize(DELTA) Decimal('0.74') >>> (D('1.30') * D('1.05')).quantize(DELTA) Decimal('1.36')
        
        En plus ils ne mentionnent pas que la plupart du temps, les taux proviennent du résultat d'un quotient $(\Delta y / \Delta x)$ et donc ne se stocke quasiment jamais de façon exacte (dans quelque base que ce soit).
        
        Non, les taux de taxes et les taux de change sont fournis en décimal et doivent pouvoir être représentés de manière exacte dans le type. L'exemple du dessus provient d'ailleurs de l'application d'une taxe à 5%.
        
        Pour ce qui est des besoins des Dring, il a surtout fait mention du langage COBOL qui utilise des flottants et du type BigDecimal de Java qui est assez proche des flottants de la norme IEEE-754.
        
        Immutable, arbitrary-precision signed decimal numbers. A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale. If zero or positive, the scale is the number of digits to the right of the decimal point. If negative, the unscaled value of the number is multiplied by ten to the power of the negation of the scale. The value of the number represented by the BigDecimal is therefore (unscaledValue × 10^-scale).
        
        extrait de la documentation de la classe BigDecimal. Un BigDecimal à la forme :
        
        où mant est un entier signé de précision arbitraire et exp un entier signé sur 32 bits. On retrouve aussi dans cette classe la notion de contexte pour les opérations (qui gère les modes d'arrondis, la levée ou non d'exception en cas de résultat non représentable strictement…), toutes choses qui se retrouvent dans la norme IEEE-754 pour les décimaux flottants.
        
        Ce qui semble le plus dérangé Dring, c'est la syntaxe concrète pour faire usage du type en question. Pour ma part je trouve que c'est une question mineure, appeler le constructeur avec une chaîne de caractère pour les constantes au lieu de la syntaxe pour les float ça demande juste d'ajouter deux guillemets ''.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 26 janvier 2018 à 20:24. Évalué à 1. Dernière modification le 26 janvier 2018 à 20:26.
        
        Non, ce n'est pas cela qu'il cherche à illustrer mais l'arrondi d'une opération à la deuxième décimale.
        
        Quand on a décidé de mal arrondir, c'est sûr, on arrondit mal, ça on est d'accord. Si l'on veut arrondir correctement à 0.01 près, on fait le calcul à 0.001 près pour décider si on doit aller au dessus ou en dessous pour l'arrondi au centième. C'est d'ailleurs ce que font les calculatrices (avec leurs chiffres cachés, et c'est aussi ce que font les processeurs avec les bits supplémentaires permettant de faire les arrondis (défaut, excès, au plus près)). Quand on fait cela, il n'y a aucun problème avec les floats binaires.
        
        Sur le site que tu donnes il y a d'autres choses étranges.
        
        #include <iostream> using namespace std; int main() {double x = 1.05, y = 0.7, r1, r2 = 0.735; r1 = x * y; cout << r1 == r2 <<endl; // Va afficher True return 0; }
        
        Où est le problème ? Quand bien même on arriverait à 0.7349999[…], il n'y aurait pas de problème non plus: l'arrondi traité comme il faut donne ce que veut le banquier. Suivant la convention en vigueur, on peut donc parfaitement décider si l'on doit renvoyer, au centièmes près, 0.73 (par défaut) ou 0.74 (par excès). Le float binaire donnerait tout aussi bien le bon résultat si r1 était le résultat d'un quotient comme le sont la plupart des taux manipulés dans l'économat. Je n'arrive pas du tout à comprendre ce que donne le float décimal dans ce genre de cas.
        
        Non, les taux de taxes et les taux de change sont fournis en décimal
        
        Il n'y a pas que ce genre de taux quand on fait de l'économat. Certains taux peuvent résulter d'un quotient (c'est même souvent le cas non ?).
        
        […] doivent pouvoir être représentés de manière exacte dans le type.
        
        Et pourquoi donc ? Si tu as une valeur approchée à $10^{-17}$ de la valeur finale, il n'y a aucun problème à donner un arrondi qui respecte les spécifications imposées en sortie.
        
        Chacun des exemples donnés sur http://speleotrove.com/decimal/decifaq1.html#inexact se traite sans aucun problème sans utiliser le moindre flottant décimal. Si tu spécifies ce que tu veux, tu peux faire une fonction de deux lignes qui renverra exactement ce qu'est censé recevoir l'utilisateur.
        
        Pour ce qui est des besoins des Dring, il a surtout fait mention du langage COBOL qui utilise des flottants[…]
        
        Oui et aussi de la virgule fixe dont les spécifications sont suivies à la lettre par Ada. Comme Dring voulait des alertes compilo en cas de "problème", il fallait en passer par la virgule fixe (le flottant étant silencieux par nature sur la plupart des opérations posant problème).
        
        Voilà comment je comprends le problème concernant la monnaie:
        
        En entrée, on reçoit du décimal x à $10^{-2}$ près (appelons ce type D).
        En sortie on veut du décimal y à $10^{-2}$ près.
        Entre les deux, on a des opérations donnant un résultat f(x), qui en général, ne sera pas nécessairement y. Ce qu'on veut c'est arrondir f(x) pour obtenir le y désiré. Je ne pense pas que l'utilisation du flottant décimal apporte quoi que ce soit de plus dans ce type d'application que le flottant binaire. En tout cas, je n'ai pas encore vu de contre-exemple et je ne vois pas trop (à part utiliser des types n'utilisant pas la même taille mémoire).
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 26 janvier 2018 à 23:31. Évalué à 2. Dernière modification le 26 janvier 2018 à 23:34.
        
        Quand on a décidé de mal arrondir, c'est sûr, on arrondit mal, ça on est d'accord.
        
        Non ce qui est reproché aux flottants binaires sont leur API si on veut travailler avec du décimal. Que l'on puisse présenter un type abstrait, représenté de manière sous-jacente via le type float primitf (en binaire) d'un langage donné, qui se comporte comme des décimaux : personne ne le nie. Mais à ce compte là, il te suffit de ce type :
        
        type nat = | Zero | Succ of nat
        
        et de pouvoir faire de la récursion pour encoder tout est n'importe quoi dedans : c'est le principe même de l'informatique et du numérique. Ça va juste mettre à l'épreuve l'ingéniosité et la sagacité du programmeur.
        
        Mais ce que veulent les gens qui ont besoin de décimaux, c'est d'un type qui se comporte comme des décimaux : ils ont autre chose à foutre que de se taper l'encodage à la main. Donc soit le langage le fournit comme un type primitif, soit ils utilisent une bibliothèque le fournissant (et ils se foutent royalement du mécanisme effectivement utilisé pour l'implanter, tant qu'il se comporte comme souhaité).
        
        Si tu spécifies ce que tu veux, tu peux faire une fonction de deux lignes qui renverra exactement ce qu'est censé recevoir l'utilisateur.
        
        Oui et c'est ce qu'a fait l'auteur du site en question, à savoir Mike Cowlishaw, en rédigeant la norme IEEE-754 pour les décimaux flottants.
        
        This specification defines these components in the abstract. It neither defines the way in which operations are expressed (which might vary depending on the computer language or other interface being used),[1] nor does it define the concrete representation (specific layout in storage, or in a processor’s register, for example) of numbers or context.
        
        Si tu veux l'implanter en utilisant des flottants binaires comme représentation concrète¹, libre à toi, tant que tu respectes l'API décrite dans la norme : c'est de cela dont ont besoin les programmeurs.
        
        Voilà comment je comprends le problème concernant la monnaie:
        
        En entrée, on reçoit du décimal x à $10^{-2}$ près (appelons ce type D).
        En sortie on veut du décimal y à $10^{-2}$ près.
        
        Effectivement, c'est bien ce qu'il me semblait : tu n'as aucune idée des besoins et des attentes de ce domaine métier. ;-)
        
        Comme Colinshaw a passé un bon bout de temps à se pencher sur ces contraintes métiers, tu devrais te promener un moment sur le site que je cite depuis le début, tu y verras sans doute plus clair après.
        
        si tu fouilles le net tu trouveras des articles de recherche sur le sujet : utiliser le FPU (binaire) pour implanter cette norme. ↩
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 27 janvier 2018 à 09:50. Évalué à 2.
        
        Sommaire
        
        Sur le fond
        
        Virgule fixe / flottant binaire / flottant décimal ? Quel choix quand on veut représenter des valeurs monétaires en machine ?
        
        Une implantation rapide en Ada pour éclairer davantage
        
        Sur la forme
        
        Sur le fond
        
        Virgule fixe / flottant binaire / flottant décimal ? Quel choix quand on veut représenter des valeurs monétaires en machine ?
        
        Appelons D le type censé représenter notre monnaie. Qu'attendons nous de lui ?
        
        D doit pouvoir représenter de façon exacte les nombres de la forme k/100 où k est un entier compris dans un intervalle fixé borné (ici on pourrait se contenter de k inférieur à 1 million de milliards soit 10 puissance 15).
        
        On doit pouvoir, de façon exacte, additionner / soustraire dans D.
        
        Comme on ne multiplie pas des valeurs de D entre elles mais qu'on veut pouvoir prendre des fractions de D il nous faut pouvoir multiplier un float par un élément de D et obtenir un élément de D. On doit donc disposer en particulier d'une fonction d'arrondi de float vers D qui respecte scrupuleusement des règles fixées (éventuellement plus complexes que les 3 modes que propose les différentes normes IEEE754 décimal ou binaire). Celle-ci devra donc être codée par le programmeur en fonction des spécifications.
        
        Il serait bon, bien que non indispensable, que le programmeur puisse entrer des expressions littérales usuelles directement dans D et surtout, que le compilateur empêche des écritures qui sortent des attendus ci-dessus, et oblige le cas échéant au programmeur de forcer les choses par du casting explicite.
        
        Pour faire matheux, D doit donc posséder une structure (exacte) de Z-module et représenter des valeurs uniformément réparties d'un intervalle fixé (dont le diamètre ne dépasse pas 10 puissance 15). Cette description n'est pas celle des flottants (ulp variable, dynamique inutile pour représenter de la monnaie), par contre c'est exactement la description de la virgule fixe qui a été conçue spécialement pour ça.
        
        Une implantation rapide en Ada pour éclairer davantage
        
        with ada.text_io; use ada.text_io; procedure my_dec is -- Déclaration de notre type stockant la monnaie type dec is delta 0.01 range -10.00**16 .. 10.00**16; for dec'small use 0.01; -- Description des règles d'arrondi, à modifier en fonction des spécifications -- Ici on choisit l'arrondi au centime couramment utilisé évoqué dans le lien que tu as donné function round (u : long_float) return dec is function rounding_positive (u : long_float) return dec is d2 : dec := dec (100.0 * u); d1 : dec := 100 * dec (u); begin return (if d2 -d1 >= 0.5 then 0.01 * d1 + dec'small else 0.01 * d1); end rounding_positive; begin return (if u>=0.0 then rounding_positive (u) else - rounding_positive (-u)); end round; -- On ajoute une opération permettant d'appliquer des taux (flottants) à notre monnaie function "*" ( rate : long_float; d : dec) return dec is (round (rate * long_float (d))); value : dec := 100.0; d : dec := (1.0 / 3.0) * value; begin put_line (d'img); -- affiche 33.33 comme attendu d := (2.0/3.0) * value; put_line (d'img); -- affiche 66.67 comme attendu d := 1.05* dec (0.7); put_line (d'img); -- affiiche 0.74 comme attendu d := 0.01; while d <= 0.05 loop -- fait exactement 6 tours comme attendu put_line (d'img); d := d + 0.01; end loop; d := round (0.004); put_line (d'img); -- affiche 0.00 comme attendu d := round (0.005); -- affiche 0.01 comme attendu put_line (d'img); d := 10_000_000_000_000_000.0 + 0.01; put_line (d'img); -- affiche 10_000_000_000_000_000.01 comme attendu d := 0.001; -- provoque une erreur de compilation explicite d := end my_dec;
        
        Trois commentaires
        
        ma fonction d'arrondi correspond à une spécification particulière, mais le programmeur ne pourra faire l'économie d'écrire la fonction correspondant aux politiques d'arrondi qu'il a à respecter. C'est le seul moment où j'ai écrit du code "compliqué". Tout le reste est out-of-the-box et en terme d'API, c'est plus efficace (car plus safe au niveau code) que d'utiliser du flottant qui sera, par nature silencieux sur des écritures absurdes et qui sera également silencieux quand on dépasse les bornes de l'intervalle (alors qu'il faudrait soit empêcher la compilation le cas échéant, soit lancer des exceptions à l'exécution). Ce sont des exigences qu'un programmeur est en droit d'attendre dans l'économat et que ne lui fournit pas le flottant (binaire ou décimale).
        
        dans la fonction d'arrondi on peut ajouter des post et pré conditions si on veut rajouter la vérification que la fonction fait bien qu'elle doit faire et que ses arguments soient dans des bornes acceptables (cf https://en.wikibooks.org/wiki/Ada_Programming/Contract_Based_Programming )
        
        Les exemples que j'ai donnés montrent, que sans le moindre effort, on peut répondre aux problèmes auxquels n'est censé répondre que le flottant décimal (en tout cas c'est ce qu'on pourrait croire en lisant le lien (IBM) que tu as donné.
        
        Sur la forme
        
        Tu me cites:
        
        Quand on a décidé de mal arrondir, c'est sûr, on arrondit mal, ça on est d'accord.
        
        ce qui me semble être une évidence et refléter ce que tu as fait en python. Puis tu me réponds:
        
        Non ce qui est reproché aux flottants binaires sont leur API si on veut travailler avec du décimal.
        
        Mauvaise foi ? On était parti d'erreurs factuelles sur le site d'IBM que tu as mentionné concernant le calcul de 0.70 x 1.05. Ils font deux erreurs: la première sur le résultat du calcul en utilisant des "double". L'autre en arrondissant au centième sans tenir compte du chiffre des millièmes en sous-entendant que ça serait la faute du binaire flottant (!!!!) (La preuve que c'est du grand n'importe quoi est dans mon petit programme ci-dessus: aucun problème à arrondir correctement) et là tu me redis un "Non" (un non à quoi au juste ?) et tu embrayes en disant que finalement c'est un problème d'API !
        
        Que l'on puisse présenter un type abstrait, représenté de manière sous-jacente via le type float primitf (en binaire) d'un langage donné, qui se comporte comme des décimaux : personne ne le nie. Mais à ce compte là, il te suffit de [tout reconstruire à la main]
        
        Le programme ci-dessus te montre qu'on est très loin de cette caricature tu ne crois pas ?
        J'écris ensuite qu'il faut spécifier pleinement et qu'alors on fait facilement ce qu'on a à faire et tu réponds:
        
        Oui et c'est ce qu'a fait l'auteur du site en question, à savoir Mike Cowlishaw, en rédigeant la norme IEEE-754 pour les décimaux flottants.
        
        Je parlais de ce que veut l'utilisateur (en économat en l'occurrence). Je ne parle pas de celui qui pond une norme générale (qui d'ailleurs ne fournira pas forcément la bonne fonction d'arrondi out of the box au banquier). J'imagine bien que Mike Cowlishaw a fait ce qu'il avait à faire quand il a rédigé sa norme. D'autre part, les arrondis gérés par sa norme ne portent pas sur la deuxième décimale qui intéresse le banquier mais sur le dernier ulp (donc il faudra coder la fonction d'arrondi un peu comme je l'ai fait probablement)
        
        Effectivement, c'est bien ce qu'il me semblait : tu n'as aucune idée des besoins et des attentes de ce domaine métier. ;-)
        
        Peut-être pourrais-tu nous rappeler précisément ces besoins. J'ai l'impression que ni toi ni moi ne les connaissons précisément. Je fais ce que je peux en raisonnant mais si tu as des choses plus précises n'hésite pas à en faire part, c'est toujours intéressant.
        
        Je ne dis pas du tout que le flottant décimal est inutile (j'imagine bien qu'il y a des cas d'utilisation où c'est pratique), je dis qu'il ne répond pas aux besoins de Dring ce qui est très différent.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 27 janvier 2018 à 15:44. Évalué à 3. Dernière modification le 27 janvier 2018 à 15:48.
        
        Appelons D le type censé représenter notre monnaie. Qu'attendons nous de lui ?
        
        D doit pouvoir représenter de façon exacte les nombres de la forme k/100 où k est un entier compris dans un intervalle fixé borné (ici on pourrait se contenter de k inférieur à 1 million de milliards soit 10 puissance 15).
        
        […]
        
        Je m'arrête là pour le fond et je conteste cette partie de la spécification que tu proposes (sinon tout le reste s'ensuit bien, comme il se doit, sur le plan mathématique : je conteste ta première prémisse).
        
        Regardons déjà ce que Dring t'a répondu quand tu lui as proposé les décimaux à virgules fixes avec deux chiffres après la virgule :
        
        Le truc chiant avec les devises, c'est qu'elles n'ont pas toutes 2 décimales. Du coup, est-ce que dans ce code la valeur du delta peut être une variable ? Je crains que non.
        
        et maintenant regardons, par exemple, les règles fixées par la Communauté Européenne lors de l'introduction de l'euro dans la publication The introduction of the euro and the rounding of currency amounts. On y trouve dans la section 3.3 Use of the conversion rate (p. 8) :
        
        The rates have been adopted with six significant figures, e.g. 1 EUR = 40.3399 BEF.
        
        Wherever these conversion rates are used, they will have to be applied exactly, i.e. with six significant figures; no rounding or truncating of the conversion rates is allowed (Article 4(2)).
        
        Parmi les taux de change fixés par la commission, on trouve :
        
        1 euro = 40.3399 francs belges 1 euro = 1.95583 marks allemands 1 euro = 166.386 pesetas espagnoles
        
        personnellement j'appelle cela des décimaux flottants avec 6 chiffres significatifs (et donc le type decimal32, qui a 7 chiffres significatifs, permet de gérer les taux de changes dont la norme est légalement fixée par l'Union Européenne).
        
        Les mêmes règles existent de nos jours pour les conversions avec les monnaie hors zone euro. Celles fixant la gestion des arrondis, les problèmes de double-conversion pour revenir dans la monnaie d'origine y sont également définies.
        
        J'espère que ce simple exemple répond à la demande qui conclut ton commentaire :
        
        Peut-être pourrais-tu nous rappeler précisément ces besoins. J'ai l'impression que ni toi ni moi ne les connaissons précisément. Je fais ce que je peux en raisonnant mais si tu as des choses plus précises n'hésite pas à en faire part, c'est toujours intéressant.
        
        Pour ta partie sur la forme, tu as mal compris ce que je voulais dire.
        
        Mauvaise foi ? On était parti d'erreurs factuelles sur le site d'IBM que tu as mentionné concernant le calcul de 0.70 x 1.05. Ils font deux erreurs: la première sur le résultat du calcul en utilisant des "double".
        
        Il n'y a aucune mauvaise foi, c'est bien un problème d'API. Un programmeur qui a besoin de décimaux veut pouvoir écrire : arrondi moi ce nombre à la deuxième décimal selon telle règle d'arrondis. Autrement dit, il veut quelque chose du genre :
        
        module type Decimal = sig type t val round : int -> t -> t (+) : t -> t -> t (*) : t -> t -> t dec : string -> t end
        
        et si il utilise une module Decimal avec une telle interface, il exige que l'opération suivante retourne 0.74 :
        
        Decimal.(round 2 (dec "0.70" * dec "1.05"))
        
        Toi ce que tu dis, c'est que l'on peut prendre t = float et définir round de façon à ce qu'il se comporte correctement. Ce à quoi je t'ai répondu : personne ne l'a jamais nié, mais le programmeur ne veut pas avoir à faire ça à la main, il veut une bibliothèque qui lui fournisse cela ou un type primitif du langage. Ici le type sera abstrait (en théorie des types on parle de type existentiel¹) ce qui est la base d'un idiome standard en programmation : l'encapsulation. ;-) Et du point de vue de l'utilisateur, rien ne le distingue d'un type primitif : il ne peut rien faire d'autre que de l'utiliser à partir des fonctions exportées par le module.
        
        C'est là toute la distinction entre la représentation abstraite du type de données, déterminée par sa spécification, et la représentation concrète effectivement utilisée par le module pour l'implantation. Je n'ai jamais dit qu'il fallait tout reconstruire à la main, mais seulement que le seul type des entiers naturels permet d'être utilisé pour faire cela, rien de propre au type des flottants binaires.
        
        Je te disais en note de bas de page qu'il y a des articles sur le sujet : utiliser les flottants binaires comme représentation concrète pour implanter la norme IEEE-754 des flottants décimaux. En voici un : Implementing Decimal Floating-Point Arithmetic through Binary: some Suggestions, avec parmi les co-auteurs Jean-Michel Muller que tu as cité dans un de tes commentaires. En voici le résumé :
        
        We propose algorithms and provide some related results that make it possible to implement decimal floating-point arithmetic on a processor that does not have decimal operators, using the available binary floating-point functions. In this preliminary study, we focus on round-to-nearest mode only. We show that several functions in decimal32 and decimal64 arithmetic can be implemented using binary64 and binary128 floating-point arithmetic, respectively. We discuss the decimal square root and some transcendental functions. We also consider radix conversion algorithms.
        
        on les appelle ainsi car ils se définissent par un énoncé de la forme : « il existe un type t tel que … » où la seule chose que l'on sache de lui se trouve dans les ..., c'est-à-dire dans les valeurs et fonctions exportées par le module mais qui cache sa représentation concrète à l'utilisateur afin de maintenir des invariants. ↩
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 27 janvier 2018 à 17:07. Évalué à 2.
        
        Je m'arrête là pour le fond et je conteste cette partie de la spécification que tu proposes (sinon tout le reste s'ensuit bien, comme il se doit, sur le plan mathématique : je conteste ta première prémisse). […devises différentes à prendre en compte]
        
        suivi de
        
        Wherever these conversion rates are used, they will have to be applied exactly,
        
        Si tu dois faire des conversion entre des € et une devise A où 1,000_000 € = 1,500_000 A, il t'apporte quoi le flottant décimal ? Il ne fera pas mieux que le flottant binaire pour la conversion de A vers €.
        Mais de toute façon, ça ne pose aucun problème: tu gères tout dans une monnaie (disons l'euro avec virgule fixe) et convertir d'une devise à l'autre avec 6 décimales exactes comme exigé ne pose pas le moindre problème (mon arrondi au centime en Ada n'était qu'un exemple et rien n'empêche d'aller chercher 6 décimales exactes).
        
        Il n'y a aucune mauvaise foi, c'est bien un problème d'API. Un programmeur qui a besoin de décimaux veut pouvoir écrire : arrondi moi ce nombre à la deuxième décimal selon telle règle d'arrondis. Autrement dit, il veut quelque chose du genre : Decimal.(round 2 (dec "0.70" * dec "1.05"))
        
        Et comment tu lui dis à Python comment il doit arrondir sachant que les règles d'arrondi tu en as quasiment une par pays ! cf https://en.wikipedia.org/wiki/Cash_rounding
        Python ne peut pas connaître toutes ces règles ! L'arrondi ne sera jamais out-of-the-box. La norme IEEE754 (décimale ou non) ne proposera jamais quoique ce soit pour répondre à la diversité de ces règles (et encore heureux !). Tu as une fonction qui permet de faire round ("irlande",4.6789987,2) ?
        
        Toi ce que tu dis, c'est que l'on peut prendre t = float et définir round de façon à ce qu'il se comporte correctement. Ce à quoi je t'ai répondu : personne ne l'a jamais nié, mais le programmeur ne veut pas avoir à faire ça à la main,
        
        Qu'il pleure ou qu'il gémisse, il devra de toute façon le faire car il n'a pas le choix, vu qu'il y a plus de règles d'arrondis dans le monde qu'il n'y a de modes d'arrondi définis par la norme IEEE754 décimale (remarque au passage que cette norme ne propose rien de plus que la norme classique en terme de nombre de modes d'arrondis: 3 modes différents qui ne portent de toute façon que sur le dernier ulp. De toute façon le décimal ne propose rien pour l'arrondi à la mode irlandaise ou norvégienne etc.
        
        Pour synthétiser:
        
        Pour les conversions de devise exactes: le flottant décimal n'apporte absolument rien par rapport au flottant binaire (exemple 1€ <---> 1,5A ça te sert à quoi le flottant décimal pour passer de A à € ?). De toute façon le flottant binaire suffit amplement pour appliquer scrupuleusement l'exactitude au millionième près.
        
        Les règles d'arrondi sont tellement diverses (presque une par pays !) qu'aucune norme ne pourra dispenser le programmeur en économat de produire le code ad hoc.
        
        La seule chose que doit faire le programmeur c'est de coder cet arrondi: tout le reste c'est out of the box en virgule fixe (normal, ça a été fait pour ça).
        
        Si tu utilises du flottant ça peut devenir la foire à la saucisse dans le code si le programmeur "ne veut pas trop se prendre la tête". Au contraire, l'emploi de la virgule fixe façon Ada, empêche le programmeur en amont de faire n'importe quoi: les erreurs grossières ne doivent jamais rester silencieuses (à la compilation, le flottant sera toujours silencieux, au runtime idem, à moins de taper dans du 10 puissance 300 et des brouettes.
        
        Rien de de que dit Muller dans le lien que tu me donnes ne contredit tout cela (ou alors j'ai raté un passage). Le flottant décimal a des utilisations pratiques mais pour les besoins de Dring, ça n'a aucun intérêt.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par kantien le 27 janvier 2018 à 22:21. Évalué à 3. Dernière modification le 27 janvier 2018 à 22:24.
        
        Bon je vais arrêter là, on ne tombera jamais d'accord. Juste deux remarques :
        
        Et comment tu lui dis à Python comment il doit arrondir sachant que les règles d'arrondi tu en as quasiment une par pays ! cf https://en.wikipedia.org/wiki/Cash_rounding
        
        C'est des règles pour les paiements en liquide, ça ne nous concerne pas : personne n'a besoin de machine pour faire cela. Par exemple en Belgique, ils ont retiré les pièces de 1 et 2 cents d'euros, donc si le marchand te sors un montant de 9.98 (via sa machine) alors tu paieras 9.95 : le commerçant comme toi appliquez la règle. ;-)
        
        Rien de de que dit Muller dans le lien que tu me donnes ne contredit tout cela (ou alors j'ai raté un passage).
        
        Ça tombe bien je n'ai jamais soutenu cela, ni cherché à contredire ce que tu faisais avec tes float. Relis bien tout mon laïus sur la différence entre type concret et type abstrait, et tu comprendras que l'article n'avait nullement pour intention de te contredire. Je ne sais pas si c'est moi qui m'exprime mal ou si c'est toi qui a du mal à comprendre, mais il y a un problème de communication entre nous.
        
        Comme il y a un quelqu'un qui moinse sans raison, ni sans s'exprimer, comme je pisse dans un violon en me fatigant à écrire tout un texte sur le principe qu'une bibliothèque doit fournir une API, c'est-à-dire un langage pour un domaine métier spécifique (ou EDSL), en cachant l'implantation concrète des types qu'elles exposent (qui peuvent tout à fait être dans notre cas un float comme tu n'as pas cessé de l'illustrer, et donc je n'ai jamais cherché à te contredire sur ce point là), je préfère arrêter les frais de cette discussion qui ne mène nulle part. Peut être que la célèbre fable de Reynolds sur les deux représentations des nombres complexes à la Bessel (coordonnées polaires) ou à la Descartes (coordonnées cartésiennes) te fera voir où je voulais en venir.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 27 janvier 2018 à 23:54. Évalué à 2.
        
        C'est des règles pour les paiements en liquide, ça ne nous concerne pas
        
        Regarde ce que raconte IBM sur différents modèles d'arrondis : https://www.ibm.com/support/knowledgecenter/fr/SSZLC2_7.0.0/com.ibm.commerce.management-center.doc/concepts/cpiactrounding.htm Le tableau présenté rassemble 11 exemples de modèles qui peuvent se présenter quand on manipule de la monnaie. Il n'y a pas d'API toute faite pour les arrondis dans un quelconque module généraliste décimal et le flottant décimal ne sera d'aucune utilité pour les gérer.
        
        J'essaye juste de te dire que l'implantation en virgule fixe répond à toutes les exigences de ce que veut faire Dring (c'est normal, ça sert à ça):
        
        conversions entre devises avec garantie de respect de la norme de précision en vigueur en Europe.
        
        addition/soustraction et multiplication entier * type D exacte dans les limites de la plage de représentation (10 puissance 12 si besoin).
        
        alertes à la compilation en cas d'écritures grossièrement fausses ou exceptions à l'exécution
        
        application de taux flottants à des éléments de type D avec garantie du respect de la précision pour des taux compris entre 0,001 et 1000 (on peut pousser au besoin)
        
        J'essaye d'expliquer que, concernant le flottant décimal:
        
        il n'apporte absolument rien à l'affaire (rien que pour les conversions entre devises, tu n'as quasiment jamais un rapport décimal pour passer d'une devise à l'autre dans les deux sens). Tu as argumenté pendant plusieurs posts en sa faveur et je n'ai toujours pas compris ce que ça pouvait bien apporter.
        
        il est, comme tout flottant, trop silencieux donc potentiellement dangereux (les erreurs silencieuses, y a rien de pire). Et c'était un besoin de Dring.
        
        Tu évoques la nécessité de disposer d'une API complète, mais la virgule fixe propose tout ce qu'il faut (sauf qu'elle ne peut pas décider à ta place de ta gestion des arrondis). Je ne dis rien de plus.
        
        Voilà, je pense comme toi que ça ne sert plus à grand chose de continuer et qu'on a fait le tour. De mon côté j'ai apprécié, j'ai appris plein de choses, désolé si ce n'était pas le cas pour toi.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par claudex le 28 janvier 2018 à 21:18. Évalué à 6.
        
        Par exemple en Belgique, ils ont retiré les pièces de 1 et 2 cents d'euros, donc si le marchand te sors un montant de 9.98 (via sa machine) alors tu paieras 9.95
        
        Pour info, ce n'est pas comme cité dans l'article Wikipédia. Le commerçant a le choix de pratiquer l'arrondi ou pas. Et c'est valable aussi pour les payements électroniques depuis 2016.
        
        http://www.dhnet.be/conso/argent/l-arrondi-taille-en-pieces-54e37fd035701001a1c87d2f
        https://www.rtbf.be/info/dossier/bon-a-savoir/detail_les-paiements-electroniques-peuvent-etre-arrondis-a-quelles-conditions?id=9179848
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 27 janvier 2018 à 18:22. Évalué à 1.
        
        Complément:
        
        Pour des conversions de devises propres et sûres respectant scrupuleusement la norme européenne:
        
        type change is delta 10.0**(-7) range 0.000_1 .. 1000.0; function Convert (from : change; target : change; value : dec) return dec is ((long_float (target)/long_float (from)) * value);
        
        On voit ici que le fait que long_float soit binaire ou décimal n'apporte rien: le résultat donné sera juste dans les deux cas (car la précision sur le premier quotient
        
        On ajoute volontairement un type change obligeant le programmeur à respecter les bonnes pratiques et pas à faire n'importe quoi dans n'importe quel ordre avec des floats. On ajoute aussi des garde fou (impossibilité de diviser par zéro, et surtout on est explicite. si des débordements on lieu, il y aura levée d'exception (rien n'est silencieux).
        
        On peut de plus garantir que Convert donne le bon résultat (car max_change/min_change est majoré par 1 million et donc le quotient flottant ne fait perdre qu'une précision de 6 digits au long_float (17 chiffres significatifs) et laisse de quoi garantir que round fera exactement ce qu'elle doit faire). C'est là tout l'avantage de mettre des contraintes sur les types et de ne pas prier à chaque fois qu'on manipule des floats sans aucun contrôle.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 29 janvier 2018 à 12:44. Évalué à 4.
        
        Intéressant Xavier ! Je la connaissais pas cette politique d'arrondi pour les caisses électroniques :
        
        Ainsi, si le montant total du ticket de caisse se termine par 0,01 ou 0,02, il sera arrondi à 0 centime. Si le montant se termine par 0,03 ou 0,04 ou 0,05 ou 0,06 ou 0,07, il sera arrondi à 0,5 centimes. Enfin, le montant se terminant par 0,08 ou 0,09 sera arrondi à 0,10 centimes.
        
        Ce passage concernant la gestion des arrondis par la machine de caisse confirme bien qu'il n'existe aucune API toute faite permettant de pratiquer la politique d'arrondi et que le programmeur ne peut se dispenser de coder lui même l'arrondi.
        
        Une API de haut niveau pour gérer ce problème consiste à faire un type générique avec pour paramètres un type delta (virgule fixe) ET la fonction d'arrondi ad hoc.
        Exemple:
        
        -- le fichier de spécifications generic type Decimal is delta <>; -- on fournira, à l'instantiation du package, la précision et la plage with function my_round (float_value : Long_Float) return Decimal; -- et on lui fournit une politique d'arrondi (cf le PS3 en bas de mon post au sujet de l'encapsulation possible du type long_float) package my_general_money is -- on fournit au client un outil pour calculer des taux respectant scrupuleusement la politique d'arrondi fournie par my_round function "*" (rate : Long_Float; value : Decimal) return Decimal; end my_general_money; -- le fichier d'implantation de la fonction "*" package body my_general_money is is function "*" (rate : Long_Float; value : Decimal) return Decimal is ( my_round (rate * Long_Float (value))); end my_general_money; -- Voilà ! fini ! On dispose à ce stade d'une API générique complète pour gérer une monnaie quelconque liée à une politique d'arrondi donnée -- Un programme principal dans un troisième fichier pour tester ce module sur l'euro. Voilà ce qui se passe côté utilisateur de ce module: with ada.text_io; use ada.text_io; -- entrée sorties with my_general_money; -- notre API complète pour créer une monnaie procedure main is -- On instancie une monnaie à nous (virgule fixe) type Euro is delta 0.001 range -10.0**10 .. 10.0**10; -- On se donne une politique d'arrondi (ici l'arrondi par défaut fourni par Ada function round_euro (lf : Long_Float) return Euro is (Euro (lf)); -- on instancie un package pour ajouter à notre Euro une politique d'application d'un taux package Euros is new my_general_money (Euro, round_euro); use Euros; -- Voilà ce que le programmeur a à faire: 3 lignes pour décrire ses contraintes et sa politique d'arrondi. Il a maintenant tout pour jouer avec sa monnaie e1 : Euro := 3.0; -- expression littérale très naturelle pour le programmeur e2 : Euro; rate : Long_Float := 2.0/3.0; -- une baisse de 33.333.... pourcents -- rappelons qu'un taux n'est pas une valeur monétaire mais (idéalement) un réel. begin e2 := rate * e1; put_line (e2'img); -- affichera exactement 2.000 (c'est à dire que la sortie tient compte de la précision en vigueur sans rien avoir à faire end Main;
        
        Ce qu'on gagne à faire ça:
        
        On dispose d'une API complète parfaitement encapsulée de haut niveau où le programmeur fournit simplement sa politique d'arrondi (on peut même en mettre une par défaut si on veut, ou même lui filer dans l'API une dizaine de modèles codées par celui écrit l'API une fois pour toutes).
        
        Le code reflète exactement la nature du problème mathématique. Le code contient du sens et donc:
        
        Le programmeur (client de l'API) est obligé de faire correctement les choses: il est obligé de faire la distinction entre les types des objets qu'il manipule. Il ne peut par exemple pas écrire un Euro * un Euro. Mais il peut bien évidemment écrire un entier * un Euro,ou un Euro +/- un Euro et il est certain que le calcul sera rigoureusement exact. Dans cette approche on peut écrire ce qui a du sens, on ne peut pas écrire ce qui n'en a aucun dans le cadre de l'API fournie.
        
        Il est assuré qu'au moindre calcul hors plage de sa monnaie, une exception sera levée (contrairement au décimal flottant qui serait silencieux: danger !!!)
        
        Il ne peut pas écrire à la main e := 2.0001 sans se prendre une erreur du compilateur qui lui signifie que la valeur entrée est stupide puisqu'elle exige une précision supérieure à celle qu'il a exigée dans son type
        
        Il n'a rien eu à coder à part sa fonction d'arrondi si elle n'est pas standard (c'est bien le minimum légal, sans jeu de mot :) )
        
        Chaque fois qu'un changement de politique d'arrondi se produit, il n'a qu'une seule fonction à coder, il n'a rien d'autre à toucher nulle part dans le code.
        
        On n'a même pas besoin de coder les entrées/sorties: le formatage est géré tout seul parce que ada écrit correctement de la virgule fixe et ça rappelle, à l'affichage, le nombre de chiffres correspondant à la précision souhaitée.
        
        Le client de l'API n'a même pas à faire appel lui même à sa fonction d'arrondi. C'est l'API qui le fait pour lui.
        
        Pour le calcul de taux, que le long_float soit binaire ou décimal n'a aucune importance concernant l'exactitude des résultats : on obtiendra toujours la même chose à la fin avec l'un ou l'autre contrairement à ce qui a été insinué plusieurs fois dans ce fil. Le programmeur n'a même pas à savoir comment c'est géré par Ada: Ada lui garantit simplement que les specs sont respectées.
        
        Ceci répond à tous les souhaits exprimés par Dring (y compris les conversions entre devises); Une API de type Decimal (qui a été mentionnée comme solution pour les problèmes de Dring) ne pourra jamais bénéficier de tous ces avantages car trop silencieuse / permissive (même sémantiquement on peut y écrire Decimal("0.1") fois Decimal("0.000001") sans se prendre le moindre warning puisque Python n'a aucune indication dans le code du 'sens' qu'il faut donner à ces expressions ; Et puis, pour le programmeur, comme le disait Dring, c'est franchement pas agréable de se traîner à chaque calcul l'instanciation d'une classe à partir de chaînes de caractères. Côté client, difficile de faire plus fluide, plus naturel ou plus précis.
        
        PS1
        J'ai mis plus de temps à écrire le texte de ce commentaire qu'à coder l'API (qui prend 5mn).
        PS2
        J'espère que ce post aura clarifié les incompréhensions réciproques.
        PS3
        Si on veut laisser au client de l'API la possibilité de coder son arrondi on ne peut lui cacher le long_float. Mais si on lui fournit une centaine de politiques d'arrondi directement dans notre API, ou si on lui code selon ses souhaits, on pourra même lui cacher le long_float.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 29 janvier 2018 à 13:17. Évalué à 4.
        
        Pour le calcul de taux, que le long_float soit binaire ou décimal n'a aucune importance concernant l'exactitude des résultats
        
        C'est chouette! Et donc si je calcule un truc du genre 0,2% de 1000 milliards d'euros, le genre de blagues qui arrive avec les flottants du type
        
        # printf "%.25f\n" (0.0021 *. 1_000_000_000_000.0);; 2099999999.9999997615814208984375000
        
        n'arrivent pas. (Puisque comme on le voit sur l'exemple la précision est assez grande pour donner le bon résutlat après arrondi.) Le point important est de bien arrondir après chaque multiplication dans la définition de la structure de “float-module,” c'est bien ça?
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par snowball (site web personnel) le 29 janvier 2018 à 14:12. Évalué à 4. Dernière modification le 29 janvier 2018 à 14:14.
        
        C'est exactement ça ! L'API peut parfaitement prévenir l'utilisateur, à la compilation, que le nombre de digits demandé n'est pas suffisant pour garantir l'exactitude du calcul des taux et le client de l'API devra réviser ses exigences à l'instanciation de son type "monnaie".
        
        En gros: tu peux aller en valeur absolue jusqu'à 10 puissance 12 et une précision de 7 digits après la virgule sans problème (c'est largement suffisant pour assurer les exigences européennes de conversion de devises dont parlait Kantien). Tu peux même créer des pré et post conditions dans la fonction "round" pour être averti, par une levée d'exception, que tu demandes l'impossible. Jamais le flottant ne te permettra d'avoir ce niveau de contrôle puisqu'il mange tout ce qu'on lui donne sans broncher.
        
        Et même si on regarde sur le plan mathématique, une analyse rapide montre qu'il est absurde d'utiliser un type decimal flottant codé en hard pour répondre au problème de la représentation de valeurs monétaires. Je m'explique:
        
        on se confronte au phénomène de "cancellation". C'est à dire que si $u=10^{14}$ et $v=10^{-4}$ alors perd quasiment tous ses chiffres significatifs et donc si on multiplie derrière par un entier assez grand, on obtiendra (silencieusement !!) quelque chose de complètement faux. Rien de pire que les erreurs silencieuses (donc détectables uniquement quand la catastrophe s'est produite)
        
        si on note e le nombre de bits occupés par l'exposant dans la représentation machine du flottant (disons sur 64 bits), on voit qu'on n'utilise qu'un tout petit nombre valeurs possibles codées par les e bits (disons 16 pour fixer les idées). C'est à dire que sur les $2^{64}$ valeurs possibles du flottant décimal, seules environ un 64ème de ces valeurs sont utiles. En virgule fixe, on utilise vraiment les $2^{64}$ valeurs possibles. Cette perte d'informations montre à elle seule que le flottant n'est pas adapté à la situation dont on parle.
        
        un dernier avantage concernant les perfs: la virgule fixe c'est de la gestion d'addition/soustraction d'entiers dans le backend FPU. C'est donc bien plus efficace que de manipuler du float au niveau FPU (2 voire 6 fois plus rapide en moyenne suivant le FPU utilisé).
        
        A quel problème informatique répond le concept de virgule fixe ? Réponse: il a été fait spécialement pour gérer un nombre fini de points (de façon exacte) uniformément répartis dans un intervalle borné; typiquement… une monnaie :)
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Dring le 25 janvier 2018 à 22:02. Évalué à 4.
        
        En effet, ça ferait un OVNI difficile à diffuser. Je vais réfléchir à la question cette nuit, puis ma procrastination naturelle fera le reste pour oublier tout ça.
        
        [^] # Re: Il faut bien lire ce qu'on lit!
        
        Posté par Michaël (site web personnel) le 25 janvier 2018 à 23:07. Évalué à 2.
        
        Pour donner l'exemple de Java que tu donnais BigDecimal bd = new BigDecimal(5.5); le plus simple serait sûrement soit de construire une classe spéciale MoneyAmount qui fait ce qu'il faut pour s'initialiser correctement à partir d'un float. Ou bien de définir une sorte de constructeur à BigDecimal, qui fait ce qu'il faut?
  - [^] # Re: Il faut bien lire ce qu'on lit!
    
    Posté par snowball (site web personnel) le 25 janvier 2018 à 10:17. Évalué à 3.
    Dans les années soixante, on avait un langage qui était conçu pour tout ça : le COBOL.
    
    C'est quoi "tout ça" ? C'est là qu'on ne peut plus te suivre. Quelles sont spécifications qui se cachent derrière ce "tout ça" ?
    
    Depuis, plus rien. Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.
    
    Aujourd'hui le langage Ada permet de déclarer des types répondant exactement aux spécifications du COBOL (cf https://en.wikibooks.org/wiki/Ada_Programming/Types/delta )
    Je précise dans ce lien l'endroit qui t'intéresse: https://i.imgur.com/FwGhVBW.png . Au passage, note que tout est "fully specified".
    
    Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
    
    C'est exactement ce que propose Ada.
    
    Exemple:
```
with ada.text_io;use ada.text_io;

procedure my_decimal is 
  type my_dec is delta 0.01 digits 6; -- 6 chiffres significatifs, précision au centième 
  s1, s2, s : my_dec;
begin
  s1 := 1.8;
  s2 := 0.2;
  s := 2.0 - s1 - s2;
  put_line (s'img); -- affiche 0.00
  s1 := 2.0;
  s2 := 3.0;
  s := s1 / s2; 
  put_line (s'img); -- affiche 0.66 (conforme à la spec COBOL avec un écart entre réalité et résultat <0.01)

end my_decimal;
```
    Ada gère la structure de $\mathbb{Z}$ module (c'est à dire que tu peux parfaitement écrire un entier * un décimal)
```
with ada.text_io;use ada.text_io;

procedure my_decimal is 
  type my_dec is delta 0.01 digits 6; -- 6 chiffres significatifs, précision au centième 
  s : my_dec;
begin
  s := 0.01;
  s := 10_000 *  s;
  put_line (s'img); -- Affiche 100.00
end my_decimal;
```
    Mais Ada te prévient à la compilation s'il ne peut être certain que tu veux vraiment manipuler des décimaux en te croyant dans un anneau plutôt qu'un $\mathbb{Z}$ -module):
```
with ada.text_io;use ada.text_io;

procedure my_decimal is 
  type my_dec is delta 0.01 digits 6; -- 6 chiffres significatifs, précision au centième 
  s, s1 : my_dec;
begin
  s := 0.01;
  s1 := 10.0;
  s := 10.0 * s * s1; -- (ligne 9) qui va provoquer une erreur à la compilation
  put_line (s'img);
end my_decimal;
```
    Ne compile pas et te sort :
    my_decimal.adb:9:13: type cannot be determined from context
    my_decimal.adb:9:13: explicit conversion to result type required
    gprbuild: *** compilation phase failed
    
    Dernier point, la prévention ne se déroule pas seulement à la compilation, mais, par défaut, il y a un contrôle, au runtime, des contraintes de dépassements que tu peux évidemment traiter comme tu le veux par la gestion des exceptions ad hoc.
    
    Ne serait-ce pas ce que tu attends ?
# Pas si vite :)

Posté par snowball (site web personnel) le 22 janvier 2018 à 14:11. Évalué à 10. Dernière modification le 22 janvier 2018 à 14:14.

il est possible qu'à un horizon indéterminé mais réel, ce problème soit réglé ou sensiblement atténué et qu'on puisse travailler sur des nombres à virgule flottante sans erreur et sans perte majeure de performance.

Malheureusement non.

Ce système continue à calculer de façon approchée et ne résout pas le "problème" évoqué dans le journal précédent qui traitait de ce sujet.

Par exemple, pour le calcul 2-1.8-0.2, chacun des réels 1.8 et 0.2 sera déjà arrondi dès qu'il sera stocké dans les registres du FPU. Ce qu'ajoute ce système c'est de conserver un majorant des erreurs qui seront (de toute façon) commises (pour l'entrée en mémoire, puis pour les deux opérations) ce qui permet à l'utilisateur d'avoir un encadrement du résultat exact géré par le FPU lui-même.

A noter que le système en question ne s'embarrasse pas de la base 10 et continue à gérer des flottants en base 2 (pour lesquels 0.1 n'est pas représentable en machine).

En fait, ce que je trouve "amusant" dans tous ces échanges, c'est qu'on démontre en faisant un tout petit peu de math, que le souhait d'exactitude est impossible à atteindre, mais que certains veulent continuer à y croire. Comme si la démonstration n'avait pas valeur de vérité. En gros, on revient inlassablement à des problèmes de compréhension des concepts en math.
- [^] # Re: Pas si vite :)
  
  Posté par rewind (Mastodon) le 22 janvier 2018 à 21:19. Évalué à 6.
  
  En fait, ce que je trouve "amusant" dans tous ces échanges, c'est qu'on démontre en faisant un tout petit peu de math, que le souhait d'exactitude est impossible à atteindre, mais que certains veulent continuer à y croire. Comme si la démonstration n'avait pas valeur de vérité. En gros, on revient inlassablement à des problèmes de compréhension des concepts en math.
  
  Est-ce si étonnant à l'heure où des gens croit (j'allais écrire pense mais en fait non) que la Terre est plate ?
  - [^] # Re: Pas si vite :)
    
    Posté par Marotte ⛧ le 22 janvier 2018 à 21:35. Évalué à 3.
    
    Ou que l’électronique est une technologie extra-terrestre…
    - [^] # Re: Pas si vite :)
      
      Posté par .Nicolas. le 22 janvier 2018 à 21:46. Évalué à -8. Dernière modification le 22 janvier 2018 à 21:47.
      
      Ou qu'il y a un complot russe qui truque les élections des démocraties occidentales.
      
      Ah non mince ça c'est le Vrai.
      - [^] # Re: Pas si vite :)
        
        Posté par .Nicolas. le 22 janvier 2018 à 22:00. Évalué à -10.
        
        Et le BCD est une technologie extraterrestre utilisée par les reptiliens terrestres.
        
        La crise économique et financière est donc en fait un complot des reptiliens pour reprendre le pouvoir sur Terre. Après avoir été massacré par les extraterrestres par le moyen d'un astéroïde.
        
        L'astéroïde ayant manqué de peu l'objectif d'extinction totale de l'espèce reptilienne suite à une erreur de calcul en virgule flottante, c'est depuis ce temps là que les extraterrestres ont imposé le BCD.
        
        Même les reptiliens, pourtant leurs ennemis héréditaires, s'y sont mis, assurant ainsi leur hégémonie sur l'économie humaine.
# Ne règle pas le "problème" du journa précédent

Posté par THE_ALF_ le 22 janvier 2018 à 14:47. Évalué à 2. Dernière modification le 22 janvier 2018 à 14:47.

Effectivement, c'est intéressant, mais ne réglera pas les "problèmes" identifiés dans le journal précédent. En gros, il semble s'agir d'un processeur capable de propager les erreurs de calcul dus aux arrondis "hardwares". En soit très intéressant, mais dans la cas donné, on n'aurait pas 2-0.8-1.2 = 0 mais plutôt quelque chose comme 2-0.8-1.2 = 0 ± 1e-17
- [^] # Re: Ne règle pas le "problème" du journa précédent
  
  Posté par snowball (site web personnel) le 22 janvier 2018 à 14:51. Évalué à 4. Dernière modification le 22 janvier 2018 à 14:53.
  
  D'après ce que j'ai lu, il donnera plutôt 2-0.8-1.2 = -5.551115123125783e-17 ± 3e-17
  (et même sûrement plus que 3e-17 vu que les trois nombres ont des exposants différents, il y a phénomène d'absorption)
  - [^] # Re: Ne règle pas le "problème" du journa précédent
    
    Posté par gUI (Mastodon) le 22 janvier 2018 à 17:04. Évalué à 2.
    
    Je ne sais pas ce qu'il donnera, mais j'espère juste que le résultat encadrera 0 tout de même (ce qui n'est pas le cas de -5.551115123125783e-17 ± 3e-17 me semble-t-il)
    
    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
    - [^] # Re: Ne règle pas le "problème" du journa précédent
      
      Posté par snowball (site web personnel) le 22 janvier 2018 à 17:31. Évalué à 1.
      
      C'était déjà le cas avant comme le stipule IEEE754 (elle te dit que tu perds au maximum 1ulp par addition sur des flottants de même exposant et au minimum 3ulp si tu additionnes 3 flottants distants de 1 au niveau de l'exposant). L'avantage de ce système n'est pas pour trois additions mais plutôt pour des calculs du genre $\sin(2^{64})$ où il faut pas mal se casser la tête pour trouver un majorant de l'erreur.
      - [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par .Nicolas. le 22 janvier 2018 à 18:52. Évalué à -5. Dernière modification le 22 janvier 2018 à 18:53.
        
        Tiens c'est sympa comme exemple. Comment ils font pour calculer l'erreur de ce truc ?
        
        On évalue cos(2⁶⁴ ) ?
        
        ….
        
        Heu wait…
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 20:07. Évalué à 3.
        
        Bah, en l'occurrence, le système dont il est question dans cet article prévient l'utilisateur que le résultat qu'il donne est vrai à … 2 près :)
        
        De son côté IEEE754 donne le même résultat et c'est à l'utilisateur d'anticiper que la réduction modulo pi de $2^{64}$ dans l'intervalle -pi/2…pi/2 engendre des erreurs d'approximation tellement grandes sur l'argument que le résultat donné ne pourra être vrai qu'à … 2 près.
        
        En gros les deux donnent le même résultat, avec, évidemment aucun chiffre significatif exact, mais le premier ne le fait pas silencieusement à la différence du second.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par .Nicolas. le 22 janvier 2018 à 21:51. Évalué à -5.
        
        Le cas est trop violent. Ce que je voulais dire c'est : est-ce que quelqu'un sait comment est évaluée la borne ? Parce que l'évaluation de la borne n'est potentiellement pas moins entachée d'erreur que le résultat lui-même…
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 22:22. Évalué à 4.
        
        J'ai choisi un cas "violent" pour montrer ce qu'apporte ce système à l'utilisateur (il est très agréable de connaître l'intervalle de confiance d'un résultat).
        
        L'évaluation de "la" borne est également soumise aux problèmes d'approximation, évidemment. Mais comme tu cherches des majorants de l'erreur, le calcul exact d'un "meilleur" majorant n'est pas nécessaire (à chaque fois on peut arrondir au dessus si on ne peut pas faire mieux).
        Il n'y a évidemment aucune promesse d'exactitude dans ce système, juste des indications de confiance correctes, mais c'est pas mal (à condition que ça soit fait par le FPU lui-même évidemment).
      - [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par gUI (Mastodon) le 22 janvier 2018 à 19:04. Évalué à 1.
        
        C'était déjà le cas avant comme le stipule IEEE754
        
        Je reste très étonné que IEEE754 te donne un résultat approché dont l'encadrement n'encadre même pas le bon résultat. Mais bon, c'est toi le spécialiste.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 19:16. Évalué à 3.
        
        J'ai dit le contraire de ce que tu dis puisque je viens justement d'expliquer que la taille de l'intervalle d'encadrement obtenue avec des flottants classiques (pour le calcul de 2-1.8-0.2) est supérieure à 3 ulp (et donc cet encadrement contient 0).
        Ce n'est pas la peine d'être un spécialiste, puisque ça s'apprend dès le premier cours d'arithmétique flottante. C'est bien d'ailleurs pour cela que, dans le journal précédent, les intervenants ont précisé à plusieurs reprises que "le résultat donné par python était juste car conforme à ce que stipule la norme en terme de précision".
        Comme je n'ai pas envie de repartir dans une conversation trollesque et que tout a déjà été dit, je m'arrête là dans la lutte d'égo vers laquelle tu sembles à nouveau te diriger.
        Bonne continuation.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par gUI (Mastodon) le 22 janvier 2018 à 20:23. Évalué à 4.
        
        J'avais mal compris ta réponse.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 20:30. Évalué à 2.
        
        Pas de souci.
      - [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par freem le 22 janvier 2018 à 21:22. Évalué à 3.
        
        Juste une question: c'est quoi, un ulp?
        
        Serait-ce le bruit que fait le processeur quand on lui file des flottants, de la même façon que les personnages de BD font gulp quand il y a un truc qu'ils vont pas apprécier, mais en plus rapide donc on entend pas le g?
        Je déconne, certes, mais pas sur la question originelle :) si quelqu'un peut vulgariser le terme… me suis toujours méfié des flottants comme de la peste, parce que je ne sais jamais comment déterminer le delta qui permets de considérer une égalité entre 2 flottants… d'ailleurs, on dit qu'il faut pas utiliser operator== entre 2 flottants, mais est-t-on bien assuré que 2 nombres, après 2 calculs complexes, soient correctement considérés inférieurs dans le bon ordre par le CPU? (j'aurai bien dis l'UA, mais je ne suis pas sûr que ça traite les flottants…)
        
        Autre question, les flottants réels sont-ils bien plus rapides qu'une approche à virgule fixe? De mon petit bout de lorgnette, cette assertion que j'ai lue me semble étrange: au mieux, je crois savoir que ces nombres sont manipulés par des puces différentes, et donc en parallèle, mais de la à considérer ça comme plus rapide dans l'absolu? Et si ce n'est pas le cas, pourquoi toujours utiliser des flottants réels dans la 3D? La précision semble aléatoire, seule la vitesse semble potentiellement intéressante d'un point de vue factuel. Le manque de précision ne serait-il pas, justement, une fonctionnalité intéressante des réels (ça permets des optimisations, et puis, un flou, ça permets de donner une meilleure illusion de réalisme qu'une ligne bien nette)?
        
        Oups… c'est fourre-tout du coup. Mea culpa.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 22:40. Évalué à 1.
        
        https://en.wikipedia.org/wiki/Unit_in_the_last_place
        
        En gros, un flottant s'écrit sous la forme $2^e (1+k.2^{-f})$ où e est un entier (l'exposant) et k est un entier compris entre 0 et . Chez les double, on prend f=52 (52 bits de mantisse pour représenter k, 11 bits pour représenter l'exposant et 1 pour le signe).
        
        Par définition, $1ulp =2^{e-f}$ c'est à dire l'écart minimal entre deux flottants de même exposant.
        
        Quand tu écris x=1.5, tu as et donc, pour les flottants correspondants, $1ulp=2^{-52}$ soit environ 2e-16.
        
        Si maintenant tu considères x=3, tu as et donc pour les flottants correspondants, $1ulp=2^{1-52}=2^{-51}$ soit environ 4e-16. Etc.
        
        La valeur d'un ulp dépend directement de l'exposant.
        
        Une bonne façon de voir les flottants est le "râteau réglable". Je m'explique: le nombre de dents c'est (où f désigne toujours le nombre de bits de la mantisse), c'est donc fixé. Par contre, en jouant sur la valeur de e, tu peux modifier l'écart entre deux dents successives (en multipliant/divisant cet écart successivement par 2). Un ulp c'est l'écart entre deux dents pour un réglage e du râteau donné.
        
        En espérant avoir été clair.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par freem le 22 janvier 2018 à 23:02. Évalué à 4. Dernière modification le 22 janvier 2018 à 23:05.
        
        Question qui n'a rien à voir avec le sujet:
        
        y'a que chez moi que c'est illisible?
        Les mots sont séparés par des blancs de taille variable, qui semble dépendre de la taille de l'expression contenue par ce que je suppose être un type de rendu mathématique).
        
        Je suis actuellement en train d'utiliser vivaldi, basé sur chromium, dans Devuan testing. Le résultat est identique quand j'utilise chromium. Je reboot le temps de tester avec voidlinux (la version basée sur musl pour le coup, pour laquelle j'ai au moins un firefox, et probablement un chromium)…. je risque juste de me faire jeter à l'édition.
        
        [edit]
        Aussi illisible via chromium sous void, mais pas sous firefox?
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 23:07. Évalué à 1.
        
        Sous firefox j'ai ça: https://i.imgur.com/AYr9bjO.png
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par freem le 22 janvier 2018 à 23:08. Évalué à 2. Dernière modification le 22 janvier 2018 à 23:10.
        
        Post-edit: c'est aussi ce que j'ai avec firefox, je me demande si je suis le seul a avoir le problème avec d'autres navigateurs (basés sur le même moteur de rendu, pour le coup)?
        
        Hop, suis con, j'ai pas mis de imgur du coup:
        
        https://imgur.com/a/FTPKG
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 23:19. Évalué à 1.
        
        C'est une des raisons pour lesquelles je préfère firefox à chromium :)
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par freem le 22 janvier 2018 à 23:21. Évalué à 3. Dernière modification le 22 janvier 2018 à 23:22.
        
        Ma foi, je croyait naïvement que l'avantage du web-based sur le natif était la portabilité et le rendu uniforme peu importe la machine… oups, pardon, je suis en avance de 5 jours :)
        
        Je voudrai juste confirmation pour faire une entrée de suivi, ceci dit, tant que je tiens ce problème. Je l'ai déjà rencontré plusieurs fois et avec divers browsers, mais il est ici particulièrement évident et je voulais savoir si c'est lié à mon système avant de flooder.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par kantien le 23 janvier 2018 à 00:00. Évalué à 2.
        
        Tu devrais ouvrir une entrée dans le suivi, ça ressemble à un problème d'interprétation du CSS (il y a des erreurs dans la mise en page et l'insertion des images correspondant aux formules LaTeX dans le texte).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par freem le 23 janvier 2018 à 01:22. Évalué à 2.
        
        Ben, je voulais avoir confirmation par une autre moule, que ce ne soit pas un truc local :) je ferais ça demain.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par pulkomandy (site web personnel, Mastodon) le 23 janvier 2018 à 09:23. Évalué à 2.
        
        Même problème ici (Vivaldi, Windows) dès qu'il y a des formules mathématiques dans un post.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par freem le 24 janvier 2018 à 14:02. Évalué à 2.
        
        done.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 22 janvier 2018 à 22:58. Évalué à 2.
        
        Pour ta deuxième question (comparaison virgule fixe/virgule flottante):
        
        Chaque approche a un intérêt propre directement lié à ce que veut faire l'utilisateur.
        
        En gros la virgule fixe sert à représenter uniformément les réels d'un intervalle fixe a;b. C'est donc du "râteau fixe" où les nombres sont uniformément répartis (de la forme $a+ (b-a) k 2^{-f}$ où est un entier compris entre 0 et ). Bref, manipuler de la virgule fixe, c'est quasiment comme manipuler des entiers avec des ulp constants égaux à $(b-a)2^{-f}$ . L'avantage c'est que ça fournit de l'exactitude dans [a;b] pour des additions/soustractions (c'est super pour les manipulations monétaires).
        
        Par contre, tu n'as aucune dynamique ni vers 0+ ni vers $+\infty$ . Par exemple, la moitié d'un ulp donnera directement 0. Et tu resteras coincé entre a et b. En science, la dynamique est essentielle, l'exactitude sur une machine, est une illusion: on choisit naturellement les floats. Le banquier choisir naturellement la virgule fixe.
        
        La plupart des langages évolués ont des modules pour gérer la virgule fixe (d'ailleurs souvent à partir des flottants !).
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par .Nicolas. le 22 janvier 2018 à 23:33. Évalué à -10.
        
        Tu as fais évoluer ton discours l'air de rien. Dommage que tu n'as pas pu t'empêcher d'insulter.
        
        Donc tu connais maintenant le tarif.
        
        encore une fois tu dis de la bonne grosse daube. Alors je me répète : la dynamique en sciences, c'est le mal absolu. Jamais. Même pas en rêve. Oublie.
        
        EN CALCUL NUMÉRIQUE ON NOR-MA-LISE.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par snowball (site web personnel) le 23 janvier 2018 à 00:21. Évalué à 7.
        
        Commence déjà par TE normaliser, te calmer, clarifier ta pensée et donner des exemples précis de ce que tu tentes d'exprimer à travers des expressions tellement raccourcies qu'elles n'ont absolument aucun sens.
        
        En calcul numérique on utilise des flottants car ils permettent de la dynamique. Cette notion est essentielle. Si tu ne vois pas ce qu'en calcul numérique on appelle la dynamique tu peux toujours aller lire ce document http://perso.univ-perp.fr/guillaume.revy/teaching/201516/ValidationNumerique/C1-ValidationNumerique.pdf (page 23/37) ou ici http://perso.ens-lyon.fr/jean-michel.muller/Ecole_PRCN_Muller.pdf (page 2). Tu y apprendras ce qu'on appelle la dynamique, à quoi ça sert, pourquoi c'est indispensable en calcul numérique.
        
        Je ne retire pas un iota (ni un ulp :) ) de ce que j'ai dit depuis le début sur ces sujets, tout simplement parce que ce ne sont pas mes convictions personnelles, mais
        juste des maths basiques que tu trouveras dans n'importe quel cours d'introduction ou d'approfondissement d'analyse numérique. Ces idées basiques se fichent bien de quelconques considérations hystérico-égotiques vers lesquelles tu veux systématiquement emmener les discussions.
        
        Je ne suis responsable ni de des frustrations ni de ton mal être. Trouve toi un autre camarade sur qui passer tes nerfs. Fin de partie pour moi concernant tes interventions/agressions.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par .Nicolas. le 23 janvier 2018 à 13:06. Évalué à -10. Dernière modification le 23 janvier 2018 à 13:07.
        
        Nan mais lol, t'es un sketch sur patte.
        
        Muller ? Tu viens d'où ?
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par .Nicolas. le 23 janvier 2018 à 18:24. Évalué à -10.
        
        Fin de partie pour moi concernant tes interventions/agressions.
        
        Chiche ?
        
        Tu de rends bien compte que ta "blague" sur le corps saignant est passible de poursuite pénale ?
        
        Quant à ta persistance à vouloir me faire passer pour un ignorant de la discipline… C'est de ton niveau argumentaire. Peu importe que j'ai eu à travailler sur quelques-uns des codes scientifiques majeurs de ma discipline… utilisé par des milliers de scientifiques et d'analystes numériques de par le monde… C'est pas un obscur prof de fac qui va m'apprendre quoi que ce soit, surtout quand le dit prof a un gros pb psycho (tu devrais consulter sérieux, entre ton agression et le fait que tu me prend pour ton étudiant t'es chtarbé). Le pire c'est que tu viens ensuite te poser comme une fleur pour faire la pleureuse. Sérieux y'a un truc qui tourne pas rond chez toi t'en tiens une couche.
        
        Tu ne sais pas ce que c'est que la normalisation ? M'étonnes pas. T'es complètement incompétent. Nul à chier. C'tout.
        
        [^] # Re: Ne règle pas le "problème" du journa précédent
        
        Posté par .Nicolas. le 23 janvier 2018 à 18:45. Évalué à -8. Dernière modification le 23 janvier 2018 à 18:46.
        
        Allez un petit indice pour t'aider.
        
        Un de tes commentaires démontre pkoi exploiter la "dynamique" des flottants est une idée de merde. Et pkoi tous les codes numériques sérieux sont normalisés.
# Un papier intéressant sur l'arithmétique flottante et la comparaison avec celle des intervalles

Posté par snowball (site web personnel) le 23 janvier 2018 à 18:52. Évalué à 3.

Pour ceux qui sont intéressés, entre autres, par les coûts liés à l'implantation du système dont il est question dans ce journal: http://perso.ens-lyon.fr/nathalie.revol/talks/sieste-NR-11.pdf