Si c est grand/petit et a-b petit/grand je peux avoir un overflow/underflow dans la division. Par contre mon dénominateur ne sera jamais nul (au pire NaN ou infini, mais pas 0).
J'ai la flemme de faire la preuve et j'ai pas mon cours d'arith sur moi, mais avec une étude de cas plus ou moins fastidieuse ça doit se montrer.
(en gros soit a et b sont éloignés et on montre facilement que a-b /= 0, soit ils sont proches et on applique le lemme de Sterbenz pour dire que l'opération est exacte)
Je suis contre cette démarche fataliste qui dit que puisqu'on n'arrivera jamais à calculer exactement, autant laisser tomber tout de suite et calculer n'importe comment.Je suis d'accord avec toi que ca arrivera moins souvent mais ca ne fait que repousser le probleme.
Ça n'est pas très éloigné de comment fonctionnent les x86, on a juste du soft au lieu du microcode pour intercepter les exceptions...Meme si la plupart des processeurs ont toujours eu la possibilite de supporter la norme, il y en a plus d'un qui ne la supportait pas dans son mode d'operation par defaut, le plus connu etant l'alpha qui ne respectait pas la norme pour les overflow/NaN en hard jusqu'a EV6 (une option de compilation permettait de l'activer et le soft gerait ces cas la).
Tu as tout compris.Je ne sais pas vraiment ce que font les GPUs mais je suppose que tu n'as pas l'option de trap et de gerer l'exception a la main en soft, d'ou pas mal de problemes.
Les traps ne sont pas une feature qui intéresse les programmeurs graphiques, et avec les SIMD de 16 ou 32 voies et les pipelines monstrueux qu'on a les perfs seraient vraiment désastreuses.
Peut-être parce que DAZ et FTZ sont pas activés par défaut on a pas de problème avec?PS: j'ai vu plus de problemes lies a la presence de denormaux que de problemes de DAZ/FTZ parmi les utilisateurs qui utilisaient le flottant sans comprendre. Certes le resultat avec les denormaux a des chances d'etre plus proche du resultat vise (mais c'est un peu comme utiliser double a la place de float en esperant avoir un meilleur resultat), mais ce n'est pas systematique, et on y arrive beaucoup plus lentement.
Certes, à partir du moment où on a des dénormaux qui apparaissent c'est que le code à un problème de stabilité numérique. Mais c'est pas pour autant l'auteur de compilateur doit se prendre pour un héro ou un donneur de leçons en massacrant volontairement le code qu'on lui donne. Ou alors à la limite en -O5.
Sinon le débugger pourrait intercepter les underflows pour afficher des warnings dans sa console, comme ça le programmeur spammé verra que quelque chose cloche.