Myriad Blog 1.3.0 Thursday, Nov 23rd, 2017 at 04:42am 

Tuesday, Jan 29th, 2013 at 05:10pm
Dénormalisation

 
 
Les ordinateurs calculent en binaire. Leurs calculs préférés sont donc des calculs en nombre entiers, addition, soustraction, multiplication ou division. Depuis maintenant quelques décennies, ils savent travailler en "virgule flottante", c'est-à-dire que sur un nombre défini de bits (généralement 32 ou 64), ils peuvent stocker des nombres à virgule très grands, très petits ou très proches de zéro, avec un ratio d'erreur constant.
 
Pour cela, le stockage du nombre a été divisé en trois parties : le signe, l'exposant et la mantisse.
Un bit est réservé au signe (le nombre est positif ou négatif), plusieurs bits à l'exposant (lui-même positif ou négatif), et le reste à la mantisse.
 
Pour transformer un nombre ainsi code en "vrai" nombre réel, en gros :
- On prend la mantisse sous forme de nombre entier  
- On la multiplie ou divise par 2 (selon le signe de l'exposant) autant de fois qu'indiqué par la valeur absolue de l'exposant
- On prend l'opposé du résultat si le bit de signe est positionné
 
Tout va donc pour le mieux. Le processeur sait calculer sur ce type de nombres, et le résultat est suffisamment précis pour la plupart des opérations mathématiques courantes.
 
Pour prendre en compte le résultat d'opérations impossibles (divisions par zéro, dépassement des bornes possibles de l'exposant, fonctions non définies pour certaines valeurs ) des valeurs particulières ont été introduites. On les note, par convention:
+INF infini positif
-INF infini négatif
NAN not a number
 
Lorsqu'une variable contient une de ces valeurs, et qu'on demande un calcul, le programme ne plante pas. Le processeur prend juste beaucoup plus de temps pour réaliser l'opération, mais donne tout de même une valeur  (est-ce parce que le système tente d'appeler une routine de traitement des exceptions mathématiques, ou est-ce inhérent à la méthode de calcul du processeur ? Mystère).
 
par exemple, +INF * 2 donne +INF, NAN/3 donne NAN, etc
 
Dans le calcul des instruments virtuels, nous avons remarqué que lorsque des cordes se taisaient après avoir joué, le temps pris par le calcul augmentait massivement. Après investigation, nous nous sommes rendus compte que les données de vibration de la corde avaient toutes la valeur spéciale DEN. Et les opérations sur cette valeur spéciale prennent beaucoup plus de temps que des calculs normaux.
 
De quoi s'agit-il ? D'une valeur "dénormalisée", c'est-à-dire un exposant négatif qui a dépassé les bornes admises.
Cela se produit, par exemple, si vous prenez un nombre quelconque et le divisez par 10. Vous récupérez le résultat et le divisez encore par 10, et ainsi de suite.
Au bout d'un moment, le nombre va être plus petit que 1E-10, puis 1E-11, etc. jusqu'à ce que le nombre soit si proche de zéro qu'on ne puisse plus noter son exposant.
Et là, au lieu de le considérer comme valant 0, le processeur lui donne la valeur spéciale DEN, qui dégrade fortement les performances du programme.
 
Eviter cela n'est pas chose facile, et pose problème à tous ceux qui font notamment des calculs audio, où les lignes à décalage (une partie de ce qui sort est réinjecté dans l'entrée à l'infini) ne manquent pas de s'atténuer au bout d'un moment si on ne les sollicite pas.
 
Des méthodes ont été publiées pour tenter de parer à cet inconvénient.
La meilleure semble d'être, après chaque opération pouvant produire un DEN, d'ajouter puis de retrancher un *tout petit* nombre au résultat !  
 
A<- A+EPSILON
A<- A-EPSILON
 
En effet, un nombre quelconque A pas trop proche de zéro auquel on ajoute un très petit EPSILON vaut toujours A (en vertu de l'imprécision des nombres à virgule flottante). Si on lui soustrait ensuite EPSILON, il reste encore égal à A. L'opération n'a donc pas eu d'effet.
 
Par contre, DEN+EPSILON = EPSILON, et EPSILON-EPSILON=0. Nous l'avons essayé et ça fonctionne. Mais nous ne savons pas si un compilateur évolué ne va pas supprimer cette opération lors de la compilation : si on ne saisit pas l'astuce, ajouter puis retrancher le même nombre semble en effet totalement inutile.
by Olivier Guillion


Most recent first
Oldest first

Top of page
Legal information Last update:  (c) Myriad