27 votes

Quelle est la qualité de l'implémentation de classe aléatoire dans .NET?

J'ai deux questions concernant la mise en œuvre de l' Random classe .NET Framework 4.6 (code disponible ici):

  1. Quelle est la justification pour le paramètre Seed argument 1 à la fin du constructeur? Il semble être la copie-collé de Numerical Recipes in C (2e Ed.) où il a fait un certain sens, mais il n'a pas en C#.

  2. Il est directement indiqué dans le livre (Numerical Recipes in C (2e Ed.)) qu' inextp champ est réglé sur la valeur 31 parce que:

La constante 31 est spécial; voir Knuth.

Toutefois, dans le .NET de mise en œuvre de ce champ est réglé sur la valeur 21. Pourquoi? Le reste du code semble suivre de près le code de livre, sauf pour ce détail.

21voto

DGibbs Points 8844

Concernant l' intexp question, c'est un bug, qui Microsoft a reconnu et a refusé de réparer en raison de la compatibilité ascendante des préoccupations.

En effet, vous avez découvert un véritable problème avec l'application Aléatoire. Nous avons discuté au sein de l'équipe et avec certains de nos partenaires et a conclu que nous ne pouvons malheureusement pas de résoudre le problème dès maintenant. La raison en est que certaines applications se basent sur le fait que lors de l'initialisation avec la même semence, le générateur produit de la même séquence pseudo aléatoire. Même si le changement est pour le mieux, il va casser les applications qui ont fait de cette hypothèse une fois qu'ils ont migré vers le "fixe" version.

4voto

Kevin Cathcart Points 3521

Pour un peu plus de contexte:

Un temps, j'ai complètement analysé cette mise en œuvre. J'ai trouvé quelques différences.

A la première (à la perfection) est une autre grande valeur (MBIG). Numerical Recipies prétend que Knuth il est clair que toute grande valeur doit travailler, ce qui n'est pas un problème, et Microsoft raisonnablement choisi d'utiliser la plus grande valeur d'un entier de 32 bits.

La deuxième, c'est que constante, vous l'avez mentionné. Que l'on est une grosse affaire. Au minimum, il sera de réduire considérablement la période. Il ya eu des rapports que les effets sont en fait pire que ça.

Mais ensuite vient un autre particulièrement méchante différence. Il est littéralement une garantie de polarisation de la sortie (car il ne fait donc directement), et seront également susceptibles d'affecter la période de la RNG.

Quelle est donc cette deuxième question? Lors de l' .NET sortis pour la première fois, Microsoft n'a pas réalisé que le RNG ils ont codé était ouverte à ses deux extrémités, et ils ont décrit comme exclusif au maximum de la fin. Pour résoudre ce problème, l'équipe de sécurité de l'ajout d'un assez de mal de ligne de code: if (retVal == MBIG) retVal--;. C'est très malheureusement, comme le bon correctif serait littéralement seulement 4 caractères ajoutés (en plus des espaces).

Le bon correctif aurait été de changer de MBIG de int.MaxValue-1, mais le commutateur Sample() utilisation MBIG+1 (c'est à dire de continuer à utiliser int.MaxValue). Ce qui garantirait que l'Échantillon a l'intervalle [0.0, 1.0) sans introduire de biais, et seules les modifications de la valeur de MBIG qui Numerical Recipies dit Knuth a dit est parfaitement bien.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X