2010-10-22 8 views
1

Dans la boîte à outils Silverlight il y a cette méthode:Que fait RemoveNoiseFromDoubleMath?

/// <summary> 
    /// Removes the noise from double math. 
    /// </summary> 
    /// <param name="value">The value.</param> 
    /// <returns>A double without a noise.</returns> 
    internal static double RemoveNoiseFromDoubleMath(double value) 
    { 
     if (value == 0.0 || Math.Abs((Math.Log10(Math.Abs(value)))) < 27) 
     { 
      return (double)((decimal)value); 
     } 
     return Double.Parse(value.ToString(CultureInfo.InvariantCulture), CultureInfo.InvariantCulture); 
    } 

Je ne comprends pas ce que le but est, est-il en double bruit de faire des mathématiques en .Net?

Qu'est-ce qui est avec la distribution double à décimale à double?

Pourquoi faire un ToString l'analyse?

J'ai écrit un projet de test rapide pour générer des nombres aléatoires et l'exécuter à travers la méthode et je n'ai vu aucun changement (pas que je pensais que je le ferais).

Répondre

1

Ce que cela tente de faire est d'atténuer la différence d'arrondi hérité à l'arithmétique en virgule flottante.

Si vous prenez par exemple l'extrait suivant:

double result = 1.0/7.0; 

double difference = result - RemoveNoiseFromDoubleMath(result); 

Console.WriteLine(difference); 

Cela produit une différence de -1,38777878078145E-16.

+0

Cela est logique car la boîte à outils utilise la méthode autour d'un double calcul: ValueHelper.RemoveNoiseFromDoubleMath (ValueHelper.RemoveNoiseFromDoubleMath (Math.Floor (typedValue/typedInterval)) * typedInterval); – darren

0

Il est vraiment génial que cette fonction ait un bloc de commentaire qui n'explique pas réellement ce que ce «bruit» est en train de traiter, et comment cela affecte la valeur.

La façon dont je le lis, si le nombre a moins de 27 chiffres de base-10 (ou est exactement zéro), il est converti en un nombre décimal, puis de nouveau à doubler. Je m'attendais à la conversion en décimal si n'a aucun effet sur la valeur, puisque la décimale a une plus grande résolution que le double. La conversion en double devrait à nouveau être sans perte.

L'exemple de Pieter montre que cette opération semble réellement affecter la valeur, donc apparemment les conversions du double en décimal et en arrière ne préservent pas la valeur, même quand elles pourraient l'être. En regardant dans msdn, je vois ceci: http://msdn.microsoft.com/en-us/library/yht2cx7b(v=VS.80).aspx

qui dit:

Lorsque vous convertissez float ou double à décimale, la valeur de la source est convertie à représentation décimale et arrondie au nombre le plus proche après la 28e décimale si nécessaire.

Ok, donc ça arrondit. Cela signifie que si vous avez un double avec une valeur de 1.9999999999999999999999999999, la conversion en décimal l'arrondira à 2, donc quand il est converti en double, vous obtenez un double avec une valeur de 2.0 exactement.

Si le nombre a plus de 27 chiffres, il est converti en une chaîne, puis analysé. Je ne suis pas sûr du résultat final: cela dépend du comportement par défaut de ToString et de Double.parse.