Calcul décimal

[Neo_13]

Salut,

Quelqu'un se souvient des raisons qui ont poussé à ne pas faire de hard de calcul décimal ?

[newbie06]

Tu parles de BCD?

[Neo_13]

Oui

[Møgluglu]

Quelqu'un se souvient des raisons qui ont poussé à ne pas faire de hard de calcul décimal ?

Non je me souviens pas, j'étais pas né.

Jusque dans les années 70 une bonne partie des ordinateurs utilisaient la base 10, les autres la base 2 ou la base 16 ou 8, ou encore la base 3 (SETUN).

Les raisons qui ont conduit à l'abandon de la virgule flottante décimale au profit du binaire incluent :
- l'efficacité du stockage par rapport au BCD, qui était à la base de quasi toutes les implémentations d'époque,
- la possibilité d'avoir le 1 implicite au début de la mantisse qui fait gagner 1 bit (très important)
- un certain nombre de problèmes théoriques qu'on ne savait pas encore résoudre dans des bases composites (quand la base n'est pas une puissance d'un nombre premier), du genre l'arrondi correct de la division si je me souviens bien.
- même pour les problèmes qu'on savait résoudre, le fait que beaucoup de choses se goupillent mieux en base 2 et permettent d'économiser quelques transistors et instructions.

Aujourd'hui, plus aucun de ces arguments n'est valable. IBM pousse très fort pour du flottant décimal en matériel et a commencé à en mettre dans le Power 6/7. Intel tire aussi très fort, mais dans l'autre sens en insistant pour une implémentation logicielle.
Résultat, IEEE 754-2008 normalise 2 codages différents des flottants décimaux pour ne vexer personne (DPD et BID).

Tu parles de BCD?

Pas forcément, BCD n'est qu'un codage possible de nombre entiers décimaux. D'ailleurs, aucun des 2 formats décimaux d'IEEE 754-2008 n'est basé (directement) sur BCD.

[Neo_13]

(c'est évidemment une réaction au topic sur les vomissures d'excel)

[fefe]

Salut,

Quelqu'un se souvient des raisons qui ont poussé à ne pas faire de hard de calcul décimal ?

Humm, humm, comment dire. Integre au x86 depuis la premiere version...
http://en.wikipedia.org/wiki/Intel_BCD_opcode

Ok, pas necessairement tres complet ou utile, mais tu as du hard qui le fait depuis 30 ans...

[Neo_13]

Donc Excel (entre autres) compte faux exprès.

[Møgluglu]

Excel a besoin de virgule flottante, donc le fait que le CPU sache faire de l'entier décimal n'avance pas à grand-chose.

Les implémentations efficaces de FP décimal (genre Intel) ne sont pas basées sur BCD et certainement pas sur les instructions BCD du x86...

Pour Neo, VBA supporte le type Decimal, qui correspond au Decimal128 d'IEEE 754 et c'est le bien.
Edit: euh en fait non, c'est un truc propriétaire pas IEEE, mais euh c'est bien quand-même...

[Neo_13]

D'ailleurs, pourquoi ((4/3-1)*3-1) != ((4/3-1)*3)-1 ? J'ai même du mal à comprendre comment on peut faire un truc pareil.

[Møgluglu]

Concernant la distinction flottant/entier décimal, j'ai l'impression que la confusion est maintenue plus ou moins délibérément par les défenseurs du décimal chez IBM pour justifier le type Decimal128 auprés de l'IEEE.

Leur argumentation est : pour implémenter les langages existants [sort une longue liste d'obscurs langages exotiques utilisés sur mainframe z1234 entre 1966 et 1968], on a besoin de virgule flottante et on a besoin d'au moins 30 chiffres décimaux, donc il nous faut le type Decimal128 à 34 chiffres.

Mais si on regarde leurs données de plus près, tous les systèmes utilisant plus de 15 chiffres sont des types virgule fixe, les chiffres en plus étant là juste pour combler le manque de dynamique. Donc on aurait très bien pu s'en tirer avec de l'entier décimal 128-bit et du flottant 64-bit.

Le flottant 128-bit est là juste à simplifier la vie des ingés d'IBM... Mais au moins on a de la quad-precision sur le Power.

[newbie06]

MS et les standards...

Les derniers POWER ne font pas déjà le FP décimal en hard ? En tout cas c'est dans l'ISA 2.05 : http://www.power.org/resources/reading/

[Neo_13]

Parce que de ce que j'en comprend, le décimal ne permet pas la chie ci dessus cité.

[Møgluglu]

D'ailleurs, pourquoi ((4/3-1)*3-1) != ((4/3-1)*3)-1 ? J'ai même du mal à comprendre comment on peut faire un truc pareil.

L'idée qui est au fond de l'esprit tourmenté des gus de Microsoft, c'est que les utilisateurs ne doivent pas se rendre compte qu'Excel ne calcule pas en décimal, et qu'il faut faire semblant que ce soit le cas.

Donc à l'affichage, ils trichent en arrondissant le nombre binaire calculé en interne à un nombre décimal proche qui tombe rond, même si c'est pas le plus proche et si la conversion n'est pas réversible.
Page 8 de http://www.eecs.berkeley.edu/~wkahan/ARITH_17.pdf, WK donne des exemples de nombres qui s'affichent pareils mais sont distincts et ont des propriétés différentes.

C'est mal, mais ce qui est pire c'est qu'ils font pas ça juste pour l'affichage, ça s'étend aux comparaisons pour ne pas surprendre les gens comme XWolverine qui s'attendent (légitimement) à ce que 0.1 fasse bien 0.1. (Mais que dans les cellules Excel, pas dans VBA, ça serait pas marrant s'il y avait une cohérence.)

Mais pour pas perdre de précision dans les calculs intermédiaires, ils ont inventé la parenthèse magique qui inhibe l'arrondi cosmétique.
Et régulièrement toute la merde qu'ils ont essayé de mettre sous le tapis ressort, parce que du binaire déguisé en décimal c'est juste pas du décimal et c'est pire que du binaire.

Les derniers POWER ne font pas déjà le FP décimal en hard ? En tout cas c'est dans l'ISA 2.05 : http://www.power.org/resources/reading/

IBM pousse très fort pour du flottant décimal en matériel et a commencé à en mettre dans le Power 6/7.

[ducon]

Pour le BCD, il me semble que comme on perdait 6 bits sur 16 (ça fait beaucoup), ben on a préféré utiliser une base où tous les bits servaient.

[newbie06]

Rah forcément si t'écris pendant que je réponds en cherchant les réfs

[Neo_13]

Et régulièrement toute la merde qu'ils ont essayé de mettre sous le tapis ressort, parce que du binaire déguisé en décimal c'est juste pas du décimal et c'est pire que du binaire.

Comment c'est beau !

Mais plus j'utilise Excel et plus je hais MS.

Je vais plagier un cousin, en exprimant 3 souhaits :
- que ça marche
- que ça marche toujours
- que ça marche toujours de la même façon.

En particulier, si la répétabilité est au prix du décimal, vu les performances de calcul modernes, est-ce vraiment un problème ?

[Møgluglu]

Pour le BCD, il me semble que comme on perdait 6 bits sur 16 (ça fait beaucoup), ben on a préféré utiliser une base où tous les bits servaient.

0,83 bits sur 4 plutôt? (log(10) / log(16) pour ce qu'on perd en ne permettant que 10 valeurs sur 16).

Le format d'IBM (DPD) utilise un format compressé (Chen-Ho) en stockant des groupes de 3 chiffres sur 10 bits, ce qui permet 1000 valeurs utilisables sur 1024 (soit une efficacité de 99,7%).
http://en.wikipedia.org/wiki/Densely_packed_decimal

Le format d'Intel (bien nommé BID) stocke juste la mantisse en binaire et utilise des algos intelligents pour faire les arrondis comme en décimal.

En particulier, si la répétabilité est au prix du décimal, vu les performances de calcul modernes, est-ce vraiment un problème ?

Non. C'est tellement pas un problème que même les constructeurs commencent à s'en rendre compte.
Le problème, c'est que 40 ans d'arithmétique binaire et autant de code écrit et plus maintenu, ça s'abandonne pas comme ça...

[ylyad]

Et on revient à ce que j'ai dit: Excel n'est PAS un logiciel de calcul, et MS ne le présente PAS comme ça! Excel est un logiciel pour les comptables, donc la seule précision nécessaire, c'est 2 chiffres après la virgule - 5 max. Et un comptable, il veut que (4/3-1)*3-1 = 0, pas un truc à peu près égal à zéro.

(je sais, la réalité est qu'Excel est utilisé pour plein d'autres choses, et MS ne met pas de gros warnings du genre "Excel n'est pas précis, ne l'utilisez pas pour du calcul scientifique")

Par contre, en cherchant un peu, il y a des librairies Excel à priori plus robustes pour le calcul scientifique (exemple parmi d'autres)

[Foudge]

Et pour du calcul justement, que propose Microsoft ?

[Neo_13]

La concurrence !

[ylyad]

Ca: http://www.microsoft.com/downloads/d...displaylang=en
ou ça: http://windows.microsoft.com/en-US/w...res/calculator

OK, je sors...

[Møgluglu]

Et on revient à ce que j'ai dit: Excel n'est PAS un logiciel de calcul, et MS ne le présente PAS comme ça! Excel est un logiciel pour les comptables, donc la seule précision nécessaire, c'est 2 chiffres après la virgule - 5 max. Et un comptable, il veut que (4/3-1)*3-1 = 0, pas un truc à peu près égal à zéro.

Non non, c'est le contraire.
L'arithmétique d'Excel est basée sur la double précision IEEE, qui est largement assez précise pour à peu près n'importe quel calcul scientifique.
Lesdits scientifiques ont l'habitude de travailler en précision finie, les nombres manipulés sont en général issus de mesures ou de constantes physiques et n'ont pas de raison de s'exprimer mieux dans une base que dans une autre. Donc peu importe la base 2 ou 10, pourvu qu'on ait la précision et la "compliance" à la norme.
Le scientifique trouvera tout à fait normal que (4/3-1)*3-1 != 0.

Les comptables c'est différent, ils travaillent avec des nombres générés par des humains qui s'écrivent en base 10, et ils s'attendent à ce que le résultat d'un calcul corresponde à celui qui serait fait à la main. Voire même, c'est la loi qui attend ça ("mais non msieu j'vous assure, le million qui a atterri dans ma poche c'est la faute d'une erreur d'arrondi d'Excel" ).
Et pour ça, Excel ne te permet pas de calculer correctement avec 2 chiffres après la virgule. Ni même 1. Il n'y a qu'avec les entiers < 10^15 que ça passe, et encore faut faire les arrondis explicitement.

Donc quoi que MS dise, Excel est presque adapté pour les scientifiques mais pas pour les comptables. Presque parce que les pathétiques tentatives de maquiller les résultats pour faire croire à du décimal foutent le boxon dans les calculs.

Ce n'est pas un problème de précision, c'est un problème de base. On aura beau augmenter la précision autant qu'on veut, on arrivera jamais à représenter exactement 0,1 par un flottant en base 2.

[ylyad]

Tu parles de possibilité et de contrainte technique, je parle de public visé J'irai même plus loin (pour m'être souvent pris la tête avec les comptables sur les histoires d'arrondi, vu que souvent, ils arrondissent que l'affichage - via format / cellule), Excel est destiné à des opérationnels qui veulent tâter un peu de contrôle financier, et qui généralement se foutent des chiffres après la virgule

PS: bon, Excel sert aussi aux chefs de projet pour faire des Gantt avec des cellules de couleur, parce qu'ils ne veulent pas se faire chier avec MSProject ou que leur boss veut pas payer la licence

[Foudge]

Møgluglu> En gros Excel se base sur une utilisation bidouillée des double afin de répondre à un public large (Scientifiques, comptable, etc.) mais au final c'est bon pour personne ?
Avec Excel faut donc se contenter de calculs basés sur des nombres entier avec interdiction d'utiliser la division

[ducon]

Sauf si elle tombe juste ?

[Møgluglu]

Møgluglu> En gros Excel se base sur une utilisation bidouillée des double afin de répondre à un public large (Scientifiques, comptable, etc.) mais au final c'est bon pour personne ?

Toutafé.

Sauf que la raison n'est pas "pour un public large". Sinon, la réponse serait décimal (pour le calcul scientifique on s'en fout de la base donc décimal va très bien).

Je ne connais pas l'historique de l'arithmétique d'Excel (en particulier avant la généralisation des copros arithmétiques), mais je soupçonne que quelqu'un a décidé d'utiliser du binaire à une époque reculée et que depuis ils sont obligé de conserver ça sous peine de casser des millions de feuilles de calcul dans la nature...

[newbie06]

Allez hop tout le monde sous COBOL et on n'en parle plus.

[Møgluglu]

Et pour les réfractaires, il y a des packages pour Java, Python, ..., et même C.

Il y a quand-même quelques autres différences entre les types binaire et décimaux d'IEEE-754.
En particulier le fait que l'arithmétique n'est pas normalisée, contrairement au binaire et à la plupart des calculatrices modernes.

Ça signifie que le système fait la distinction entre les nombres 2 (= 1+1) et 2,0 (= 3 - 0,5 - 0,5), ce qui serait plus intuitif (d'après IBM).
Ça simplifie certains trucs au passage (plus besoin de distinguer zéros, dénormalisés, normalisés, on peut émuler les types virgule fixe facilement...)

Comme nouvelles opérations on a:
- quantize qui permet de forcer le nombre de chiffres après la virgule (éventuellement négatif),
- reduce qui vire les zéros non significatifs,
- same_quantum pour comparer les "nombres de chiffres après la virgule" de deux nombres.

En FP binaire on a 2 zéros, +0 et -0. En décimal on en a dans les 2000 : 0e-1007, 0e-1006... 0e+999...
http://speleotrove.com/decimal/decifaq4.html.

Il y a aussi des changements dans les modes d'arrondis et les exceptions (même que cette fois promis juré elles vont servir à quelque chose)