Cet article a fait l'objet d'une traduction automatique.

Valeurs numériques

Test de fonctions mathématiques dans Cloud Numerics de Microsoft

Stuart Brorson

Supposons que vous avez besoin effectuer un calcul mathématique. Par exemple, supposons que vous devez savoir le sinus de 34 °. Que fais-tu? Probablement, vous tournez vers une calculatrice, ordinateur ou tout autre périphérique intelligent. Sur votre appareil, vous tapez « sin(34) » et vous obtenez une réponse, souvent avec 16 décimales de précision. Mais comment savez-vous si que votre réponse est correcte ?

Nous sommes tellement habitués à obtenir des réponses mathématiques de nos gadgets électroniques que personne ne pense à propos de la question de savoir si les réponses sont correctes ! Presque tout le monde prend pour acquis que nos machines nous donnent les bonnes réponses. Toutefois, pour un petit ensemble d'ingénieurs qualité logiciel, exactitude ne peut être tenue pour acquise ; le travail est tout au sujet d'obtenir la bonne réponse. Cet article explique comment les fonctions mathématiques de la nouvelle bibliothèque de mathématiques Numerics Cloud Microsoft sont testées.

Plus de calculs scientifiques et d'ingénierie utilisent arithmétique à virgule flottante. L'IEEE a normalisé le fonctionnement de base des mathématiques à virgule flottante en 1985. Un élément clé de la norme, c'est qu'il ne reconnaît pas tous les nombres peuvent être représentés sur un ordinateur. Alors que l'ensemble des nombres réels est infinie et innombrables, l'ensemble des nombres à virgule flottante IEEE est nécessairement fini et dénombrable car la représentation numérique des nombres à virgule flottante utilise un nombre fixe de bits. La construction des nombres à virgule flottante IEEE implique qu'ils sont aussi des nombres rationnels, alors couramment utilisés tels que π ne sont pas exprimés exactement et leur utilisation, telles que des opérations sin (x), ne sont pas exactes, soit.

En outre, contrairement à avec des entiers, l'espacement entre les nombres à virgule flottante IEEE est localement uniforme, mais elle augmente logarithmiquement avec le nombre lui-même. Cet aspect logarithmique est représenté dans Figure 1, qui illustre schématiquement les emplacements des morceaux uniformes de nombres à virgule flottante IEEE sur la ligne nombre réel. Dans la figure, morceaux valide de nombres à virgule flottante (intégré dans la ligne de nombre réel) est indiquées par des lignes verticales. Notez que la distance entre les nombres à virgule flottante valides augmente logarithmiquement comme l'amplitude de x augmente. La distance entre deux nombres à virgule flottante adjacents est souvent appelée l'unité de précision moindre ou unité en dernière Place (ULP) et est fournie comme une fonction intégrée appelée eps(x) dans de nombreux programmes mathématiques courantes. Une conséquence de la variation de l'espacement est qu'un petit nombre proche de 0 n'a aucun effet lorsqu'on ajoute un nombre relativement plus important telle que 1.

Figure 1 la grille de nombre à virgule flottante représentée schématiquement

Outre la codification des formats de nombres à virgule flottante, la norme IEEE fournit une aide strictement sur quel degré de précision le rendement des opérations mathématiques plus fondamentales doit être. Par exemple, la norme IEEE spécifie que les déclarations de quatre opérations arithmétiques (+, -, * et /) doit être « mieux arrondie, » ce qui signifie que la réponse renvoyée doit être plus proche au résultat "mathématiquement correct". Bien que cette exigence a été tenue avec une certaine résistance, retournant le résultat best-rounded maintenant se déroule au niveau matériel, montrant comment banal, il est devenu. Plus intéressant encore, la spécification à virgule flottante IEEE exige également que la fonction racine carrée retourne le résultat best-rounded. Ce qui est intéressant car il ouvre la porte à deux questions : « La précision avec laquelle une fonction irrationnelle calculent à l'aide de la représentation à virgule flottante IEEE? » et « Comment faut-il faire analyser l'exactitude d'une implémentation de fonction? »

Calcul des fonctions précises

Quels sont les facteurs vont déterminer la précision d'un calcul ? La réalité est que nous devrions rencontrer des inexactitudes, comme arrondi peut se produire dans n'importe quelle étape de l'algorithme. Ces erreurs pourraient composé, même si parfois ils pourraient également annuler. Dans la pratique, un concepteur d'algorithme doit apprendre à vivre avec et contenir l'inexactitude inhérente des calculs numériques.

Vous pouvez séparer les facteurs qui contribuent à l'erreur de calcul en deux catégories :

1. Facteurs liés à l'algorithme utilisé pour effectuer le calcul. Concrètement, cela signifie la stabilité de l'algorithme lui-même et sa sensibilité à l'arrondi erreurs. Un algorithme pauvre et instable aura tendance à retourner des résultats moins précis, alors qu'un bon algorithme stable vous donne des résultats plus précis.
2. La nature intrinsèque de la fonction elle-même et le domaine de ses intrants. Il y a une limite théorique à la précision réalisable de toute implémentation de fonction lorsque le calcul utilise un nombre fini (par opposition à un infini) de bits. La raison est qu'arrondi agit comme une source d'erreur dans le calcul et le comportement de la fonction elle-même détermine si cette erreur est amplifiée ou atténuée que le calcul s'effectue depuis les entrées aux sorties. Par exemple, calculer les valeurs d'une fonction à une singularité, un zéro ou une oscillation rapide pourrait être moins précise à ces endroits qu'une fonction qui varie lentement sur le même domaine d'entrée de l'informatique. Quand on parle de cette précision atteignable intrinsèque, nous parlons de la façon dont la fonction « bien conditionné » est.

En conséquence, tester la précision d'une implémentation de la fonction consiste à vérifier que l'algorithme renvoie des résultats aussi précise aussi théoriquement possible. Les limites de la possibilité théorique sont établis par le conditionnement de la fonction à chacune de ses entrées. Pour le dire autrement, à l'aide des nombres à virgule flottante pour calculer un résultat introduit deux sources possibles d'erreur : Erreurs qui nous permet d'éviter à l'aide de bon, stable (facteur 1) des algorithmes et erreurs qui sont plus difficiles à éviter, car elles sont liées au comportement de la fonction à ses intrants (facteur 2).

En analyse numérique, le concept de conditionnement est quantifié par le soi-disant « condition numéro », qui mesure la sensibilité d'une fonction aux variations de ses intrants. Selon la nature exacte de la fonction à l'examen (par exemple, le nombre d'entrées, scalaires et matrice et ainsi de suite), il y a un certain nombre d'expressions complexes pour le nombre de conditions. Le cas le plus simple est pour une fonction dérivable d'une variable, telles que 1 / x, x 2, sin (x) ou toute autre fonction probablement rencontré en algèbre lycée. Dans ce simple cas la condition numéro de la fonction f est donnée par :

Équation 1

Nous appellerons cela plus tard comme l'équation 1. Comme toujours, la notation f désigne la dérivée de la fonction f (x). Un certain nombre de grandes condition (Kf >> 1) indique une sensibilité élevée aux perturbations relatives, alors qu'un petit nombre de condition (Kf < = 1) indique la fonction est relativement insensible aux perturbations. Intuitivement, vous pouvez voir que si une fonction a une singularité — autrement dit, la fonction explose, tels que 1 / x près de x = 0 — le dérivé va saisir cet effet et un grande condition numéro de retour.

Par exemple, considérons la fonction f (x) = 1/(1-x). Cette fonction fait évidemment sauter (c'est-à-dire devient infinie) à x = 1. Le dérivé est f = 1 /(1-x) 2. Cela branchant dans l'équation 1 et en éliminant les termes donne le numéro de condition pour cette fonction :

La condition numéro Kf*(x)* tend vers l'infini autour de x = 1, ce qui signifie que les calculs impliquant cette fonction sera sensibles aux perturbations, comme l'erreur d'arrondi lorsque x est proche de 1. Parce que f (x) saute vers le haut pour → x 1, ce comportement est attendu. En outre, la condition numéro Kf (x) goes à 0 quand x est proche de 0. Ceci indique que les calculs à l'aide de cette fonction sera insensibles aux perturbations quand x → 0. Cela est logique intuitive, car f (x) tend vers une valeur constante de 1 lorsque x est beaucoup plus petit que 1.

Test de précision de la fonction

Alors à quoi une épreuve pratique d'une fonction mathématique ressembler ? Supposons que nous voulons tester notre implémentation de la fonction scalaire y = f (x), où x correspond à l'entrée et y est la valeur de sortie retournées. Étant donné une valeur à virgule flottante d'entrée x, test requiert trois éléments :

1. La valeur calculée par la fonction en cours de test, ycalculé = fcalculé*(x)*.
2. Le résultat « mathématiquement vrai ». Supposons que nous avons eu un oracle qui pourrait nous dire la réponse exacte, mathématiquement correcte. Ronde alors que la valeur la plus proche de la valeur à virgule flottante (donc il peut être représenté sur un ordinateur). Appelez cette valeur yvrai = fvrai*(x)*.
3. Une test de tolérance. Pour certaines fonctions, cette tolérance peut être 0, ce qui signifie qu'ycomputed est exactement identique à la valeur vraie mathématiquement, ytrue. Par exemple, la spécification à virgule flottante exige que la fonction sqrt() retourne la valeur à virgule flottante qui est situé le plus près de la réponse exacte (c'est-à-dire best-rounded). Dans le cas général, cependant, on ne peut attendre le retour de toutes les fonctions soient les approximations best-rounded leurs valeurs exactes. Par conséquent, la test de tolérance doit intégrer des informations sur combien d'erreur n'est autorisée dans le retour de f (x). Note que la tolérance peut dépendre des détails de la fonction f (x), ainsi que la valeur exacte de l'entrée, x.

Avec ces ingrédients, la précision de notre implémentation de la fonction est jugée acceptable (autrement dit, elle passe à notre test) si

| ycomputed* - ytrue | < tol (f ; x),*

où la tolérance dépend à la fois sur la valeur d'entrée x et le comportement de la fonction f elle-même.

Dans les mots, cette équation indique que la fonction réussit le test, si la valeur retournée est différente de la valeur « true » d'un montant inférieur à la tolérance d'essai (l'erreur permise). Notez que | ycomputed* - y*true | est l'erreur absolue de la fonction calculée.

Dans ce formalisme, un test de fonction est exécuté en créant un grand nombre de valeurs d'entrée se trouvant dans le domaine d'entrée de la fonction, ces valeurs en cours d'exécution grâce à la fonction à l'essai et de comparer la fonction des sorties ycalculés en fonction des valeurs (mathématiquement vrais) best-rounded, yvrai. Les valeurs des entrées devraient être choisis pour couvrir tous les éléments pertinents du domaine d'entrée valide de la fonction.

À ce stade, le testeur a à répondre à deux questions : Quel est le « vrai » résultat d'une fonction ? et ce qui est une tolérance raisonnable ?

Pour répondre à la première question, la meilleure chose à faire est d'utiliser un paquet de maths « précision infinie » pour créer les paires d'entrées/sorties utilisées pour l'essai. Ce paquet n'utilise pas les nombres à virgule flottante 32 bits ou 64 bits pour calculer une valeur. Au contraire, il utilise une représentation numérique — ou, mieux encore, une représentation symbolique, d'un certain nombre qui peut-être porter la capacité de calculer un nombre arbitrairement grand de chiffres par l'intermédiaire du calcul au détriment de la vitesse de calcul. Plusieurs forfaits disponibles dans le commerce de mathématiques implémentent l'arithmétique une précision infinie. En outre, de nombreuses bibliothèques de mathématiques de précision infinie peuvent être branchés dans langages communs. La possibilité d'utiliser les mathématiques de précision infinie à une vitesse moderne est une innovation récente, rendant ce type de test pratique. Une de ces ressources est suffisant pour créer des paires de ce qu'on appelle « valeur or » utile pour tester la mise en œuvre à virgule flottante de la fonction.

Vue d'ensemble — mise à l'essai de tolérance

Dès que nous aurons des valeurs or, nous avons besoin répondre à la question : Ce qui est une tolérance d'essai raisonnable ? Obtenir la bonne tolérance test est l'élément critique de l'essai. Si la tolérance est trop petite, la fonction ne passe jamais de son test, même si le meilleur algorithme est utilisé pour calculer l'il. En revanche, si la test de tolérance est trop importante, cela signifie que l'erreur permise est plus grand qu'il doit être, et la fonction va passer le test, même si l'algorithme est défectueux.

La condition numéro défini précédemment est la clé pour déterminer l'erreur acceptable autorisé en fonction de tests. L'expression de la condition numéro peut être réarrangée comme suit :

Équation 2

Nous appellerons cela plus tard comme l'équation 2. Si nous identifions ∆x comme la distance entre un nombre à virgule flottante et la suivante, cette expression nous dit combien la sortie de f (x) va sauter comme nous déplacer d'un nombre à virgule flottante x à son voisin, x + ∆x. Traditionnellement, le domaine des valeurs numériques ordinateur prend ∆x la fonction eps(x), l'espacement entre les deux nombres à virgule flottante adjacents. Notez que parce que l'espacement de la grille est non constants (voir Figure 1), eps(x) est une fonction de x. (Comme indiqué précédemment, la distance entre un nombre à virgule flottante et son plus proche voisin est également liée à un ULP — la grandeur représentée par le bit faible.)

Ensuite, nous demandons que l'erreur de sortie dans notre test, ycalculé -yvrai, être inférieur à un multiple de ce saut. Autrement dit, nous demandons que, où C est une constante :

Intuitivement, cette expression saisit l'idée suivante : Si x fait un pas sur la grille à virgule flottante, le changement dans le résultat devrait être pas plu de l'équation 2. Une fonction précise f (x) changera sa sortie seulement du montant provenant de la condition numéro et pas davantage. Donc, des perturbations qui se produisent pendant le calcul de la puissance f (x) doit être inférieure à la variation causée par la prise d'un pas sur la grille en virgule flottante. La constante C est un "facteur de sucre à la crème". Bien évidemment, aussi C augmente, la tolérance autorisée augmente avec elle. On peut donc interpréter cette constante puisque l'erreur fonctionnel autorisé au-dessus du minimum théorique. Lors de tests réels, C prend les valeurs de nombre entier entre 1 et 10, que nous interprétons comme l'erreur autorisée, exprimée en ULPs.

Enfin, à l'aide de la définition de la condition numéro, nous pouvons réorganiser l'équation d'une manière qui expose la tolérance d'essai :

| ycalculé -yvrai | ≤ C | affichera | eps(x) = tolérance

Il s'agit de notre test souhaité — c'est l'expression qui doit être satisfaite par l'implémentation exacte de la fonction f (x) pour toute entrée x. En d'autres termes, c'est l'expression utilisée pour valider les fonctions scalaires de mathématiques. Notez que cette expression devrait être vraie pour toutes les valeurs d'entrée valides x.

La dernière question à régler est, "ce qui correspond à la valeur correcte de C à utiliser dans les tests? » Parce que nous interprétons C comme le nombre d'erreurs ULP autorisées, C est un entier d'ordre 1. Nous avons mis C en commençant par un premier C valeur (généralement 10) et l'exécution du test. Si le test réussit, diminuer C par 1 et exécutez à nouveau le test. Répétez cette procédure pour diminuer le C valeurs jusqu'à ce que le test échoue. Choisissez ensuite la valeur de C qui a permis enfin le test à passer (mais toujours garder un homme dans la boucle pour assurer le caractère raisonnable). L'objectif de ce processus consiste à fermer la porte pour passer autant que possible (tout en permettant à la fonction passer le test) donc vous pouvez être sûr est de tester le fonctionnement aussi rigoureusement que possible. Fonctions bien élevées requièrent généralement C valeurs comprises entre 1 et 3, mais les fonctions plus complexes peuvent nécessiter un plus grand C valeurs de passage. Nous trouvons que les implémentations de fonctions très peu exigent C > 10 faire passer, et quand nous trouver une fonction qui nécessite C > 10, il signale souvent une implémentation non optimale.

Du point de vue des tests de logiciels, une fois C est déterminée pour test d'une fonction (et les passes de test), nous savons que tout manquement subséquent test signifie que quelque chose dans la fonction de mise en œuvre a changé — sans doute pour le pire (par exemple, a été une régression). Bien sûr, des compromis dans la conception d'algorithmes peuvent dicter que c'est la peine de donner un peu de mou sur C si la régression est faible (par exemple, une vitesse par rapport aux compromis entre précision). De même, après l'amélioration de l'algorithme, c'est la peine de voir si C peut être plus serré. En tout état de cause, un travail de test logiciel devient gérant les tolérances d'essais comme le reste du logiciel est développé.

Or valeur Testing and Beyond

Dans la méthodologie de test que nous avons discuté jusqu'à présent, nous avons utilisé précalculées paires d'entrées/sorties disséminés dans tout le domaine d'entrée de la fonction de l'essai. Nous appelons ce type de test de valeur or, ce qui signifie que l'oracle test de précision infinie fournit or paires d'entrées/sorties qui sont connus pour être très précis. Les paires peuvent être stockées dans un fichier et lire dans le programme d'essai lorsqu'il est exécuté. Comme une boîte noire méthode pour tester la précision fonctionnelle, cette approche fonctionne très bien. Toutefois, autres types de tests de la fonction fournissent également des moyens importants pour valider le comportement de la fonction. Autres tests comprennent :

• Test de valeur spéciale : Nombreuses fonctions retournent connues, exacte théorique valeurs pour certaines entrées, telles que cos(0) = > 1, sin(π) => 0 et gamma(1/2) = √π, pour obtenir des exemples. Dans un test de valeur spéciale, entrées fixes connues sont nourris à la fonction de l'essai, et le retour de fonction est comparé au résultat connu. Bien sûr, parce que les nombres irrationnels tels que π ne mentent pas exactement sur la grille à virgule flottante, l'à virgule flottante qui se rapproche de ces numéros doit être utilisé dans les essais et une valeur non nulle pour sinus et test de tolérance (tel que calculé plus haut) est utilisé pour valider les résultats de calculs.
• L'analyse d'identité : Nombreuses fonctions obéissent à des identités qui sont valables pour toutes les entrées sur un domaine connu. Par exemple, sin (x) ^ 2 + cos (x) ^ 2 == 1 pour toutes les entrées x. Un autre est arcsin(x) == i - log (j'ai * x + sqrt (1-x 2)). La différence entre une identité et un test de valeur spéciale est que le test d'identité est vrai pour une entrée arbitraire, alors que le test de valeur spéciale valable uniquement pour une valeur d'entrée particulière. En conséquence, les tests d'identité valident les relations entre les fonctions.

Vous devez être prudent avec les tests d'identité. Tout d'abord, certaines identités sont mal conditionnées. Par exemple, les résultats intermédiaires pourraient se développer pour être assez grande, même si le résultat final est de taille modérée. Dans ce cas, petits erreurs admissibles engagés au cours des étapes intermédiaires dans le calcul peuvent provoquer des échecs aux tests fallacieuses. En outre, de nombreuses fonctions (par exemple, les fonctions trigonométriques inverses) ont plusieurs valeurs dans le plan complexe. Aveuglément à l'aide de tests d'identité peut entraîner des échecs aux tests fallacieuses lors les côtés gauche et droit de l'identité renvoient des valeurs correctes se trouvant sur différentes feuilles de Riemann dans le plan complexe. Le testeur doit soigneusement concevoir des tests d'identité afin d'éviter ces deux problèmes.

• Test inverse : Cela implique une fonction composée par son inverse et vérifier le résultat est le même que l'entrée pour le test de calcul. Par exemple, pour positif x nous pouvons tester log(exp(x)) = x. Si vous pensez cela comme un cas particulier de l'analyse d'identité, et en effet il est. Cependant, parce que tant des fonctions inverses — et cohérence mathématique exige qu'une fonction composée avec son retour inverse l'entrée originale, nous utilisons une catégorie de test distinct pour valider que les fonctions et leurs inverses se comportent de manière cohérente. Les mêmes restrictions qui s'appliquent aux tests d'identité (par exemple conditionné ou retours se trouvant sur différentes feuilles de Riemann) également s'appliquent aux essais inverse.
• Série test de sommation : Presque toutes les fonctions transcendantes admettent un développement en série sur certains domaine d'entrée. Dans la série essais de sommation, nous comparons la valeur retournée par la fonction à l'essai à la valeur renvoyée par une série somme explicitement lors de l'essai. Vous pourriez considérer la sommation de la série comme un type de test d'identité. Toutefois, les considérations entrant dans la création d'un test de somme de bonne série sont semblables dans l'ensemble de fonctions (par exemple, les critères de stabilité et de convergence). Par conséquent, nous considérons ce type de test conceptuellement différent de l'analyse d'identité.
• Extensions de la fraction continue : Certaines fonctions peuvent également être évaluées sur un domaine connu en utilisant un développement de fraction continue. Lorsqu'une telle expansion existe, il pourrait bien plus rapidement qu'une somme de série convergent. Donc, pour certaines fonctions, le test de somme de série pourrait remplacer avec une expansion de fraction continue.
• Valeur construite test (également connu sous le nom model-based testing) : Dans le test de la valeur construite, vous créez une implémentation simple, de façon vérifiable correcte de la fonction au sein de l'épreuve proprement dite. Ce type de test ne s'applique pas nécessairement aux fonctions scalaires math. Cependant, un paquet de maths bon n'est pas limité à l'ensemble des fonctions analytiques. Prenons l'exemple des fonctions telles que le plancher, plafond, mod, les opérateurs de concaténation pour vecteurs et ainsi de suite. Chacune de ces fonctions peut être testé en écrivant du code qui implémente la fonction à l'aide de constructions de langage de programmation basic. Par exemple, plancher, plafond et la côtelette numériques diverses fonctions peuvent être modélisées à l'aide d'opérateurs de cast qui convertissent la valeur à virgule flottante en un entier et puis convertir le résultat en arrière à un flotteur (avec quelques calculs simples effectuées pour imiter le comportement exact de la fonction à l'examen). Des avantages de ce type de test sont que la mise en œuvre du modèle est généralement négligeable et n'est donc vérifiable par l'inspection.
• Test de l'erreur : Ces tests s'assurer que l'entrée non valide est gérée correctement en renvoyant une erreur de nettoyage qui permet au programmeur de clairement et rapidement comprendre le problème. Par exemple, lorsque vous travaillez dans des nombres réels, sqrt (x) doit retourner une erreur utile (ou NaN) si x < 0. Des erreurs d'entrée sont connus pour interrompre l'ordinateur si elles ne sont pas manipulées correctement, et emploi de l'appareil d'essai est de s'assurer que cela ne se produit pas.

L'avantage de ces types de tests est qu'ils fournissent une vérification de la justesse de la fonction en utilisant seulement les mathématiques elle-même. Car elles utilisent la cohérence des mathématiques comme le fondement des tests, ils sont « connus bien » et ne s'appuient sur des calculs numériques à l'aide de logiciels tiers.

Validation de l'approche

Une façon d'apprécier l'avantage des tolérances numéros condition consiste à examiner les tolérances utilisées pour valider les fonctions scalaires mathématiques qui ont des singularités dans leurs domaines respectifs d'entrée. Par exemple, la commune fonctions trigonométriques tan et cot sont au singulier à un nombre infini de points le long de la ligne de nombre réel. Si les tolérances fixes et constantes ont été utilisés pour la validation de l'exactitude, ces fonctions échouerait leurs tests pour les valeurs d'entrée à proximité des singularités ou les tolérances d'essais serait nécessairement si grandes que les tests ne serait pas efficaces. Avec des tolérances numéros de condition, nous pouvons valider les fonctions scalaires au sein d'une petite poignée de ULPs sur tout le domaine d'entrée de la fonction. Montre Figure 2 sont des exemples de transmettre des valeurs ULP, nous avons constaté au cours de la qualification des fonctions réparties dans le produit Microsoft Cloud Numerics. Autrement dit, ce sont les valeurs de PDT au cours de laquelle la fonction correspondante passe son test.

La figure 2 en passant les valeurs ULP

La conclusion à tirer des exemples dans Figure 2 est que les fonctions spéciales sont implémentées à l'aide d'algorithmes qui sont précis à un petit nombre de ULPs. Le pire des cas présentés dans Figure 2 ont une erreur inférieure à 6 ULPs, ce qui correspond à log10(2^6) = 1,8 les chiffres décimaux de l'erreur dans l'ordre le plus bas chiffres du numéro. Pour un double à virgule flottante, cela correspond à une erreur relative de 1.3323e-015.

Test de l'état-of-the-Art

Pour passer en revue, une méthodologie de test rigoureuse a été appliquée avec succès à la validation des algorithmes utilisés dans les paquets de math Microsoft Cloud Numerics. À l'aide de tests tolérances dérivés numéro d'état de la fonction a permis d'identifier et les implémentations de fonction incorrect correct, même quand les erreurs se sont produites que dans le dernier quelques chiffres de la fonction retourne. Tolérances tests fixes ne peut pas fournir un critère strict qui ne cause des défaillances parasites (comme les singularités près de fonction). La majorité de nos tests impliqués en utilisant les valeurs d'entrée/sortie valeur doré qui sont précalculées en utilisant des paquets de mathématiques de précision infinie et ensuite stocké dans des fichiers qui sont lus au moment du test. Outre l'utilisation de valeurs or, nous avons également effectué des contrôles croisés sur nos implémentations de fonctions à l'aide d'une variété d'identités différentes math pour valider le comportement de nos fonctions.

Nous croyons que les utilisateurs de Microsoft Cloud Numerics peuvent utiliser le grand nombre de fonctions mathématiques et statistiques de la bibliothèque et être confiants que les fonctions ont été contrôlées soigneusement à l'aide d'état-of-the-art software testing pratiques.

Pour plus d'informations, nous vous encourageons à lire la description classique de David Goldberg de l'arithmétique à virgule flottante, « Ce qui chaque ordinateur scientifique devrait savoir sur Floating-Point Arithmetic, » qui est disponible à bit.ly/vBhP9m et d'autres sites.

Stuart Brorson est un SDET au centre Microsoft NERD à Cambridge, au Massachusetts. Il a rejoint Microsoft lorsque la société a acquis Supercomputing Interactive, qui a mis au point permettant aux utilisateurs de logiciels pour lancer mathématiques et calculs de la matrice sur des superordinateurs parallèles. Pour le plaisir, Brorson aime piratage électronique et le violon irlandais autour de Boston.

Ben Moskowitz est un SDET spécialisées dans les tests des projets axés sur les mathématiques chez Microsoft. Il a contribué à des rejets de nuage Numerics et Solver Foundation, un paquet d'optimisation et plate-forme qui a remporté le prix de phare de Visual Studio en 2011. Heures creuses, il passe du temps avec sa femme, qui prennent soin de leurs chèvres vivant dans la ville.

Alan Edelman est professeur de mathématiques et membre de l'informatique et les AI laboratoires du MIT à Cambridge, au Massachusetts. Professeur Edelman a remporté de nombreux prix pour ses travaux sur l'analyse numérique, calcul parallèle et théorie de la matrice aléatoire. Il fut le fondateur de superinformatique Interactive, est l'un des fondateurs du projet Julia, a beaucoup appris de Velvel Kahan et a participé intensément à la Numerical Mathematics Consortium sur les questions de mathématiques à virgule flottante*.***

Merci à l'expert technique suivant d'avoir relu cet article : Paul Ringseth