dieharder - En ligne dans le Cloud

PROGRAMME:

Nom

plus intransigeant - A vers les tests et analyse comparative outil pour aléatoire nombre générateurs.

SYNOPSIS

dieharder [-a] [-d dieharder numéro de test] [-f nom de fichier] [-B]
[-D indicateur de sortie [-D indicateur de sortie] ... ] [-F] [-c séparateur]
[-g numéro de générateur ou -1] [-h] [-k ks_flag] [-l]
[-L chevauchement] [-m multiplier_p] [-n ntuple]
[-p nombre de p échantillons] [-P Xoff]
[-o nom de fichier] [-s stratégie de départ] [-S graine de nombre aléatoire]
[-n ntuple] [-p nombre de p échantillons] [-o nom de fichier]
[-s stratégie de départ] [-S graine de nombre aléatoire]
[-t nombre d'échantillons de test] [-v indicateur détaillé]
[-W faible] [-X échec] [-Y Xtratégie]
[-x valeur x] [-y valeur y] [-z valeur z]

plus intransigeant OPTIONS

-a exécute tous les tests avec les options standard/par défaut pour créer un
rapport contrôlable par l'utilisateur. Pour contrôler le formatage du rapport, voir -D ci-dessous.
Pour contrôler la puissance du test (qui utilise des valeurs par défaut pour les tsamples qui
ne peut généralement pas être varié et psamples qui peuvent généralement) voir -m ci-dessous comme un
"multiplicateur" du nombre par défaut de psamples (utilisé uniquement dans une exécution -a).

-d numéro de test - sélectionne un test pur et dur spécifique.

-f nom de fichier - les générateurs 201 ou 202 autorisent soit le binaire brut, soit
nombres ASCII formatés à lire à partir d'un fichier pour le test. générateur 200 lectures
en nombres binaires bruts de stdin. A noter bien : de nombreux tests avec des paramètres par défaut
nécessitent beaucoup de rands! Pour voir un exemple de l'en-tête (obligatoire) pour ASCII
entrée formatée, exécuter

plus dur -o -f example.input -t 10

puis examinez le contenu de example.input. L'entrée binaire brute lit 32 bits
incréments du flux de données spécifié. stdin_input_raw accepte un tube d'un raw
flux binaire.

Le mode binaire -B (utilisé avec -o ci-dessous) entraîne l'écriture des rands de sortie en binaire brut, pas
formaté ascii.

-D indicateur de sortie - permet de sélectionner des champs à inclure dans
sortie plus dure. Chaque indicateur peut être entré sous la forme d'un nombre binaire qui active un
champ ou en-tête de sortie spécifique ou par nom d'indicateur ; les drapeaux sont agrégés. Pour tout voir
les indicateurs actuellement connus utilisent la commande -F.

-F - répertorie tous les drapeaux connus par nom et numéro.

-c séparateur de table - où le séparateur est par exemple ',' (CSV) ou ' ' (espace blanc).

-g numéro de générateur - sélectionne un générateur spécifique pour le test. À l'aide de
-g -1 provoque l'affichage de tous les générateurs connus.

-h affiche l'aide contextuelle -- généralement Usage (ce message) ou un
test synopsis s'il est entré comme par exemple dieharder -d 3 -h.

-k ks_flag - ks_flag

0 est rapide mais légèrement bâclé pour psamples > 4999 (par défaut).

1 est BEAUCOUP plus lent mais plus précis pour un plus grand nombre de psamples.

2 est encore plus lent, mais (nous l'espérons) précis à la précision de la machine pour un nombre quelconque de
péchantillons jusqu'à une limite supérieure numérique encore inconnue (elle a été testée pour
au moins des centaines de milliers).

3 est kuiper ks, rapide, assez imprécis pour les petits échantillons, obsolète.

-l liste tous les tests connus.

-L chevauchement

1 (utiliser le chevauchement, par défaut)

0 (ne pas utiliser de chevauchement)

dans operm5 ou d'autres tests qui prennent en charge les modes d'échantillonnage qui se chevauchent et ne se chevauchent pas.

-m multiplier_p - multiplier le nombre par défaut de psamples dans -a(ll) s'exécute pour lancer
jusqu'à la résolution de l'échec. -n ntuple - définit la longueur de ntuple pour les tests sur un bit court
chaînes qui permettent de faire varier la longueur (par exemple bitdist rgb).

-o nom de fichier - sortie -t compte les nombres aléatoires du générateur actuel vers le fichier.

-p count - définit le nombre d'échantillons de valeur p par test (par défaut 100).

-P Xoff - définit le nombre de psamples qui se cumuleront avant de décider
qu'un générateur est « bon » et passe vraiment, vraiment, même une exécution -Y 2 T2D. Actuellement
la valeur par défaut est 100000 ; éventuellement, il sera défini à partir de l'échec du test T2D dérivé d'AES
seuils pour un fonctionnement fiable entièrement automatisé, mais pour l'instant c'est plus un
seuil "d'ennui" défini par combien de temps on peut raisonnablement vouloir attendre sur un
essai.

-S graine - où graine est un uint. Remplace la valeur de départ aléatoire par défaut
sélection. Ignoré pour l'entrée de fichier ou stdin.

-s stratégie - si la stratégie est la valeur (par défaut) 0, les réensemencements les plus durs (ou
rembobine) une fois au début lorsque le générateur de nombres aléatoires est sélectionné et
puis plus jamais. Si la stratégie est non nulle, le générateur est réamorcé ou rembobiné à
le début de CHAQUE TEST. Si -S seed a été spécifié, ou si un fichier est utilisé, cela
signifie que chaque test est appliqué à la même séquence (ce qui est utile pour la validation
et tester les plus purs et durs, mais ce n'est pas un bon moyen de tester les rngs). Sinon un nouveau aléatoire
la semence est sélectionnée pour chaque test.

-t count - définit le nombre d'entités aléatoires utilisées dans chaque test, où
possible. Soyez averti - certains tests ont des tailles d'échantillon fixes ; d'autres sont variables mais
avoir des tailles minimales pratiques. Il est suggéré de commencer par les valeurs utilisées dans -a
et expérimenter soigneusement sur une base de test par test.

-W faible - définit le seuil "faible" pour rendre le(s) test(s) plus ou moins
pardonner pendant, par exemple, une course de test à la destruction. La valeur par défaut est actuellement 0.005.

-X fail - définit le seuil d'"échec" pour rendre le(s) test(s) plus ou moins
pardonner pendant, par exemple, une course de test à la destruction. La valeur par défaut est actuellement 0.000001,
qui est fondamentalement « l'échec certain de l'hypothèse nulle », le mode de
panne reproductible du générateur.

-Y Xtrategy - le drapeau Xtrategy contrôle le nouveau "test à l'échec" (T2F)
modes. Ces drapeaux et leurs modes agissent comme suit :

0 - exécutez simplement dieharder avec le nombre spécifié de tsamples et psamples, ne
modifier dynamiquement une exécution en fonction des résultats. C'est ainsi que cela a toujours fonctionné, et
est la valeur par défaut.

1 - Mode « résoudre l'ambiguïté » (RA). Si un test renvoie "faible", il s'agit d'un
résultat indésirable. Qu'est-ce que ça veut dire, après tout ? Si vous exécutez une longue série de tests,
vous verrez des rendements faibles occasionnels pour un générateur parfait car p est
uniformément distribué et apparaîtra dans n'importe quel intervalle fini de temps en temps.
Même si un test renvoie plus d'un résultat faible, vous ne pouvez pas être certain que
le générateur tombe en panne. Le mode RA ajoute des psamples (généralement par blocs de 100) jusqu'à ce que
le résultat du test se termine solidement pas faible ou procède à un échec sans ambiguïté. Cette
est moralement équivalent à exécuter le test plusieurs fois pour voir si un résultat faible est
reproductible, mais élimine le biais de jugement personnel dans le processus puisque
le seuil de défaillance par défaut est très petit et très peu susceptible d'être atteint par
chance aléatoire même dans de nombreuses courses.

Ce option devrait uniquement be d'utiliser avec -k 2.

2 - mode "test à la destruction". Parfois, vous voulez juste savoir où ou si un
le générateur échouera un jour à un test (ou à une série de tests). -Y 2 provoque la création de psamples
ajouté 100 à la fois jusqu'à ce qu'un test renvoie une pvalue globale inférieure à l'échec
seuil ou un nombre maximum spécifié de psamples (voir -P) est atteint.

Notez bien! Dans ce mode, on peut très bien échouer en raison de la autre hypothèse nulle --
le test lui-même est un mauvais test et échoue ! De nombreux tests plus acharnés, malgré nos meilleurs
efforts, sont numériquement instables ou n'ont qu'une cible approximativement connue
statistiques ou sont des résultats asymptotiques directs, et renverront éventuellement un
résultat d'échec même pour un générateur de référence (comme AES), ou pour le
hyperprudent le générateur XOR avec AES, threefish, kiss, tous chargés à la fois et
xor'd ensemble. Il est donc plus sûr d'utiliser ce mode.
exécuter une exécution T2D sur AES pour avoir une idée du ou des seuils d'échec du test
(quelque chose que je finirai par faire et publier sur le Web pour que tout le monde n'ait pas à le faire
le faire indépendamment), puis l'exécuter sur votre générateur cible. Échec avec
nombres d'échantillons dans un ordre de grandeur des seuils AES devraient
probablement être considérés comme des échecs de test possibles, pas des échecs de générateur. Échecs à
des niveaux nettement inférieurs aux seuils de défaillance de générateur de référence connus
sont, bien sûr, probablement des défaillances du générateur.

Ce option devrait uniquement be d'utiliser avec -k 2.

-v verbose flag -- contrôle la verbosité de la sortie pour le débogage
seul. Probablement de peu d'utilité pour les non-développeurs, et les développeurs peuvent lire le
enum(s) dans dieharder.h et les sources de test pour voir quelles valeurs d'indicateur activent la sortie
sur quelles routines. 1 est le résultat d'une trace très détaillée de l'activité du programme.

-x,-y,-z nombre - Certains tests ont des paramètres qui peuvent être modifiés en toute sécurité
de leur valeur par défaut. Par exemple, dans le test des anniversaires purs et durs, on peut varier
le nombre de longueur, qui peut également être varié. -x 2048 -y 30 modifie ces deux
valeurs mais devrait toujours fonctionner correctement. Ces paramètres doivent être documentés en interne
(lorsqu'ils existent) dans les notes visibles par exemple -d 0 -h.

REMARQUE BIEN: La ou les évaluations des sonneries peuvent, en fait, être complètement incorrectes ou
trompeur. Il y a encore des "mauvais tests" dans les plus purs et durs, bien que nous nous efforcions de
les corriger et les améliorer (et essayer de les documenter dans les descriptions de tests visibles
avec -g numéro de test -h). En particulier, les pvalues ​​«faibles» devraient se produire un test sur deux
cent, et les pvalues ​​« Echec » devraient se produire un test sur un million avec la valeur par défaut
seuils - c'est ce que p SIGNIFIE. Utilisez-les à vos risques et périls! Être averti!

Ou mieux encore, utilisez les nouveaux -Y 1 et -Y 2 pour résoudre l'ambiguïté ou tester jusqu'à la destruction
modes ci-dessus, en comparant à des exécutions similaires sur l'un des meilleurs
générateurs cryptographiques, AES ou threefish.

DESCRIPTION

plus intransigeant

Bienvenue dans l'instantané actuel du testeur de nombres aléatoires inconditionnel. Il encapsule
tous les générateurs de nombres aléatoires (rngs) de la bibliothèque scientifique Gnu (GSL) ainsi qu'un
nombre de générateurs de la bibliothèque statistique R, des sources matérielles telles que
/ dev /*générateurs aléatoires de qualité cryptographique « gold standard » (utiles pour les tests
plus durs et à des fins de comparaison avec de nouveaux générateurs) ainsi que des générateurs
contribué par les utilisateurs ou trouvé dans la littérature dans un unique harnais qui peut les chronométrer
et les soumettre à divers tests d'aléatoire. Ces tests sont diversement tirés de
La « batterie à outrance de tests de nombres aléatoires » de George Marsaglia, le test statistique du NIST
Suite, et encore d'autres sources telles que l'invention personnelle, la contribution de l'utilisateur, d'autres
des suites de tests (open source) ou de la littérature.

Le point principal du plus pur et dur est de faciliter le chronométrage et le test de nombres (pseudo) aléatoires
générateurs, y compris les rngs logiciels et matériels, avec un outil entièrement open source. Dans
en plus de fournir un accès « instantané » aux tests de tous les générateurs intégrés, les utilisateurs peuvent
choisir l'une des trois façons de tester leurs propres générateurs ou sources de nombres aléatoires : un unix
canal d'un flux binaire brut (présumé aléatoire) ; un fichier contenant un (présumé aléatoire)
flux binaires bruts ou uints ou flottants ascii formatés ; et en intégrant votre générateur dans
le harnais rng compatible GSL de dieharder et en l'ajoutant à la liste des générateurs intégrés.
Les méthodes d'entrée stdin et fichier sont décrites ci-dessous dans leur propre section, comme suggéré
« meilleure pratique » pour les débutants dans les tests de générateurs de nombres aléatoires.

Une motivation importante pour l'utilisation de dieharder est que l'ensemble de la suite de tests est entièrement Gnu
Code open source sous licence publique (GPL) et donc plutôt que d'être interdit de "regarder
sous le capot" tous les utilisateurs sont ouvertement encouragés à examiner de manière critique les plus purs et durs
code pour les erreurs, ajouter de nouveaux tests ou générateurs ou interfaces utilisateur, ou l'utiliser librement tel quel pour
tester leurs propres rngs candidats préférés sous réserve uniquement des contraintes de la GPL. Comme un
résultat de son ouverture, littéralement des centaines d'améliorations et de corrections de bugs ont été
contribué par les utilisateurs à ce jour, résultant en une suite de tests beaucoup plus solide et plus fiable
que cela n'aurait été possible avec des sources fermées et verrouillées ou même des sources ouvertes
(comme le STS) qui n'ont pas le mécanisme de rétroaction dynamique permettant d'effectuer des corrections
partagé.

Même de petites erreurs dans les statistiques de test permettent alternative (généralement non déclaré) null
hypothèse pour devenir un facteur important dans les tests rng - la possibilité fâcheuse que
votre générateur est très bien mais c'est le tester c'est défaillant. Un extrêmement utile
caractéristique du plus pur et dur est qu'il est au moins modérément soi valider. En utilisant le "or
générateurs cryptographiques standard" aes et threefish, vous pouvez observer comment ces générateurs
effectuer sur des courses plus dures avec le même degré général de précision que vous souhaitez utiliser sur
les générateurs que vous testez. En général, les tests les plus durs qui échouent systématiquement à n'importe quel
niveau de précision donné (sélectionné avec par exemple -a -m 10) sur les deux anneaux de référence
(et/ou les meilleurs générateurs GSL, mt19937, gfsr4, taus) ne sont probablement pas fiables à cela
précision et il ne serait guère surprenant qu'ils fassent également défaut à votre générateur.

Les experts en statistiques sont encouragés à essayer la suite, peut-être en utilisant l'un des
exemple ci-dessous dans un premier temps, puis en l'utilisant librement sur leurs propres générateurs ou en tant que
harnais pour ajouter leurs propres tests. Novices (à statistiques ou nombre aléatoire
test du générateur) sont fortement encouragés à lire la section suivante sur les valeurs p et les
hypothèse nulle et exécuter la suite de tests plusieurs fois avec un rapport de sortie plus détaillé
pour apprendre comment tout fonctionne.

RAPIDE La START EXEMPLES

Des exemples de configuration d'entrée de canal ou de fichier sont donnés ci-dessous. Cependant, il est recommandé
qu'un utilisateur joue avec certains des générateurs intégrés pour se familiariser avec les plus purs et durs
des rapports et des tests avant de s'attaquer à leur propre générateur préféré ou à un fichier rempli d'éventuelles
nombres aléatoires.

Pour voir le rapport de test standard par défaut de dieharder pour son générateur par défaut (mt19937) simplement
courir:

plus intransigeant -a

Pour augmenter la résolution des échecs possibles du test standard -a(ll), utilisez le -m
"multiplicateur" pour les nombres par défaut de test de pvalues ​​(qui sont plus sélectionnées pour faire un
le test complet prend environ une heure au lieu de plusieurs jours, car il s'agit vraiment d'un test exhaustif
séquence de test) exécuter :

plus dur -a -m 10

Pour tester un autre générateur (disons l'étalon-or AES_OFB) spécifiez simplement le générateur
sur la ligne de commande avec un indicateur :

plus dur -g 205 -a -m 10

Les arguments peuvent être dans n'importe quel ordre. Le générateur peut également être sélectionné par son nom :

plus dur -g AES_OFB -a

Pour appliquer uniquement le test opso pur et dur au générateur AES_OFB, spécifiez le test par son nom ou
nombre:

plus dur -g 205 -d 5

or

irréductible -g 205 -d irréductible_opso

Presque tous les aspects ou champs du format de rapport de sortie de dieharder sont sélectionnables par l'utilisateur par
moyen d'afficher des drapeaux d'options. De plus, le caractère séparateur de champ peut être sélectionné
par l'utilisateur pour rendre la sortie particulièrement facile à analyser (-c ' ') ou à importer dans
une feuille de calcul (-c ','). Essayer:

dieharder -g 205 -d diehard_opso -c ',' -D test_name -D pvalues

pour voir un rapport extrêmement concis et facile à importer ou

dieharder -g 205 -d diehard_opso -c ' ' -D par défaut -D histogramme -D description

pour voir un rapport détaillé bon pour un "débutant" qui comprend une description complète de chacun
tester lui-même.

Enfin, le binaire pur et dur est remarquablement autodocumenté même si la page de manuel n'est pas
disponible. Tous les utilisateurs doivent essayer les commandes suivantes pour voir ce qu'ils font :

plus dur -h

(imprime le synopsis de la commande comme celui ci-dessus).

plus dur -a -h
plus dur -d 6 -h

(imprime les descriptions de test uniquement pour les tests -a(ll) ou pour le test spécifique indiqué).

plus dur -l

(répertorie tous les tests connus, y compris la fiabilité de rgb selon l'état actuel des choses).

plus dur -g -1

(liste tous les rngs connus).

plus intransigeant -F

(répertorie tous les indicateurs de contrôle d'affichage/de sortie actuellement connus utilisés avec -D).

Les débutants comme les experts doivent savoir que l'évaluation fournie par les plus purs et
son rapport standard doit être considéré avec une grande méfiance. Il est tout à fait possible pour
un générateur pour "passer" tous les tests en ce qui concerne leurs valeurs p individuelles et pourtant
échouer complètement en les considérant tous ensemble. De même, il est probable qu'un rng
apparaîtra au moins comme "faible" sur 0, 1 ou 2 tests dans une exécution typique de -a(ll), et
peut même "échouer" 1 test d'une telle exécution sur 10 environ. Pour comprendre pourquoi il en est ainsi, il est
nécessaire pour comprendre quelque chose de RNG les tests, valeurs p, et le nul hypothèse!

VALEURS P ET THE NULL HYPOTHÈSE

dieharder renvoie des "valeurs p". Pour comprendre ce qu'est une p-value et comment l'utiliser, il est
essentiel pour comprendre le nul hypothèse, H0.

L'hypothèse nulle pour le test du générateur de nombres aléatoires est « Ce générateur est un
générateur de nombres aléatoires, et pour tout choix de graine produit un infiniment long, unique
séquence de nombres qui ont toutes les propriétés statistiques attendues des nombres aléatoires,
à tous les ordres". Notez bien que nous savoir que cette hypothèse est techniquement fausse pour tous
générateurs de logiciels car ils sont périodiques et n'ont pas le contenu entropique correct pour
cette déclaration à jamais être vraie. Toutefois plusieurs matériel les générateurs tombent en panne a priori aussi,
car ils contiennent des biais ou des corrélations subtils dus à la physique déterministe qui
les sous-tend. La nature est souvent imprévisible mais c'est rarement aléatoire et les deux mots
ça ne veut pas (tout à fait) dire la même chose !

L'hypothèse nulle peut être pratiquement vrai, cependant. À la fois logiciel et matériel
les générateurs peuvent être "aléatoires" assez que leurs séquences ne peuvent pas être distinguées du hasard
ceux-ci, du moins pas facilement ou avec les outils disponibles (y compris les plus purs et durs !) D'où la
L'hypothèse nulle est une affirmation pratique et non théoriquement pure.

Tester H0 , on utilise l'anneau en question pour générer une séquence de données vraisemblablement aléatoires
Nombres. En utilisant ces nombres, on peut générer n'importe lequel d'un large éventail de tester statistiques
-- nombres calculés empiriquement qui sont considérés aléatoire échantillons qui peut être ou non
covariant soumis à H0, selon que des séquences chevauchantes de nombres aléatoires sont
utilisé pour générer des échantillons successifs tout en générant la ou les statistiques, tirées d'un
Distribution. A partir d'une connaissance de la distribution cible de la ou des statistiques et de la
fonction de distribution cumulée (CDF) associée et la empirique valeur de l'aléatoire
statistique(s) générée(s), on peut lire la probabilité d'obtenir le résultat empirique
if le séquence était vraiment Aléatoire, c'est-à-dire que si l'hypothèse nulle est vraie et que le
générateur en question est un "bon" générateur de nombres aléatoires ! Cette probabilité est le "p-
value" pour l'exécution de test particulière.

Par exemple, pour tester une pièce (ou une séquence de bits), nous pourrions simplement compter le nombre de
têtes et queues dans une très longue chaîne de flips. Si nous supposons que la pièce est un « parfait
pièce", nous nous attendons à ce que le nombre de têtes et de queues soit binomialement distribué et peut facilement
calculer la probabilité d'obtenir un nombre particulier de têtes et de queues. Si nous
comparer notre nombre enregistré de têtes et queues de la série de tests à cette distribution
et trouver que la probabilité d'obtenir le nombre que nous avons obtenu est très faible avec, disons, chemin
plus de têtes que de queues, nous soupçonnerions que la pièce n'était pas une pièce parfaite. le plus dur applique ceci
très test (rendu mathématiquement précis) et bien d'autres qui opèrent sur ce même
principe à la chaîne de bits aléatoires produite par la sonnerie testée pour fournir un
image de la façon dont la sonnerie est "aléatoire".

Notez que le dogme habituel est que si la valeur p est faible - généralement inférieure à 0.05 - un
"rejette" l'hypothèse nulle. En un mot, il est peu probable que l'on obtienne le résultat
obtenu si le générateur est bon. S'il s'agit d'une autre valeur, on n'"accepte" pas
le générateur aussi bon, on "ne parvient pas à rejeter" le générateur aussi mauvais pour ce particulier
test. Un "bon générateur de nombres aléatoires" est donc celui que nous n'avons pas pu faire
échouer encore!

Ce critère est, bien sûr, naïf à l'extrême et ne peut pas be d'utiliser avec plus dur ! It
est tout aussi logique de rejeter un générateur qui a des valeurs p de 0.95 ou plus ! Les deux
ces plages de valeurs p sont également improbable sur n'importe quel test donné, et devrait être retourné
pour (en moyenne) 5 % de tous les tests effectués par un parfaite générateur de nombres aléatoires. Un générateur
qui ne parvient pas à produire des valeurs p inférieures à 0.05 5% du temps, il est testé avec différents
les graines sont un mauvais générateur de nombres aléatoires, celui qui échoue le test de l'hypothèse nulle.
Puisque dieharder renvoie plus de 100 pvalues ​​par défaut / test on s'attendrait à n'importe quel
parfaitement bon rng pour "échouer" un test aussi naïf environ cinq fois par ce critère dans un
une seule course plus dure !

Il s'avère que les valeurs p elles-mêmes sont des statistiques de test ! De par leur nature, les valeurs p
doit être uniformément répartie sur la plage 0-1. Dans plus de 100 tests avec des
graines, il ne faut pas s'étonner d'obtenir 0, 1, 2, voire (rarement) 3 p-values ​​de moins
que 0.01. D'autre part, obtenir 7 valeurs de p comprises entre 0.24 et 0.25, ou constater que
70 des valeurs p sont supérieures à 0.5 devraient rendre le générateur hautement suspect ! Comment puis
un utilisateur détermine quand un test produit « un trop grand nombre » d'une plage de valeurs particulière pour p ?
Ou trop peu ?

Dieharder le fait pour vous, automatiquement. On peut en effet convertir un set des valeurs p dans
une valeur p en comparant leur distribution à celle attendue, en utilisant un Kolmogorov-Smirnov
tester contre la distribution uniforme attendue de p.

Ces les valeurs de p obtenues en examinant la distribution des valeurs de p devraient à leur tour être
uniformément répartis et pourraient en principe être soumis à encore plus de tests KS dans
agrégat. La distribution des valeurs p pour un Bien le générateur doit être idempotent, pair
à travers différentes statistiques de test et plusieurs exécutions.

Un échec de la distribution des valeurs p à n'importe quel niveau d'agrégation signale des problèmes. Dans
fait, si les valeurs p d'un test donné sont soumises à un test KS, et ces valeurs p sont
puis soumis à un test KS, à mesure que nous ajoutons plus de valeurs de p à l'un ou l'autre niveau, nous allons soit
observer l'idempotence de la distribution résultante de p à l'uniformité, or nous allons observer
idempotence à une seule valeur p de zéro! C'est-à-dire qu'un bon générateur produira environ
distribution uniforme des p-values, dans le sens spécifique que les p-values ​​du
les distributions des valeurs p sont elles-mêmes à peu près uniformes et ainsi de suite à l'infini, tandis qu'un
un mauvais générateur produira une distribution non uniforme des valeurs p, et comme plus de valeurs p
tirés de la distribution non uniforme sont ajoutés à son test KS, à un moment donné le
l'échec sera absolument indubitable car la valeur p résultante s'approche de 0 dans le
limite. Problème en effet !

La question est, problème avec quoi? Les tests de nombres aléatoires sont eux-mêmes complexes
objets de calcul, et il y a une probabilité que leur code soit mal cadré ou
que des erreurs d'arrondi ou d'autres erreurs numériques -- non méthodiques -- contribuent à une
distorsion de la distribution de certaines des valeurs p obtenues. Ce n'est pas un ralenti
observation; quand on travaille à l'écriture de programmes de test de générateurs de nombres aléatoires, on est
toujours tester les tests eux-mêmes avec de "bons" (nous l'espérons) générateurs de nombres aléatoires afin que
les échecs flagrants de l'hypothèse nulle ne signalent pas un mauvais générateur mais une erreur dans le
code d'essai. L'hypothèse nulle ci-dessus est correctement encadrée à partir d'un théorique point de
vue, mais d'un réal et pratique point de vue, il devrait se lire : "Ce générateur est un
générateur de nombres aléatoires parfait, et pour tout choix de graine produit un infiniment long,
séquence unique de nombres qui ont toutes les propriétés statistiques attendues de random
numéros, à toutes les commandes et ce test est un test parfait et renvoie précisément le p-
valeurs du calcul du test. » « Échec » observé de cette hypothèse nulle conjointe H0'
peut provenir de la défaillance de l'un ou des deux de ces composants disjoints, et provient de la
seconde aussi souvent ou plus souvent que le premier pendant le processus de développement du test. Lorsque
on augmente la "résolution" du test (discuté ci-après) jusqu'à l'endroit où un générateur commence à
échouer à un test, on se rend compte, ou devrait se rendre compte, que le développement ne se termine jamais et que de nouveaux
les régimes de test révéleront toujours de nouvelles défaillances non seulement des générateurs mais du code.

Cela dit, l'un des avantages les plus significatifs de purs et durs est le contrôle qu'il
vous donne sur un paramètre de test critique. D'après les remarques ci-dessus, nous pouvons voir que nous
devrait se sentir très mal à l'aise sur « échouer » à un générateur de nombres aléatoires donné sur le
base d'un critère de 5 %, voire de 1 %, surtout lorsqu'on applique un test suite comme
plus dur qui renvoie plus de 100 valeurs p de test distinctes (et grimpantes) depuis le dernier
instantané. Nous voulons que l'échec soit sans ambiguïté et reproductible !

Pour ce faire, on peut simplement augmenter sa résolution. Si nous avons exécuté un test donné
contre un générateur de nombres aléatoires et il a renvoyé une valeur p de (disons) 0.007328, nous serions
parfaitement justifié de se demander si c'est vraiment un bon générateur. Cependant, le
la probabilité d'obtenir ce résultat n'est pas vraiment si petite - quand on utilise plus dur
pendant des heures, des nombres comme celui-ci arriveront certainement assez fréquemment et signifieront
rien. Si l'on exécute le même tester à nouveau (avec une graine différente ou une partie de l'aléatoire
séquence) et obtient une valeur p de 0.009122, et une troisième fois et obtient 0.002669 -- eh bien,
c'est trois tirs à 1 % (ou moins) d'affilée et qui devrait arriver seulement un sur un million
fois. Une façon de résoudre clairement les échecs consiste donc à augmenter le nombre of valeurs p
généré lors d'un test. Si la distribution réelle de p renvoyée par le test est
pas uniforme, un test KS faire une éventuelle renvoie une valeur p qui n'est pas ambiguë
0.035517 mais est à la place de 0.000000, ce dernier étant produit à chaque fois que nous réexécutons.

Pour cette raison, le plus pur extrêmement conservateur sur l'annonce de la "faiblesse" du rng ou
« échec » par rapport à un test donné. C'est un critère interne pour ces choses sont
actuellement p < 0.5% ou p > 99.5% de faiblesse (au niveau total de 1%) et un considérablement plus
critère d'échec strict : p < 0.05 % ou p > 99.95 %. Notez bien que les plages sont
symétrique -- une valeur de p trop élevée est tout aussi mauvaise (et improbable) qu'une valeur trop faible, et c'est
critique pour le signaler, car il est tout à fait possible qu'un anneau soit trop bien, en moyenne,
et de ne pas produire assez des valeurs p faibles sur l'ensemble du spectre des tests les plus durs. C'est
où le kstest final est d'une importance primordiale, et où l'option "histogramme" peut être
très utile pour vous aider à visualiser l'échec dans la distribution de p -- run ex :

dieharder [whatever] -D par défaut -D histogramme

et vous verrez un histogramme ascii brut des pvalues ​​qui ont échoué (ou réussi)
niveau d'épreuve.

Des rapports éparpillés de faiblesse ou d'échec marginal dans un essai préliminaire -a(ll) devraient
donc pas être une cause immédiate d'alarme. Ce sont plutôt des tests à répéter, à surveiller
out for, pour pousser le rng plus fort en utilisant l'option -m à -a ou simplement en augmentant -p pour un
épreuve spécifique. Dieharder permet d'augmenter le nombre de valeurs p générées pour tout
test, sous réserve uniquement de la disponibilité de nombres aléatoires suffisants (pour les tests basés sur des fichiers) et
temps, pour rendre les échecs sans ambiguïté. Un test qui est vraiment faible à -p 100 sera presque
échouent toujours de manière flagrante à une valeur plus grande de psamples, que ce soit -p 1000 ou -p 100000.
Cependant, parce que dieharder est un outil de recherche et est en perpétuel développement et
test, c'est fortement suggéré que l'on considère toujours l'hypothèse nulle alternative
-- que l'échec est un échec du code de test dans plus dur lui-même dans une certaine limite de
grands nombres -- et prenez au moins quelques étapes (comme exécuter le même test au même
résolution sur un générateur "gold standard") pour s'assurer que la panne est bien probablement
dans le rng et non dans le code le plus pur.

Manque une source de parfaite nombres aléatoires à utiliser comme référence, validant les tests
eux-mêmes n'est pas facile et laisse toujours une certaine ambiguïté (même aes ou threefish).
Pendant le développement, le mieux que l'on puisse faire est de s'appuyer fortement sur ces "présumés bons"
générateurs de nombres aléatoires. Il y a un certain nombre de générateurs que nous avons théoriques
raisons de s'attendre à être extraordinairement bonnes et à manquer de corrélations avec certains
dimensionnalité sous-jacente, et qui se teste également extrêmement bien de manière assez cohérente. Par
en utilisant plusieurs de ces générateurs et pas un seul, on peut espérer que ces générateurs ont
(tout au moins) différent corrélations et ne devraient pas tous échouer uniformément à un test dans le
de la même manière et avec le même nombre de p-values. Quand tous ces générateurs régulièrement
échouer à un test à un niveau donné, j'ai tendance à soupçonner que le problème est dans le code de test, pas
les générateurs, bien qu'il soit très difficile d'être Bien sur, et de nombreuses erreurs dans
le code de dieharder a été découvert et finalement corrigé de cette manière par moi-même ou
autres.

L'un des avantages de purs et durs est qu'il dispose immédiatement d'un certain nombre de ces "bons générateurs"
disponible pour les courses de comparaison, avec l'aimable autorisation de la bibliothèque scientifique Gnu et de l'utilisateur
contribution (notamment David Bauer, qui a gentiment encapsulé aes et threefish). j'utilise
AES_OFB, Threefish_OFB, mt19937_1999, gfsr4, ranldx2 et taus2 (ainsi que "true random"
numéros de random.org) à cette fin, et j'essaie de m'assurer que les plus purs et durs "passeront"
en particulier le générateur -g 205 -S 1 -s 1 à n'importe quelle résolution de valeur p raisonnable jusqu'à
-p 1000 ou plus.

Des tests (tels que l'operm5 pur et dur et le test des sommes) qui systématiquement échouer à ces hauts
les résolutions sont signalées comme étant « suspectes » - les échecs possibles de la alternative nul
hypothèse - et ils sont fortement obsolète ! Leurs résultats ne doivent pas être utilisés pour tester
générateurs de nombres aléatoires en attente d'accord dans la communauté des statistiques et des nombres aléatoires
que ces tests sont en fait valides et corrects, de sorte que les défaillances observées peuvent effectivement
être attribué à un échec de la prévu hypothèse nulle.

Comme je continue de le souligner (pour une bonne raison !), le plus pur et dur est soutenu par la communauté. je donc
demander ouvertement aux utilisateurs de purs et durs qui sont experts en statistiques de m'aider à corriger le
code ou algorithmes en cours d'implémentation. J'aimerais que cette suite de tests soit finalement
validé par la communauté statistique générale en usage intensif dans un environnement ouvert, où
tout échec possible du mécanisme de test lui-même est soumis à un examen minutieux et
correction. De cette façon, nous finirons par obtenir une suite d'outils très puissante,
ceux qui pourraient bien nous donner des informations très précises non seulement sur l'échec, mais sur les
mode d'échec également, à quel point la séquence testée s'écarte du caractère aléatoire.

Jusqu'à présent, les plus purs et durs ont énormément bénéficié de la communauté. Les individus ont
des tests ouvertement contribués, de nouveaux générateurs à tester et des correctifs pour les tests existants qui
ont été révélés par leur propre travail avec l'instrument de test. Des efforts sont en cours pour faire
plus dur plus portable pour qu'il puisse s'appuyer sur plus de plates-formes et plus rapidement pour que plus
des tests approfondis peuvent être effectués. N'hésitez pas à participer.

DOSSIER CONTRIBUTION

La façon la plus simple d'utiliser plus dur avec un générateur externe qui produit du binaire brut
bits (présumés aléatoires) est de diriger la sortie binaire brute de ce générateur (présumé à
être un flux binaire d'entiers non signés de 32 bits) directement dans le plus pur et dur, par exemple :

chat /dev/urandom | ./plus dur -a -g 200

Allez-y et essayez cet exemple. Il exécutera toute la série de tests les plus purs et durs sur le
flux produit par le générateur intégré de Linux /dev/urandom (l'utilisation de /dev/random n'est pas
recommandé car il est trop lent à tester dans un laps de temps raisonnable).

Alternativement, dieharder peut être utilisé pour tester des fichiers de nombres produits par un candidat
générateurs de nombres aléatoires :

plus dur -a -g 201 -f random.org_bin

pour entrée binaire brute ou

plus dur -a -g 202 -f random.org.txt

pour l'entrée ASCII formatée.

Un fichier d'entrée ASCII formaté peut accepter soit des uints (entiers compris entre 0 et 2^31-1,
un par ligne) ou des écarts décimaux uniformes d'au moins dix chiffres significatifs (qui peuvent
être multiplié par UINT_MAX = 2^32 pour produire un uint sans perdre la précision), également un
par ligne. Les flotteurs avec moins de chiffres échoueront presque certainement aux tests de niveau de bit, bien que
ils peuvent réussir certains des tests qui agissent sur des écarts uniformes.

Enfin, on peut assez facilement envelopper n'importe quel générateur dans le même faisceau de nombres aléatoires (GSL)
utilisé en interne par les plus purs et durs et testez-le simplement de la même manière que n'importe quel autre interne
générateur reconnu par les purs et durs. Ceci est fortement recommandé lorsque cela est possible,
parce que les plus purs et durs ont besoin d'utiliser un lot de nombres aléatoires pour tester en profondeur un générateur. UNE
le générateur intégré peut simplement laisser le plus pur et dur déterminer le nombre dont il a besoin et les générer
à la demande, où un fichier trop petit va "rembobiner" et rendre les résultats du test où
un rembobinage se produit suspect.

Notez bien que les rands d'entrée de fichier sont livrés aux tests à la demande, mais si le test
a besoin de plus que ce qui est disponible, il rembobine simplement le fichier et le parcourt à nouveau, et
encore et encore au besoin. Évidemment, cela réduit considérablement l'espace de l'échantillon et peut
conduire à des résultats complètement incorrects pour les histogrammes de valeur p, à moins qu'il n'y en ait suffisamment
rands pour exécuter CHAQUE test sans répétition (il est inoffensif de réutiliser la séquence pour
différents tests). Que l'utilisateur se méfie !

BEST PRATIQUE

Une question fréquemment posée par de nouveaux utilisateurs souhaitant tester un générateur sur lequel ils travaillent
pour le plaisir ou le profit (ou les deux) est "Comment devrais-je obtenir sa sortie dans les plus purs et durs ?" C'est un
question non triviale, car les plus purs et durs consomment énorme nombres de nombres aléatoires dans un plein
cycle de test, et puis il y a des fonctionnalités comme -m 10 ou -m 100 qui permettent un sans effort
exiger 10 ou 100 fois plus pour stresser encore plus un nouveau générateur.

Pourtant, la avec gros filet soutenez en plus dur, il est difficile de fournir assez aléatoire
nombres dans un fichier pour vraiment rendre les plus purs et durs heureux. Il est donc fortement suggéré qui
vous soit:

a) Modifiez l'étage de sortie de votre générateur de nombres aléatoires et demandez-lui d'écrire son
production à stdout en tant que aléatoire Bits courant -- créer essentiellement 32 bits aléatoires non signés
entiers et écrivez-les directement sur stdout comme, par exemple, des données de caractère ou un binaire brut. Noter que
c'est pas la même chose que d'écrire des nombres à virgule flottante bruts (ce ne sera pas du tout aléatoire
en tant que flux binaire) et que "l'endianité" des uints ne devrait pas avoir d'importance pour le null
hypothèse d'un "bon" générateur, car les octets aléatoires sont aléatoires dans n'importe quel ordre. Démarrez le
générateur et alimenter ce flux jusqu'au plus dur dans un tuyau comme décrit ci-dessus.

b) Utilisez les échantillons d'anneaux plus résistants enveloppés de GSL pour envelopper de la même manière votre générateur (ou
appels à l'interface matérielle de votre générateur). Suivez les exemples dans le ./dieharder
répertoire source pour l'ajouter en tant que générateur "utilisateur" dans l'interface de ligne de commande, reconstruire,
et invoquez le générateur en tant que générateur pur et dur "natif" (il devrait apparaître dans la liste
produit par -g -1 lorsqu'il est fait correctement). L'avantage de procéder ainsi est que vous
peut alors (si votre nouveau générateur est très efficace) le redonner aux plus purs et durs
projet si vous le souhaitez! Sans parler du fait que cela rend le test très facile.

La plupart des utilisateurs opteront probablement pour l'option a) au moins au début, mais sachez que b) est
probablement plus facile que vous ne le pensez. Les mainteneurs les plus purs et durs Au cours de cette réunion, Matthew a obtenu de précieux conseils et Linda lui a demandé de la tenir au courant de ses progrès. pouvoir te donner un coup de main
avec elle si vous avez des ennuis, mais pas de promesses.

AVERTISSEMENT!

Un avertissement pour ceux qui testent des fichiers de nombres aléatoires. dieharder est un outil qui
tests aléatoire nombre générateurs, pas fichiers of aléatoire Nombres! C'est extrêmement
inapproprié d'essayer de "certifier" un fichier de nombres aléatoires comme étant aléatoire simplement parce qu'il
ne parvient pas à "échouer" à l'un des tests les plus durs dans, par exemple, une exécution de dieharder -a. Pour le dire franchement,
si l'on rejette tous ces fichiers qui échouent à un test au niveau 0.05 (ou à tout autre), celui
chose dont on peut être certain, c'est que les fichiers en question sont pas aléatoire, en tant que vraiment
une séquence aléatoire échouerait à n'importe quel test au niveau 0.05 5% du temps !

En d'autres termes, tout fichier de nombres produit par un générateur qui "n'échoue pas"
la suite irréductible doit être considérée comme "aléatoire", même si elle contient des séquences qui
pourrait bien "échouer" à n'importe quel test donné à un certain seuil spécifique. Il faut présumer que passer
les tests plus larges du générateur lui-même, il a été déterminé que les valeurs p pour le
le test impliqué était l'échelle mondiale correctement distribué, de sorte que, par exemple, une défaillance au niveau de 0.01
se produit ni plus ni moins de 1% du temps, en moyenne, sur de nombreux tests. Si
un fichier particulier génère un échec à ce niveau, on peut donc sans risque présumer
que c'est un aléatoire fichier extrait de plusieurs milliers de fichiers similaires, le générateur pourrait
créer qui ont la distribution correcte des valeurs p à tous les niveaux de test et
agrégation.

Pour résumer, utilisez dieharder pour valider votre générateur (via l'entrée de fichiers ou un
flux). Ensuite, par tous les moyens, utilisez votre générateur pour produire des fichiers ou des flux de données aléatoires.
Nombres. N'utilisez pas dieharder comme outil d'acceptation/rejet pour valider le fichiers se!

EXEMPLES

Pour démontrer tous les tests, exécutez l'anneau GSL par défaut, saisissez :

plus intransigeant -a

Pour démontrer un test d'un générateur externe d'un flux binaire brut de bits, utilisez le
interface stdin (brute) :

chat /dev/urandom | plus dur -g 200 -a

Pour l'utiliser avec un fichier au format ascii :

plus dur -g 202 -f testrands.txt -a

(testrands.txt doit être constitué d'un en-tête tel que :

#================================================= ==================
# générateur mt19937_1999 seed = 1274511046
#================================================= ==================
tapez: d
compte : 100000
nombre : 32
3129711816
85411969
2545911541

etc).

Pour l'utiliser avec un fichier binaire

plus dur -g 201 -f testrands.bin -a

or

chat testrands.bin | plus dur -g 200 -a

Un exemple qui démontre l'utilisation de "préfixes" sur les lignes de sortie qui le rendent
relativement facile de filtrer les différentes parties du rapport de sortie et de les découper
en nombres pouvant être utilisés dans d'autres programmes ou dans des feuilles de calcul, essayez :

plus dur -a -c ',' -D par défaut -D préfixe

DISPLAY OPTIONS

Depuis la version 3.xx, dieharder a une seule interface de sortie qui produit des données tabulaires
par test, avec des informations communes dans les en-têtes. Les options de contrôle d'affichage et les drapeaux peuvent
être utilisé pour personnaliser la sortie en fonction de vos besoins spécifiques.

Les options sont contrôlées par des drapeaux binaires. Les drapeaux et leurs versions textuelles sont
affiché si vous saisissez :

plus intransigeant -F

par lui-même sur une ligne.

Les drapeaux peuvent être entrés tous à la fois en additionnant tous les drapeaux d'options souhaités. Pour
exemple, une sortie très clairsemée pourrait être sélectionnée en ajoutant les drapeaux pour le test_name (8)
et les pvalues ​​associées (128) pour obtenir 136 :

plus dur -a -D 136

Étant donné que les indicateurs sont cumulés à partir de zéro (sauf si aucun indicateur n'est entré et que la valeur par défaut est
utilisé) vous pouvez accomplir le même affichage via :

plus dur -a -D 8 -D valeurs p

Notez que vous pouvez saisir des indicateurs par valeur ou par nom, dans n'importe quelle combinaison. Parce que les gens utilisent
plus dur pour obtenir des valeurs, puis avec pour les exporter dans des feuilles de calcul (séparés par des virgules
valeurs) ou dans des scripts de filtrage, vous pouvez utiliser le caractère séparateur de champ. Pour
Exemple:

plus dur -a -c ',' -D par défaut -D -1 -D -2

produit une sortie idéale pour l'importation dans une feuille de calcul (notez que l'on peut soustraire
valeurs de champ de l'ensemble de champs de base fourni par l'option par défaut tant qu'elle est
donné en premier).

Une option intéressante est l'indicateur de préfixe -D, qui active un préfixe d'identifiant de champ pour
facilitent le filtrage de types particuliers de données. Cependant, il est tout aussi facile de tourner
sur un type particulier de production à l'exclusion des autres directement au moyen de la
drapeaux.

Deux autres indicateurs d'intérêt pour les novices des tests de générateur de nombres aléatoires sont le -D
histogramme (active un histogramme des valeurs p sous-jacentes, par test) et -D description
(active une description complète du test, par test). Ces indicateurs transforment la table de sortie en
plus d'une série de « rapports » de chaque test.

PUBLICATION DES RÈGLES

plus intransigeant est un code entièrement original et peut être modifié et utilisé à volonté par tout utilisateur,
à condition que:

a) Les avis de droits d'auteur originaux sont conservés et que la source, y compris tous les
modifications, est rendu public au moment de toute publication dérivée. Cette
est un logiciel open source selon les préceptes et l'esprit de la licence publique Gnu.
Voir le fichier d'accompagnement COPIE, qui doit également accompagner toute redistribution.

b) L'auteur principal du code (Robert G. Brown) est dûment reconnu et
référencé dans toute publication dérivée. Il est fortement suggéré que George Marsaglia et
la suite Diehard et les divers auteurs de la suite de tests statistiques soient de même
reconnu, bien que cette suite ne partage aucun code réel avec ces tests de nombres aléatoires
suites

c) L'entière responsabilité de l'exactitude, de la pertinence et de l'efficacité du programme
appartient aux utilisateurs et/ou modificateurs. Comme il est clairement indiqué dans l'accompagnement
copyright.h :

LES TITULAIRES DES DROITS D'AUTEUR EXCLUENT TOUTE GARANTIE CONCERNANT CE LOGICIEL, Y COMPRIS TOUS
GARANTIES IMPLICITES DE QUALITÉ MARCHANDE ET D'APTITUDE, EN AUCUN CAS LES TITULAIRES DES DROITS D'AUTEUR
ÊTRE RESPONSABLE DE TOUT DOMMAGE SPÉCIAL, INDIRECT OU CONSÉCUTIF OU DE TOUT DOMMAGE QUELQUE SOIT
RÉSULTANT D'UNE PERTE D'UTILISATION, DE DONNÉES OU DE BÉNÉFICES, QUE CE SOIT DANS UNE ACTION DE CONTRAT, PAR NÉGLIGENCE
OU AUTRE ACTION DÉLICTUELLE, DÉCOULANT DE OU EN RELATION AVEC L'UTILISATION OU L'EXÉCUTION DE
CE LOGICIEL.

REMERCIEMENTS

L'auteur de cette suite remercie George Marsaglia (l'auteur de la
suite de tests purs et durs) et les divers auteurs de la publication spéciale NIST 800-22 (qui
décrit la suite de tests statistiques pour tester les générateurs de nombres pseudo-aléatoires pour
applications cryptographiques), pour d'excellentes descriptions des tests qu'il contient. Ces
les descriptions ont permis de développer cette suite avec une GPL.

L'auteur souhaite également réitérer que l'exactitude et l'exactitude académiques des
la mise en œuvre de ces tests relève de sa seule responsabilité et non de celle des auteurs de
les suites Diehard ou STS. Cela est particulièrement vrai lorsqu'il a jugé bon de modifier ces
tests à partir de leurs descriptions originales strictes.

DROIT D'AUTEUR

GPL 2b ; voir le fichier COPYING qui accompagne le source de ce programme. C'est le
"Gnu General Public License version 2 ou toute version ultérieure", avec le mineur
(humoristique) Modification « Boisson » énumérée ci-dessous. Notez que cette modification est probablement
pas légalement défendable et peut être suivi à peu près selon la règle de l'honneur.

Quant à mes préférences personnelles en matière de boissons, le vin rouge est excellent, la bière est délicieuse et
Coca Cola ou café ou thé ou même lait acceptable pour ceux qui, à des fins religieuses ou personnelles
raisons souhaitent éviter de stresser mon foie.

Le Boissons Modification à le GPL :

Tout utilisateur satisfait de ce logiciel doit, après avoir rencontré le(s) auteur(s) principal(aux) de ce
logiciel pour la première fois dans les circonstances appropriées, proposez-lui de l'acheter
ou eux une boisson. Cette boisson peut être alcoolisée ou non, selon les
vues éthiques et morales de l'offrant. Le coût des boissons ne doit pas dépasser un dollar américain
(bien que cela puisse certainement être au gré de l'offrant :-) et peut être accepté ou refusé
sans autre obligation de la part de l'offrant. Il n'est pas nécessaire de répéter le
offre après la première rencontre, mais ça ne peut pas faire de mal...

Utilisez dieharder en ligne en utilisant les services onworks.net