le résultat du sinus dépend du compilateur C++ utilisé

Question

J'utilise les deux compilateurs C++ suivants :

• cl.exe : Compilateur optimisant Microsoft (R) C/C++ Version 19.00.24210 pour x86
• g++ : g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010

En utilisant la fonction sinus intégrée, j'obtiens des résultats différents. Ce n'est pas critique, mais parfois les résultats sont trop significatifs pour mon usage. Voici un exemple avec une valeur "codée en dur" :

printf("%f\n", sin(5451939907183506432.0));

Résultat avec cl.exe :

0.528463

Résultat avec g++ :

0.522491

Je sais que le résultat de g++ est plus précis et que je pourrais utiliser une bibliothèque supplémentaire pour obtenir ce même résultat, mais ce n'est pas mon propos ici. Je voudrais vraiment comprendre ce qui se passe ici : pourquoi cl.exe est-il si mauvais ?

C'est drôle, si j'applique un modulo de (2 * pi) sur le paramètre, alors j'obtiens le même résultat que g++...

[EDIT] Juste parce que mon exemple semble fou pour certains d'entre vous : il s'agit d'une partie d'un générateur de nombres pseudo-aléatoires. Il n'est pas important de savoir si le résultat du sinus est exact ou non : nous avons juste besoin qu'il donne un certain résultat.

Answer 1

Vous avez un littéral de 19 chiffres, mais le double a généralement une précision de 15 à 17 chiffres. Par conséquent, vous pouvez obtenir une petite erreur relative (lors de la conversion en double), mais une erreur absolue assez importante (dans le contexte du calcul du sinus).

En fait, les différentes implémentations de la bibliothèque standard présentent des différences dans le traitement de ces grands nombres. Par exemple, dans mon environnement, si on exécute

std::cout << std::fixed << 5451939907183506432.0;

Le résultat de g++ serait 5451939907183506432.000000
Le résultat de cl serait 5451939907183506400.000000

La différence vient du fait que les versions de cl antérieures à 19 ont un algorithme de formatage qui n'utilise qu'un nombre limité de chiffres et remplit les décimales restantes avec zéro.

En outre, regardons ce code :

double a[1000];
for (int i = 0; i < 1000; ++i) {
    a[i] = sin(5451939907183506432.0);
}
double d = sin(5451939907183506432.0);
cout << a[500] << endl;
cout << d << endl; 

Lorsqu'il est exécuté avec mon compilateur x86 VC++, le résultat est le suivant :

0.522491
0.528463

Il semble qu'en remplissant le tableau sin est compilé à l'appel de __vdecl_sin2 et lorsqu'il y a une seule opération, elle est compilée à l'appel de __libm_sse2_sin_precise (avec /fp:precise ).

A mon avis, votre nombre est trop important pour sin calcul pour s'attendre au même comportement de la part de différents compilateurs et pour s'attendre à un comportement correct en général.

Answer 2

Je pense que le commentaire de Sam est le plus proche de la réalité. Alors que vous utilisez une version récente de GCC/glibc, qui implémente sin() en logiciel (calculé au moment de la compilation pour le littéral en question), cl.exe pour x86 utilise probablement l'instruction fsin. Cette dernière peut être très imprécise, comme décrit dans l'article du blog Random ASCII, " Intel sous-estime les limites d'erreur de 1,3 quintillion ".

Une partie du problème avec votre exemple en particulier est qu'Intel utilise une approximation imprécise de pi lors de la réduction de la portée :

Lors de la réduction de gamme à partir d'une double précision (mantisse de 53 bits) pi les résultats auront environ 13 bits de précision (66 moins 53), pour une erreur allant jusqu'à 2^40 ULP (53 moins 13).

Answer 3

Selon Référence cpp :

Le résultat peut avoir peu ou pas d'importance si la magnitude de arg est grande. (jusqu'à C++11)

Il est possible que cela soit la cause du problème, auquel cas vous voudrez effectuer manuellement le modulo de manière à ce que arg n'est pas grande.