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. . Évalué à -10.
Bloub
[^] # Re: Toi Tu vas avoir des problèmes avec le corps enseignant ;)
Posté par Dr BG . É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) . É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. . Évalué à -10.
Plop
# Liens
Posté par ®om (site web personnel) . É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) . Évalué à 8.
C'est un texte intéressant, mais à mon avis il n'identifie pas clairement le problème.
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 . Évalué à 8.
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
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) . É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) . É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 :)
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 . É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) . É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. . É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) . Évalué à 10. Dernière modification le 22 janvier 2018 à 10:02.
Traduction libre:
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:
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)
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 . Évalué à 8.
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é :
À 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 Cauchy1, 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.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) . É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 . Évalué à 5.
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) . É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 . É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) . Évalué à 3.
C'est coquin, un doigt.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . É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.
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 . Évalué à 5.
Permets-moi de t'arrêter (enfin, rétrospectivement, et j'ai une bonne raison physique pour ça) sur ce point:
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…)?
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 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.
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 . Évalué à 1.
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 :
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…
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 :
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 . Évalué à 4.
Utilise Haskell, avec son mécanisme de type classes il a de la surcharge sur l'interprétation des littéraux.
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) . É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.
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) . Évalué à 6.
À 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.
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*216 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) . É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 . É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) . Évalué à 5.
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 . Évalué à 5. Dernière modification le 28 janvier 2018 à 09:04.
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 . Évalué à 6. Dernière modification le 22 janvier 2018 à 23:53.
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.
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 . Évalué à -3.
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) . É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) . Évalué à 6.
Ç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) . Évalué à 3.
Ç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 . Évalué à 6.
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) . É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) . Évalué à 8.
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 . Évalué à 10. Dernière modification le 23 janvier 2018 à 15:41.
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 relais1).
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 2. Mais on pourrait tout aussi bien appelé 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 haut3. L'étude de la totalité de ces processus calculatoire, de leurs propriétés, du fait que les deux (voire trois) définitions de 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 (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) . Évalué à 4.
Très sympa ton com'.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Michaël (site web personnel) . Évalué à 3. Dernière modification le 23 janvier 2018 à 17:04.
Pour le plaisir de digresser, je ne pense pas que qu'on puisse vraiment procéder de cette façon, parceque l'algorithme en question utilise déjà 𝜋 puisqu'on ne sait pas construire les polygones réguliers autrement qu'en disant que le polygone régulier à n côtés inscrit dans le cercle unité a pour sommets
ce qui utilise 𝜋 (même quand on le déguise en 360 degrés, ce n'est que grâce à la fonction exponentielle que l'on sait mesurer les angles). Si on veut se passer de l'exponentielle – si on dispose de l'exponentielle, autant définir 𝜋 en disant que c'est le premier zéro positif du sinus – en gardant l'approche par les périmètres on peut utiliser des polygones inscrits et circonscrits plus faciles à construire que les polygones réguliers (en faisant une construction récursive qui permet de calculer itérativement les périmètres).
En revanche, ce qui est très “facile” (il faut juste croire très fort que la théorie de la mesure c'est facile ;) ) est de voir que la surface d'un cercle ne dépend que du carré de son rayon: par translation on se ramène au cas où nos cercles sont de même centre et donc homothétiques de rapport le rapport des rayons. Les pavages (par des carrés) par excès ou par défaut de ces cercles se correspondent mutuellement et comme la surface d'un carré change dans une homothétie par le carré du rapport d'homothétie on peut conclure, en notant 𝜋 la surface du cercle unité, que la surface d'un cercle de rayon R est . Pour faire le lien avec le périmètre du cercle et l'exponentielle on utilise la formule de Green-Riemann (Stokes).
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par snowball (site web personnel) . É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) . Évalué à 3.
C'est vrai qu'on peut se contenter de faire le calcul mais remarquer que la surface de quelque chose change en lorsque cette chose subit une homothétie de rapport est quand-même une remarque importante. ;) Et puis c'est vraiment un point de détail d'expression mais je pense que c'est quand-même plus satisfaisant si on se donne la peine de dire quelque part que “Pi est la surface d'un disque unité.”
À la fac on avait tout fait avec la fonction exponentielle, du genre “regardez ma belle fonction analytique” puis on déroule tout pour définir pi comme le premier zéro positif de la fonction sinus, puis on calcule le périmètre (facile) et l'aire en faisant le changement trigo adéquat dans ton intégrale. C'est très rapide mais tombe un peu du ciel. On peut aussi partir de la géométrie pour définir le sinus et cosinus comme les coordonnés d'une paramétrisation unitaire du cercle, etc. mais c'est nettement plus épique de démontrer toutes les propriétés “bien connues” de ces objets! (notamment par le bagage théorique nécessaire!)
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par snowball (site web personnel) . Évalué à 2.
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 R2, 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 R2 en rajoute une couche). Avec l'âge, j'évite de sortir le marteau piqueur pour écraser une mouche, sûrement pour économiser mes lombaires :)
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).
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 ez 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) . Évalué à 2.
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) . É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 !! :) :)
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Michaël (site web personnel) . Évalué à 3.
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) . Évalué à 2.
Espèce de jeunot va ! :)
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Michaël (site web personnel) . É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 . Évalué à 3. Dernière modification le 24 janvier 2018 à 00:59.
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 . 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 implantable sur machine. C'est un peu comme quand les pythagoriciens on découvert l'irrationnalité de (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é :
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é :
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) . Évalué à 2.
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 ).
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 . Évalué à 3.
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.
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 . 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) . Évalué à 1.
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) . Évalué à 3.
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.
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 . Évalué à 4.
Oui et cela sans aucun soucis, voir cette proposition d'Archimède :
Dans le même traité, il donne une approximation de 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 2n 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 . Évalué à 3.
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) . Évalué à 3.
C'est tout à fait juste. Je mettrais juste un bémol quand tu dis ça:
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 -module pas l'anneau.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Michaël (site web personnel) . É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) . Évalué à 3.
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) . Évalué à 5.
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) . É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) . Évalué à 5.
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) . É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) . Évalué à 5.
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:
(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 . É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) . Évalué à 3.
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) . É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 . Évalué à 5.
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) . Évalué à 1.
Pour un flottant décimal comme évoqué dans ton lien, que va provoquer l'affectation 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 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:
PS
Je ne sais pas si on s'est bien compris
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par kantien . Évalué à 3.
Le résultat escompté en base 10
soit .
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
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) . Évalué à 6.
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 . É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) . Évalué à 3.
Tu as raison, ma citation est un peu “bizarre par excès” si on peut dire. :)
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) . É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é
Alors si tu écris
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
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . É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) . Évalué à 2.
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 . Évalué à 3.
Sauf que COBOL propose des décimaux à virgule flottante. ;-)
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 :
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) . Évalué à 1. Dernière modification le 26 janvier 2018 à 16:18.
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) . É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:
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 () 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 . Évalué à 3.
Non, ce n'est pas cela qu'il cherche à illustrer mais l'arrondi d'une opération à la deuxième décimale.
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.
extrait de la documentation de la classe BigDecimal. Un BigDecimal à la forme :
où
mant
est un entier signé de précision arbitraire etexp
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) . Évalué à 1. Dernière modification le 26 janvier 2018 à 20:26.
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.
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.
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 ?).
Et pourquoi donc ? Si tu as une valeur approchée à 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.
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 à près (appelons ce type D).
En sortie on veut du décimal y à 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 . Évalué à 2. Dernière modification le 26 janvier 2018 à 23:34.
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 :
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é).
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.
Si tu veux l'implanter en utilisant des flottants binaires comme représentation concrète1, libre à toi, tant que tu respectes l'API décrite dans la norme : c'est de cela dont ont besoin les programmeurs.
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) . É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 ?
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
Trois commentaires
Sur la forme
Tu me cites:
ce qui me semble être une évidence et refléter ce que tu as fait en python. Puis tu me réponds:
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 !
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:
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)
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 . Évalué à 3. Dernière modification le 27 janvier 2018 à 15:48.
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 :
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) :
Parmi les taux de change fixés par la commission, on trouve :
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 :
Pour ta partie sur la forme, tu as mal compris ce que je voulais dire.
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 :
et si il utilise une module
Decimal
avec une telle interface, il exige que l'opération suivante retourne0.74
:Toi ce que tu dis, c'est que l'on peut prendre
t = float
et définirround
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 existentiel1) 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é :
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) . Évalué à 2.
suivi de
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).
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) ?
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:
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par kantien . É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 :
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. ;-)
Ç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) . Évalué à 2.
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):
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 . Évalué à 6.
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) . Évalué à 1.
Complément:
Pour des conversions de devises propres et sûres respectant scrupuleusement la norme européenne:
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par snowball (site web personnel) . Évalué à 4.
Intéressant Xavier ! Je la connaissais pas cette politique d'arrondi pour les caisses électroniques :
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:
Ce qu'on gagne à faire ça:
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) . Évalué à 4.
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
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) . É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:
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 . É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) . É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écialeMoneyAmount
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) . Évalué à 3.
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" ?
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".
C'est exactement ce que propose Ada.
Exemple:
Ada gère la structure de module (c'est à dire que tu peux parfaitement écrire un entier * un décimal)
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 -module):
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) . Évalué à 10. Dernière modification le 22 janvier 2018 à 14:14.
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) . Évalué à 6.
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 ⛧ . Évalué à 3.
Ou que l’électronique est une technologie extra-terrestre…
[^] # Re: Pas si vite :)
Posté par .Nicolas. . É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. . É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_ . É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 comme2-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) . É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) . É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) . É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 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. . É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(264 ) ?
….
Heu wait…
[^] # Re: Ne règle pas le "problème" du journa précédent
Posté par snowball (site web personnel) . É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 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. . É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) . É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) . Évalué à 1.
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) . É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) . É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) . Évalué à 2.
Pas de souci.
[^] # Re: Ne règle pas le "problème" du journa précédent
Posté par freem . É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) . Évalué à 1.
https://en.wikipedia.org/wiki/Unit_in_the_last_place
En gros, un flottant s'écrit sous la forme 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, 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, soit environ 2e-16.
Si maintenant tu considères x=3, tu as et donc pour les flottants correspondants, 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 . É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) . É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 . É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) . É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 . É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 . É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 . É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) . É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 . Évalué à 2.
done.
[^] # Re: Ne règle pas le "problème" du journa précédent
Posté par snowball (site web personnel) . É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 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 à . 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 . 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. . É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.
[^] # Re: Ne règle pas le "problème" du journa précédent
Posté par snowball (site web personnel) . É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. . É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. . Évalué à -10.
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. . É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) . É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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.