4.1.4 : Reproductibilité des résultats
Bien que cet aspect ne soit que très peu présent en utilisant des types entiers, garantir la reproductibilité des résultats est une tâche ardue en arithmétique flottante. En effet, chaque calcul numérique a, par définition, une précision limitée par le nombre de chiffres significatifs que les unités de calcul de l'unité arithmétique et logique peuvent fournir dans le CPU. Il y a donc une limite physique à la précision d'un calcul et celle-ci est respectée au mieux par les développeurs qui fournissent les fonctions mathématiques standards (sin, cos, tan, exp, log, sqrt, etc.).À cela s'ajoute le fait que l'ordre dans lequel les calculs sont effectués peut influer sur le résultat final. D'ordinaire un calcul vectorisé produira des résultats plus précis que sa version séquentielle, alors qu'il est courant de demander que la version vectorisée produise des résultats identiques à la version séquentielle qui est généralement la référence, puisque c'est la première à avoir donné un résultat.
Comme nous l'avons vu dans le chapitre 11.4, les calculs sont de plus en plus parallélisés ce qui ajoute une part non négligeable d'imprévus dans le déroulement des calculs effectués. Même si chaque calcul effectué sur un thread donne un résultat avec une certaine précision, la méthode d'agrégation de ceux-ci peut porter préjudice au résultat final et plus particulièrement l'ordre dans lequel ils seront traités lorsqu'il est nécessaire de les réduire avec une addition par exemple.
L'utilisation de générateurs de nombres pseudo-aléatoires pose aussi problème, car il doit être possible, sur demande, de rejouer une séquence de nombres afin de tester un comportement imprévu ou confirmé un résultat. Lorsque ce problème se pose sur un programme parallèle, chaque thread doit avoir sa propre séquence de nombres pseudo-aléatoire, mais il est également nécessaire de garantir que toutes ces séquences seront effectivement différentes, sinon le résultat global ne sera pas le fruit d'un comportement réellement pseudo-aléatoire. Voire, dans certains cas, aucune amélioration du temps d'échéance ne sera obtenue ainsi qu'aucune amélioration du résultat final (si chaque thread doit explorer une partie d'un espace relativement grand pour trouver un minimum, ou calculer une intégrale avec une méthode stochastique).