dieharder - Online in de cloud

PROGRAMMA:

NAAM

dieharder - A het testen van en benchmarking tools voor betere willekeurige aantal generatoren.

KORTE INHOUD

dieharder [-a] [-d dieharder testnummer] [-f bestandsnaam] [-B]
[-D uitvoervlag [-D uitvoervlag] ... ] [-F] [-c scheidingsteken]
[-g generatornummer of -1] [-h] [-k ks_flag] [-l]
[-L overlapping] [-m vermenigvuldig_p] [-n verdubbelen]
[-p aantal p monsters] [-P Xoff]
[-o bestandsnaam] [-s seed-strategie] [-S random number seed]
[-n dubbel] [-p aantal p monsters] [-o bestandsnaam]
[-s zaadstrategie] [-S willekeurig nummer zaad]
[-t aantal testvoorbeelden] [-v uitgebreide vlag]
[-W zwak] [-X mislukt] [-Y Xtrategy]
[-x xwaarde] [-y ywaarde] [-zz waarde]

dieharder OPTIES

-a voert alle tests uit met standaard/standaard opties om een
door de gebruiker controleerbaar rapport. Zie -D hieronder om de opmaak van het rapport te bepalen.
Om de kracht van de test te controleren (die standaardwaarden gebruikt voor tsamples that
kan over het algemeen niet worden gevarieerd en psamples die over het algemeen -m hieronder kunnen zien als a
"vermenigvuldiger" van het standaard aantal psamples (alleen gebruikt in een -a run).

-d testnummer - selecteert een specifieke diehard-test.

-f bestandsnaam - generatoren 201 of 202 staan ​​ofwel onbewerkt binair of
geformatteerde ASCII-nummers om te worden ingelezen uit een bestand om te testen. generator 200 leest
in ruwe binaire getallen van stdin. Let goed op: veel tests met standaardparameters
veel rands nodig! Om een ​​voorbeeld te zien van de (vereiste) header voor ASCII
geformatteerde invoer, uitvoeren

dieharder -o -f voorbeeld.invoer -t 10

en onderzoek vervolgens de inhoud van example.input. Ruwe binaire invoer leest 32 bit
incrementen van de gespecificeerde gegevensstroom. stdin_input_raw accepteert een pijp van een raw
binaire stroom.

-B binaire modus (hieronder gebruikt met -o) zorgt ervoor dat uitvoerranden worden geschreven in onbewerkt binair, niet
geformatteerde ascii.

-D uitvoervlag - staat toe dat velden worden geselecteerd voor opname in
dieharder uitgang. Elke vlag kan worden ingevoerd als een binair getal dat a inschakelt
specifiek uitvoerveld of koptekst of op vlagnaam; vlaggen zijn samengevoegd. Om alles te zien
momenteel bekende vlaggen gebruiken de opdracht -F.

-F - somt alle bekende vlaggen op naam en nummer op.

-c tabelscheidingsteken - waarbij het scheidingsteken bijvoorbeeld ',' (CSV) of ' ' (witruimte) is.

-g generatornummer - selecteert een specifieke generator om te testen. Gebruik makend van
-g -1 zorgt ervoor dat alle bekende generatoren op het display worden afgedrukt.

-h drukt contextgevoelige hulp af -- meestal Gebruik (dit bericht) of a
test synopsis indien ingevoerd als bijv. dieharder -d 3 -h.

-k ks_vlag - ks_vlag

0 is snel maar enigszins slordig voor psamples > 4999 (standaard).

1 is VEEL langzamer maar nauwkeuriger voor grotere aantallen psamples.

2 is nog langzamer, maar (hopen we) nauwkeurig tot machinale precisie voor een willekeurig aantal
psamples tot een nog onbekende numerieke bovengrens (het is getest tot
minstens honderdduizenden).

3 is kuiper ks, snel, behoorlijk onnauwkeurig voor kleine samples, verouderd.

- Ik som alle bekende testen op.

-L overlappen

1 (gebruik overlap, standaard)

0 (geen overlapping gebruiken)

in operm5 of andere tests die overlappende en niet-overlappende voorbeeldmodi ondersteunen.

-m multiply_p - vermenigvuldig standaard aantal psamples in -a(ll) runs om te starten
de oplossing van mislukking. -n ntuple - stel een dubbele lengte in voor tests op korte bits
strings waarmee de lengte kan worden gevarieerd (bijv. rgb bitdist).

-o bestandsnaam - uitvoer -t tel willekeurige getallen van huidige generator naar bestand.

-p count - stelt het aantal p-waardemonsters per test in (standaard 100).

-P Xoff - stelt het aantal psamples in dat wordt gecumuleerd voordat een beslissing wordt genomen
dat een generator "goed" is en echt, echt zelfs een -Y 2 T2D-run doorstaat. Momenteel
de standaardwaarde is 100000; uiteindelijk zal het worden ingesteld op basis van een AES-afgeleide T2D-testfout
drempels voor volledig geautomatiseerde betrouwbare werking, maar voor nu is het meer een
drempel voor "verveling" die wordt bepaald door hoe lang men redelijkerwijs op een gegeven zou willen wachten
proefdraaien.

-S seed - waar seed een uint is. Overschrijft de standaard willekeurige seed
selectie. Genegeerd voor bestands- of stdin-invoer.

-s strategie - als de strategie de (standaard) 0 is, herzaait dieharder (of
terugspoelen) eenmaal aan het begin wanneer de generator voor willekeurige getallen is geselecteerd en
dan nooit meer. Als de strategie niet nul is, wordt de generator opnieuw geplaatst of teruggespoeld op
het begin van ELKE TEST. Als -S seed is opgegeven, of als er een bestand wordt gebruikt, wordt dit
betekent dat elke test wordt toegepast op dezelfde reeks (wat handig is voor validatie
en testen van dieharder, maar geen goede manier om rngs te testen). Anders een nieuwe willekeurige
zaad wordt geselecteerd voor elke test.

-t count - stelt het aantal willekeurige entiteiten in dat in elke test wordt gebruikt, waar
mogelijk. Wees gewaarschuwd: sommige tests hebben vaste steekproefomvang; anderen zijn variabel maar
hebben praktische minimummaten. Het wordt aanbevolen om te beginnen met de waarden die worden gebruikt in -a
en experimenteer zorgvuldig per test.

-W zwak - stelt de "zwakke" drempel in om de test(s) meer of minder te maken
vergevingsgezind tijdens bijvoorbeeld een test-to-destruct run. Standaard is momenteel 0.005.

-X mislukt - stelt de "mislukt"-drempel in om de test(s) meer of minder te maken
vergevingsgezind tijdens bijvoorbeeld een test-to-destruct run. Standaard is momenteel 0.000001,
wat in feite "zekere mislukking van de nulhypothese" is, de gewenste manier van
reproduceerbare generatorstoring.

-Y Xtrategy - de Xtrategy-vlag bestuurt de nieuwe "test tot falen" (T2F)
modi. Deze vlaggen en hun modi werken als volgt:

0 - voer gewoon dieharder uit met het opgegeven aantal tsamples en psamples, niet doen
een run dynamisch wijzigen op basis van resultaten. Dit is de manier waarop het altijd heeft gelopen, en
is de standaard.

1 - "dubbelzinnigheid oplossen" (RA) modus. Als een test "zwak" retourneert, is dit een
ongewenst resultaat. Wat betekent dat tenslotte? Als u een lange testreeks uitvoert,
je zult af en toe een zwak rendement zien voor een perfecte generator omdat p is
gelijkmatig verdeeld en zal van tijd tot tijd verschijnen in elk eindig interval.
Zelfs als een testrun meer dan één zwak resultaat oplevert, kunt u daar niet zeker van zijn
de generator valt uit. De RA-modus voegt psamples toe (meestal in blokken van 100) tot
het testresultaat eindigt stevig niet zwak of gaat over tot ondubbelzinnig falen. Dit
is moreel gelijk aan het meerdere keren uitvoeren van de test om te zien of een zwak resultaat is
reproduceerbaar, maar elimineert de vertekening van persoonlijk oordeel in het proces sindsdien
de standaard faaldrempel is erg klein en het is zeer onwaarschijnlijk dat deze wordt bereikt
willekeurige kans, zelfs in veel runs.

Deze optie moet Slechts be gebruikt with -k 2.

2 - "test tot vernietiging" -modus. Soms wil je gewoon weten waar en of een
generator zal .Ik zak ooit voor een test (of testreeks). -Y 2 zorgt ervoor dat psamples zijn
100 per keer toegevoegd totdat een test een algehele p-waarde retourneert die lager is dan de fout
drempel of een gespecificeerd maximum aantal psamples (zie -P) is bereikt.

Let goed op! In deze modus kan men heel goed mislukken vanwege de afwisselend nulhypothese --
de test zelf is een slechte test en faalt! Veel dieharder-tests, ondanks ons beste
inspanningen, numeriek onstabiel zijn of slechts een ongeveer bekend doel hebben
statistieken of zijn regelrechte asymptotische resultaten, en zullen uiteindelijk een
falend resultaat, zelfs voor een generator met gouden standaard (zoals AES), of voor de
hypercautious de XOR-generator met AES, threefish, kiss, allemaal tegelijk geladen en
xor'd samen. Het is daarom het veiligst om deze modus te gebruiken.
uitvoeren van een T2D-run op AES om een ​​idee te krijgen van de testfoutdrempel(s)
(iets wat ik uiteindelijk zal doen en publiceren op het web, zodat niet iedereen dat hoeft te doen
doe het onafhankelijk) en voer het vervolgens uit op uw doelgenerator. Mislukking met
aantal psamples binnen een orde van grootte van de AES-drempels
waarschijnlijk worden beschouwd als mogelijke teststoringen, niet als generatorstoringen. Storingen bij
niveaus aanzienlijk lager dan de bekende drempelwaarden voor generatorstoringen
zijn natuurlijk waarschijnlijk storingen van de generator.

Deze optie moet Slechts be gebruikt with -k 2.

-v uitgebreide vlag -- regelt de breedsprakigheid van de uitvoer voor foutopsporing
alleen. Waarschijnlijk van weinig nut voor niet-ontwikkelaars, en ontwikkelaars kunnen het
enum(s) in dieharder.h en de testbronnen om te zien welke vlagwaarden uitvoer inschakelen
op welke routines. 1 resulteert in een zeer gedetailleerd spoor van programma-activiteit.

-x,-y,-z getal - Sommige tests hebben parameters die veilig kunnen worden gevarieerd
van hun standaardwaarde. In de diehard birthdays test kan men bijvoorbeeld variëren
het aantal lengtes, dat ook kan worden gevarieerd. -x 2048 -y 30 verandert deze twee
waarden, maar zou nog steeds goed moeten werken. Deze parameters moeten intern worden gedocumenteerd
(waar ze bestaan) in de bijv. -d 0 -h zichtbare noten.

NOTITIE GOED: De beoordeling(en) voor de rngs kunnen namelijk geheel onjuist zijn of
misleidend. Er zijn nog steeds "slechte tests" in dieharder, hoewel we eraan werken
repareer en verbeter ze (en probeer ze te documenteren in de testbeschrijvingen zichtbaar
met -g testnummer -h). Met name 'zwakke' p-waarden zouden één test op twee moeten voorkomen
honderd, en 'Mislukte' pwaarden zouden met de standaardwaarde één test op een miljoen moeten voorkomen
drempels - dat is wat p BETEKENT. Gebruik ze op eigen risico! Wees gewaarschuwd!

Of beter nog, gebruik de nieuwe -Y 1 en -Y 2 om ambiguïteit op te lossen of tot vernietiging te testen
modi hierboven, in vergelijking met vergelijkbare uitvoeringen op een van de zo goed als mogelijk
cryptografische generatoren, AES of threefish.

PRODUCTBESCHRIJVING

dieharder

Welkom bij de huidige snapshot van de dieharder random number tester. Het kapselt in
alle random number generators (rngs) van de Gnu Scientific Library (GSL) en een
aantal generatoren uit de statistische R-bibliotheek, hardwarebronnen zoals
/ Dev /*willekeurige, "gouden standaard" cryptografische kwaliteitsgeneratoren (handig voor testen
dieharder en ter vergelijking met nieuwe generatoren) en generatoren
bijgedragen door gebruikers of gevonden in de literatuur in een single harnas dat kan ze timen
en onderwerp ze aan verschillende tests op willekeur. Deze tests zijn op verschillende manieren afkomstig uit
George Marsaglia's "Diehard battery of random number tests", de NIST Statistical Test
Suite, en opnieuw uit andere bronnen, zoals persoonlijke uitvinding, gebruikersbijdrage, andere
(open source) testsuites of de literatuur.

Het belangrijkste punt van dieharder is om het gemakkelijk te maken om (pseudo)willekeurige getallen te timen en te testen
generatoren, inclusief zowel software als hardware rngs, met een volledig open source tool. In
naast het bieden van "directe" toegang tot het testen van alle ingebouwde generatoren, kunnen gebruikers dat ook
kies een van de drie manieren om hun eigen random number generators of bronnen te testen: een unix
pijp van een onbewerkte binaire (vermoedelijk willekeurige) bitstroom; een bestand met een (vermoedelijk willekeurige)
onbewerkte binaire bitstream of geformatteerde ascii uints of floats; en je generator insluiten
dieharder's GSL-compatibele RNG-harnas en deze toe te voegen aan de lijst met ingebouwde generatoren.
De stdin- en bestandsinvoermethoden worden hieronder beschreven in hun eigen sectie, zoals wordt gesuggereerd
"best practice" voor nieuwkomers op het gebied van het testen van generatoren met willekeurige getallen.

Een belangrijke motivatie om dieharder te gebruiken is dat de hele testsuite volledig Gnu is
Public License (GPL) open source code en dus in plaats van verboden te zijn om te "kijken
onder de motorkap" worden alle gebruikers openlijk aangemoedigd om de dieharder kritisch te bekijken
code voor fouten, voeg nieuwe tests of generators of gebruikersinterfaces toe, of gebruik het vrij zoals het is
hun eigen favoriete kandidaat-rngs testen, alleen onderworpen aan de beperkingen van de GPL. Als een
resultaat van zijn openheid zijn er letterlijk honderden verbeteringen en bugfixes geweest
bijgedragen door gebruikers tot nu toe, resulterend in een veel sterkere en betrouwbaardere testsuite
dan mogelijk zou zijn geweest met gesloten en vergrendelde bronnen of zelfs open bronnen
(zoals STS) die het dynamische feedbackmechanisme missen waardoor correcties mogelijk zijn
gedeeld.

Zelfs kleine fouten in teststatistieken maken het mogelijk alternatief (meestal niet vermeld) null
hypothese een belangrijke factor worden bij rng-testen -- de onwelkome mogelijkheid dat
uw generator is prima, maar het is de proef dat gaat mis. Een uiterst nuttig
kenmerk van dieharder is dat het in ieder geval matig is zelf valideren. Met behulp van de "goud
standaard" aes en threefish cryptografische generatoren, kunt u zien hoe deze generatoren
voer op dieharder-runs uit met dezelfde algemene mate van nauwkeurigheid die u wilt gebruiken
de generatoren die u aan het testen bent. Over het algemeen dieharder-tests die consequent op geen enkele manier falen
bepaald precisieniveau (geselecteerd met bijvoorbeeld -a -m 10) op beide gouden standaardringen
(en/of de betere GSL-generatoren, mt19937, gfsr4, taus) zijn daar waarschijnlijk onbetrouwbaar
precisie en het zou niet verwonderlijk zijn als ze ook uw generator zouden uitvallen.

Deskundigen in statistiek worden aangemoedigd om de suite eens te proberen, misschien met behulp van een van de
voorbeeld roept eerst hieronder en gebruikt het vervolgens vrijelijk op hun eigen generatoren of als een
harnas voor het toevoegen van hun eigen tests. Beginners (naar statistieken of willekeurig nummer
generator testen) zijn sterk aangemoedigd om het volgende gedeelte over p-waarden en de
nulhypothese en de testsuite een paar keer uitvoeren met een uitgebreider uitvoerrapport
leren hoe het allemaal werkt.

SNEL START MET Voorbeelden

Voorbeelden voor het instellen van pipe- of file-invoer worden hieronder gegeven. Het is echter aan te raden
dat een gebruiker met enkele van de ingebouwde generatoren speelt om vertrouwd te raken met dieharder
rapporten en tests voordat ze hun eigen favoriete generator of bestand vol evt
willekeurige nummers.

Om eenvoudig het standaard standaardtestrapport van dieharder voor zijn standaardgenerator (mt19937) te zien
rennen:

dieharder-a

Gebruik de -m om de resolutie van mogelijke mislukkingen van de standaard -a(ll)-test te verhogen
"vermenigvuldiger" voor de standaard testgetallen van pwaarden (die meer worden geselecteerd om a
volledige testrun duurt ongeveer een uur in plaats van dagen dan omdat het echt een uitputtende test is
testvolgorde) uitvoeren:

dieharder -a-m 10

Om een ​​andere generator te testen (bijvoorbeeld de gouden standaard AES_OFB) specificeert u gewoon de generator
op de opdrachtregel met een vlag:

dieharder -g 205 -a -m 10

Argumenten kunnen in willekeurige volgorde staan. De generator kan ook op naam worden geselecteerd:

dieharder -g AES_OFB -a

Toepassen Slechts de diehard opso-test naar de AES_OFB-generator, specificeer de test met naam of
aantal:

dieharder -g 205 -d 5

or

dieharder -g 205 -d diehard_opso

Bijna elk aspect of veld in het uitvoerrapportformaat van dieharder kan door de gebruiker worden geselecteerd
middel van weergaveoptievlaggen. Bovendien kan het veldscheidingsteken worden geselecteerd
door de gebruiker om de uitvoer bijzonder gemakkelijk te ontleden (-c ' ') of erin te importeren
een rekenblad (-c ','). Poging:

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

om een ​​extreem bondig, gemakkelijk te importeren rapport te bekijken of

dieharder -g 205 -d diehard_opso -c ' ' -D standaard -D histogram -D beschrijving

om een ​​uitgebreid rapport goed te zien voor een "beginner" dat een volledige beschrijving van elk bevat
zelf testen.

Ten slotte is het dieharder-binaire bestand opmerkelijk autodocumenterend, zelfs als de man-pagina dat niet is
beschikbaar. Alle gebruikers zouden de volgende opdrachten moeten proberen om te zien wat ze doen:

dieharder -h

(drukt de synopsis van de opdracht af zoals hierboven).

dieharder -a -h
dieharder -d 6 -h

(drukt de testbeschrijvingen alleen af ​​voor -a(ll) tests of voor de specifiek aangegeven test).

dieharder-l

(vermeldt alle bekende tests, inclusief hoe betrouwbaar RGB denkt dat ze zijn zoals de zaken er nu voorstaan).

dieharder-g-1

(vermeldt alle bekende rngs).

dieharder-F

(geeft een lijst van alle momenteel bekende weergave-/uitvoerbesturingsvlaggen die worden gebruikt met -D).

Zowel beginners als experts moeten zich ervan bewust zijn dat de beoordeling door dieharder in
haar standaardrapport moet met grote argwaan worden bekeken. Het is heel goed mogelijk voor
een generator om alle tests te "slagen" voor zover het hun individuele p-waarden betreft en toch
om volkomen te mislukken als je ze allemaal samen beschouwt. Evenzo is het waarschijnlijk dat een rng
zal op zijn minst verschijnen als "zwak" op 0, 1 of 2 tests in een typische -a(ll) run, en
kan zelfs 1 test van zo'n run op de 10 of zo "mislukken". Om te begrijpen waarom dit zo is, is het zo
nodig om iets van te begrijpen RNG testen, p-waarden, en the nul hypothese!

P-WAARDEN EN HET NULL HYPOTHESE

dieharder geeft "p-waarden" terug. Om te begrijpen wat een p-waarde is en hoe deze te gebruiken, is het
essentieel om de nul hypothese, H0.

De nulhypothese voor het testen van de generator van willekeurige getallen is: "Deze generator is een perfect
generator van willekeurige getallen, en voor elke keuze van zaad produceert een oneindig lang, uniek
reeks getallen die alle verwachte statistische eigenschappen van willekeurige getallen hebben,
voor alle bestellingen". Merk goed op dat we om te weten wat dat deze hypothese technisch gezien voor iedereen onjuist is
softwaregeneratoren omdat ze periodiek zijn en niet de juiste entropie-inhoud hebben voor
deze bewering ooit waar zal zijn. Echter, velen hardware generatoren vallen a priori ook uit,
omdat ze subtiele vooroordelen of correlaties bevatten vanwege de deterministische fysica die
ligt eraan ten grondslag. De natuur is dat vaak onvoorspelbaar maar het is zelden willekeurige en de twee woorden
bedoel niet (helemaal) hetzelfde!

De nulhypothese kan zijn bijna echter waar. Zowel software als hardware
generatoren kunnen "willekeurig" zijn genoeg dat hun sequenties niet van willekeurig kunnen worden onderscheiden
die, althans niet gemakkelijk of met de beschikbare tools (inclusief dieharder!) Vandaar de
nulhypothese is een praktische, geen theoretisch zuivere bewering.

Testen H0 , gebruikt men de betreffende rng om een ​​reeks vermoedelijk willekeurig te genereren
nummers. Met behulp van deze nummers kan men er een uit een breed scala van genereren proef statistiek
-- empirisch berekende getallen die in aanmerking worden genomen willekeurige monsters dat kan wel of niet
covariant onderworpen aan H0, afhankelijk van of er overlappende reeksen willekeurige getallen zijn
gebruikt om opeenvolgende steekproeven te genereren terwijl de statistiek (en) worden gegenereerd, ontleend aan een bekende
verdeling. Vanuit een kennis van de doelverdeling van de statistiek(en) en de
bijbehorende cumulatieve distributiefunctie (CDF) en de empirisch waarde van de willekeurig
gegenereerde statistiek(en), kan men de waarschijnlijkheid van het verkrijgen van het empirische resultaat aflezen
if the volgorde was echt willekeurig, dat wil zeggen, als de nulhypothese waar is en de
generator in kwestie is een "goede" random number generator! Deze kans is de "p-
waarde" voor de specifieke testrun.

Om bijvoorbeeld een munt (of een reeks bits) te testen, kunnen we eenvoudigweg het aantal tellen
kop en munt in een zeer lange reeks salto's. Als we aannemen dat de munt een "perfect
munt", verwachten we dat het aantal kop en munt zal zijn binomiaal verdeeld en kan gemakkelijk
bereken de kans op een bepaald aantal kop en munt. Als wij
vergelijk ons ​​geregistreerde aantal koppen en muntjes uit de testreeks met deze verdeling
en ontdek dat de kans op het krijgen van de telling die we hebben verkregen is zeer lage met, laten we zeggen, manier
meer kop dan munt zouden we vermoeden dat de munt geen perfecte munt was. dieharder past dit toe
zeer test (wiskundig nauwkeurig gemaakt) en vele andere die op hetzelfde werken
principe toe aan de reeks willekeurige bits die wordt geproduceerd door de rng die wordt getest om een
beeld van hoe "willekeurig" de rng is.

Merk op dat het gebruikelijke dogma is dat als de p-waarde laag is - meestal minder dan 0.05 - één
"verwerpt" de nulhypothese. Kortom, het is onwaarschijnlijk dat men het resultaat zou krijgen
verkregen als de generator goed is. Als het een andere waarde is, "accepteert" men niet
de generator als goed, men "verwerpt niet" de generator als slecht voor dit specifieke
test. Een "goede random number generator" is er dus een die we niet hebben kunnen maken
mislukken nog!

Dit criterium is natuurlijk uiterst naïef en kan niet be gebruikt with dieharder! It
het is net zo logisch om een ​​generator met p-waarden van 0.95 of meer af te wijzen! Beiden
deze p-waardebereiken zijn even onwaarschijnlijk bij een bepaalde testrun, en moet worden geretourneerd
voor (gemiddeld) 5% van alle testritten door a willekeurig nummer generator. Een generator
die er niet in slaagt p-waarden te produceren van minder dan 0.05 5% van de tijd dat het wordt getest met een ander
zaden is een douche generator voor willekeurige getallen, een die mislukt de test van de nulhypothese.
Omdat dieharder standaard meer dan 100 p-waarden retourneert voor test men zou verwachten
volkomen goed om zo'n naïeve test ongeveer vijf keer te 'zakken' volgens dit criterium in a
enkele dieharder-run!

De p-waarden zelf, zo blijkt, zijn teststatistieken! Van nature p-waarden
moet uniform worden verdeeld over het bereik 0-1. In 100+ proefritten met onafhankelijke
zaden, moet men niet verbaasd zijn om 0, 1, 2 of zelfs (zelden) 3 p-waarden lager te krijgen
dan 0.01. Aan de andere kant het verkrijgen van 7 p-waarden in het bereik van 0.24-0.25, of zien dat
70 van de p-waarden groter zijn dan 0.5 zou de generator zeer verdacht moeten maken! Hoe kan
een gebruiker bepaalt wanneer een test "te veel" produceert van een bepaald waardebereik voor p?
Of te weinig?

Dieharder doet het automatisch voor je. Men kan in feite een omzetten reeks van p-waarden in
een p-waarde door hun distributie te vergelijken met de verwachte, met behulp van een Kolmogorov-Smirnov
toets aan de verwachte gelijkmatige verdeling van p.

Deze p-waarden verkregen door te kijken naar de verdeling van p-waarden zouden dat op hun beurt moeten zijn
gelijkmatig verdeeld en zou in principe aan nog meer KS-testen kunnen worden onderworpen
totaal. De verdeling van p-waarden voor a goed generator zou moeten zijn idempotent, zal u zelfs
over verschillende teststatistieken en meerdere runs.

Een mislukking van de distributie van p-waarden op elk aggregatieniveau duidt op problemen. In
als de p-waarden van een bepaalde test worden onderworpen aan een KS-test, en die p-waarden zijn
vervolgens onderworpen aan een KS-test, aangezien we meer p-waarden aan elk niveau toevoegen, zullen we dat ook doen
observeer idempotentie van de resulterende verdeling van p naar uniformiteit, or we zullen observeren
idempotentie tot een enkele p-waarde van nul! Dat wil zeggen, een goede generator zal ongeveer produceren
uniforme verdeling van p-waarden, in de specifieke zin dat de p-waarden van de
distributies van p-waarden zijn zelf min of meer uniform enzovoort ad infinitum, terwijl a
slechte generator zal een niet-uniforme verdeling van p-waarden produceren, en als meer p-waarden
getrokken uit de niet-uniforme verdeling worden toegevoegd aan de KS-test, op een gegeven moment de
mislukking zal absoluut onmiskenbaar zijn als de resulterende p-waarde 0 nadert in de
begrenzing. Probleem inderdaad!

De vraag is, problemen waarmee? Random number tests zijn zelf complex
computationele objecten, en er is een kans dat hun code onjuist is ingekaderd of
dat afrondings- of andere numerieke -- niet methodische -- fouten bijdragen aan a
vervorming van de verdeling van enkele van de verkregen p-waarden. Dit is geen loosheid
observatie; wanneer men werkt aan het schrijven van testprogramma's voor het genereren van willekeurige getallen, is men dat wel
altijd de tests zelf testen met "goede" (hopen we) random number generators zodat
flagrante mislukkingen van de nulhypothese duiden niet op een slechte generator, maar op een fout in de
testcode. De bovenstaande nulhypothese is correct geformuleerd vanuit a theoretisch punt van
bekijken, maar vanaf een vast en praktisch gezichtspunt zou moeten luiden: "Deze generator is een
perfecte generator voor willekeurige getallen, en voor elke keuze van zaad produceert een oneindig lange,
unieke reeks getallen die alle verwachte statistische eigenschappen van willekeurig hebben
nummers, voor alle bestellingen en deze test is een perfecte test en geeft precies de juiste p-
waarden van de testberekening." Waargenomen "mislukking" van deze gezamenlijke nulhypothese H0'
kan het gevolg zijn van het falen van een of beide van deze onsamenhangende componenten, en komt van de
tweede zo vaak of vaker dan de eerste tijdens het testontwikkelingsproces. Wanneer
men verhoogt de "resolutie" van de test (hierna besproken) tot waar een generator begint
als je niet slaagt voor een test, realiseer je je, of zou je moeten beseffen, dat ontwikkeling nooit ophoudt en dat nieuw is
testregimes zullen altijd nieuwe storingen aan het licht brengen, niet alleen van de generatoren maar ook van de code.

Dat gezegd hebbende, een van de belangrijkste voordelen van dieharder is de controle die het heeft
geeft u een kritische testparameter. Uit de bovenstaande opmerkingen kunnen we zien dat we
zou moeten voelen zeer ongemakkelijk over het "falen" van een willekeurige generator op de
op basis van een criterium van 5% of zelfs 1%, zeker als we een test toepassen suite als
dieharder die meer dan 100 (en stijgende) verschillende test-p-waarden retourneert vanaf de laatste
momentopname. Wij willen dat uitval eenduidig ​​en reproduceerbaar is!

Om dit te bereiken, kan men eenvoudigweg de resolutie verhogen. Als we een bepaalde test zouden doen
tegen een generator van willekeurige getallen en het retourneerde een p-waarde van (laten we zeggen) 0.007328, zouden we zijn
volkomen gerechtvaardigd om je af te vragen of het echt een goede generator is. echter, de
de kans om dit resultaat te krijgen is niet zo klein -- als men dieharder gebruikt
urenlang zullen dit soort getallen zeker vrij vaak en gemeen voorkomen
Niets. Als men de dezelfde test opnieuw (met een andere seed of een deel van de random
reeks) en krijgt een p-waarde van 0.009122, en een derde keer en krijgt 0.002669 -- wel,
dat zijn drie schoten van 1% (of minder) achter elkaar en uit die zou slechts één op de miljoen moeten gebeuren
keer. Een manier om mislukkingen duidelijk op te lossen, is dus toename the aantal of p-waarden
gegenereerd in een testrun. Als de werkelijke verdeling van p die door de test wordt geretourneerd, is
niet uniform, een KS-test wel uiteindelijk retourneert een p-waarde die niet dubbelzinnig is
0.035517 maar is in plaats daarvan 0.000000, waarbij de laatste keer op keer wordt geproduceerd terwijl we herhalen.

Om deze reden is dieharder uiterst conservatief over het aankondigen van rng "zwakte" of
"falen" ten opzichte van een bepaalde test. Het is een intern criterium voor deze dingen
momenteel p < 0.5% of p > 99.5% zwakte (op het niveau van 1% totaal) en een aanzienlijk meer
streng criterium voor falen: p < 0.05% of p > 99.95%. Merk goed op dat de reeksen zijn
symmetrisch -- een te hoge waarde van p is net zo erg (en onwaarschijnlijk) als een te lage waarde, en dat is het ook
kritisch om het te markeren, omdat het heel goed mogelijk is dat een rng is ook goed, gemiddeld,
en niet produceren genoeg lage p-waarden op het volledige spectrum van dieharder-testen. Dit is
waar de laatste kstest van het allergrootste belang is, en waar de optie "histogram" kan zijn
erg handig om u te helpen bij het visualiseren van de fout in de distributie van p -- run, bijvoorbeeld:

dieharder [wat dan ook] -D standaard -D histogram

en je zult een ruw ascii-histogram zien van de pvalues ​​die voor een gegeven faalden (of slaagden).
niveau van testen.

Verspreide meldingen van zwakte of marginale mislukking in een voorlopige -a(ll) run zouden moeten
dus geen directe reden tot ongerustheid. Het zijn eerder tests om te herhalen, om naar te kijken
uit voor, om de rng harder te duwen door de optie -m te gebruiken voor -a of gewoon -p te verhogen voor a
specifieke toets. Dieharder staat het toe om het aantal gegenereerde p-waarden te verhogen elke
test, alleen afhankelijk van de beschikbaarheid van voldoende willekeurige getallen (voor op bestanden gebaseerde tests) en
tijd, om mislukkingen ondubbelzinnig te maken. Een proef dan echt zwak bij -p 100 zal bijna
mislukken altijd enorm bij een grotere waarde van psamples, of het nu -p 1000 of -p 100000 is.
Omdat dieharder echter een onderzoeksinstrument is en voortdurend in ontwikkeling is en
testen, dat is het sterk gesuggereerd dat men altijd rekening houdt met de alternatieve nulhypothese
- dat de storing een storing is van de testcode in dieharder zelf in een bepaalde limiet van
grote aantallen - en neem op zijn minst enkele stappen (zoals het uitvoeren van dezelfde test op hetzelfde
resolutie op een "gouden standaard" generator) om ervoor te zorgen dat de storing inderdaad waarschijnlijk is
in de rng en niet in de dieharder-code.

Bij gebrek aan een bron van willekeurige getallen om als referentie te gebruiken, waarmee de tests worden gevalideerd
zelf is niet gemakkelijk en laat altijd een zekere dubbelzinnigheid achter (zelfs aes of threefish).
Tijdens de ontwikkeling is het beste wat men gewoonlijk kan doen, zwaar te vertrouwen op deze "veronderstelde goede"
generatoren van willekeurige getallen. Er zijn een aantal generatoren die we theoretisch hebben
redenen om te verwachten buitengewoon goed te zijn en geen correlaties te hebben met sommige bekende
onderliggende dimensionaliteit, en dat komt ook vrij consistent zeer goed uit. Door
door meerdere van dergelijke generatoren te gebruiken en niet slechts één, kan men hopen dat die generatoren dat wel hebben
(op z'n minst) anders correlaties en zouden niet allen een test in uniform moeten ontbreken
op dezelfde manier en met hetzelfde aantal p-waarden. Wanneer al deze generatoren consistent
niet slagen voor een test op een bepaald niveau, heb ik de neiging te vermoeden dat het probleem in de testcode zit, niet
de generatoren, hoewel het erg moeilijk is om te zijn zeker, en veel fouten erin
dieharder's code zijn ontdekt en uiteindelijk op deze manier opgelost door mijzelf of
anderen.

Een voordeel van dieharder is dat het direct een aantal van deze "goede generatoren" heeft
beschikbaar voor vergelijkingsruns, met dank aan de Gnu Scientific Library en gebruiker
bijdrage (met name David Bauer, die zo vriendelijk was om aes en threefish in te kapselen). ik gebruik
AES_OFB, Threefish_OFB, mt19937_1999, gfsr4, ranldx2 en taus2 (evenals "true random"
nummers van random.org) voor dit doel, en ik probeer ervoor te zorgen dat dieharder zal "passeren"
in het bijzonder de -g 205 -S 1 -s 1 generator bij elke redelijke p-waarde resolutie naar
-p 1000 of verder.

Tests (zoals de diehard operm5 en sommentest) die consistent zijn mislukken bij deze hoog
resoluties worden gemarkeerd als "verdacht" -- mogelijke mislukkingen van de alternatief nul
hypothese -- en dat zijn ze sterk verouderd! Hun resultaten mogen niet worden gebruikt om te testen
random number generators in afwachting van overeenstemming in de statistieken en random number community
dat die testen wel degelijk valide en correct zijn zodat geconstateerde storingen inderdaad veilig kunnen
toe te schrijven aan het falen van de bestemde nul hypothese.

Zoals ik blijf benadrukken (om een ​​goede reden!) Dieharder wordt door de gemeenschap ondersteund. ik dus
vraag openlijk aan de gebruikers van dieharder die expert zijn in statistieken om mij te helpen de
code of algoritmen die worden geïmplementeerd. Ik zou deze testsuite uiteindelijk graag zien
gevalideerd door de algemene statistiekengemeenschap bij hard gebruik in een open omgeving, waar
elke mogelijke storing van het testmechanisme zelf wordt nauwkeurig onderzocht en eventueel uitgevoerd
correctie. Op deze manier zullen we uiteindelijk inderdaad een zeer krachtige suite van tools bereiken,
degenen die ons heel specifieke informatie kunnen geven, niet alleen over falen, maar ook over de
mode van falen ook, hoe de geteste volgorde afwijkt van willekeur.

Tot nu toe heeft dieharder enorm geprofiteerd van de gemeenschap. Individuen hebben
openlijk bijgedragen tests, nieuwe te testen generatoren en oplossingen voor bestaande tests die
werden onthuld door hun eigen werk met het testinstrument. Er wordt aan gewerkt om te maken
dieharder draagbaarder zodat het op meer platforms kan worden gebouwd en sneller zodat meer
grondige testen kunnen worden gedaan. Doe gerust mee.

FILE INVOER

De eenvoudigste manier om dieharder te gebruiken met een externe generator die onbewerkt binair bestand produceert
(vermoedelijk willekeurige) bits is om de ruwe binaire uitvoer van deze generator door te sluizen (vermoedelijk naar
een binaire stroom van 32-bits gehele getallen zonder teken zijn) rechtstreeks in dieharder, bijvoorbeeld:

kat /dev/urandom | ./dieharder -a -g 200

Ga je gang en probeer dit voorbeeld. Het zal de hele dieharder-reeks tests uitvoeren op de
stream geproduceerd door de ingebouwde linux generator /dev/urandom (het gebruik van /dev/random is niet
aanbevolen omdat het te traag is om binnen een redelijke tijd te testen).

Als alternatief kan dieharder worden gebruikt om bestanden met nummers die door een kandidaat zijn geproduceerd, te testen
generatoren van willekeurige getallen:

dieharder -a -g 201 -f willekeurige.org_bin

voor onbewerkte binaire invoer of

dieharder -a -g 202 -f random.org.txt

voor geformatteerde ascii-invoer.

Een geformatteerd ascii-invoerbestand kan ofwel uints accepteren (gehele getallen in het bereik van 0 tot 2^31-1,
één per regel) of decimale uniforme afwijkingen met ten minste tien significante cijfers (dat kan
worden vermenigvuldigd met UINT_MAX = 2^32 om een ​​uint te produceren zonder de precisie te verliezen), ook een
per lijn. Floats met minder cijfers zullen vrijwel zeker de bitlevel-tests niet doorstaan
ze kunnen slagen voor enkele van de tests die werken op uniforme afwijkingen.

Ten slotte kan men vrij gemakkelijk elke generator in hetzelfde (GSL) harnas met willekeurige getallen wikkelen
intern gebruikt door dieharder en test het gewoon op dezelfde manier als elke andere interne
generator herkend door dieharder. Waar mogelijk wordt dit ten zeerste aanbevolen,
omdat dieharder een lot van willekeurige getallen om een ​​generator grondig te testen. A
ingebouwde generator kan dieharder eenvoudig laten bepalen hoeveel hij nodig heeft en deze genereren
on demand, waarbij een te klein bestand "terugspoelt" en de testresultaten waar weergeeft
een terugspoelen gebeurt verdacht.

Merk goed op dat bestandsinvoerranden op verzoek aan de tests worden geleverd, maar als de test
meer nodig heeft dan er beschikbaar is, wordt het bestand gewoon teruggespoeld en opnieuw doorlopen, en
opnieuw, en opnieuw als dat nodig is. Uiteraard verkleint dit de monsterruimte en -kan aanzienlijk
leiden tot volledig onjuiste resultaten voor de p-waardehistogrammen, tenzij er voldoende zijn
rands om ELKE test uit te voeren zonder herhaling (het is onschadelijk om de reeks opnieuw te gebruiken voor
verschillende proeven). Laat de gebruiker oppassen!

BEST PRAKTIJK

Een veelgestelde vraag van nieuwe gebruikers die een generator willen testen waaraan ze werken
voor de lol of winst (of beide) is "Hoe moet ik de output in dieharder krijgen?" Dit is een
niet-triviale vraag, zoals dieharder consumeert enorm nummers van willekeurige getallen in een volledige
testcyclus, en dan zijn er functies zoals -m 10 of -m 100 waarmee je moeiteloos kunt
vraag 10 of 100 keer zoveel om een ​​nieuwe generator nog meer te belasten.

Zelfs with Grote filet ondersteuning in dieharder is het moeilijk om voldoende willekeurig te bieden
nummers in een bestand om dieharder echt blij te maken. Het is daarom sterk gesuggereerd uit die
helpen hetzij:

a) Bewerk de uitgangstrap van uw generator voor willekeurige getallen en laat deze deze schrijven
productie naar stdout als een willekeurige beetje stream - creëer in feite 32 bit unsigned random
integers en schrijf ze rechtstreeks naar stdout als bijvoorbeeld char data of raw binary. Let daar op
Dit is niet hetzelfde als het schrijven van onbewerkte getallen met drijvende komma (dat zal helemaal niet willekeurig zijn
als een bitstream) en dat "endianness" van de uints er niet toe zou moeten doen voor de null
hypothese van een "goede" generator, aangezien willekeurige bytes in willekeurige volgorde willekeurig zijn. Draai de
generator en voer deze stroom naar dieharder in een pijp zoals hierboven beschreven.

b) Gebruik de monsters van GSL-verpakte dieharder rngs om uw generator (of
oproepen naar de hardware-interface van uw generator). Volg de voorbeelden in de ./dieharder
bronmap om deze toe te voegen als een "gebruiker"-generator in de opdrachtregelinterface, opnieuw opbouwen,
en roep de generator aan als een "native" dieharder-generator (deze zou in de lijst moeten verschijnen
geproduceerd door -g -1 indien correct gedaan). Het voordeel van het op deze manier doen is dat jij
kan het dan (als uw nieuwe generator zeer succesvol is) terugbrengen naar de dieharder
project als je wilt! Om nog maar te zwijgen van het feit dat het testen heel gemakkelijk wordt.

De meeste gebruikers zullen waarschijnlijk in eerste instantie kiezen voor optie a), maar houd er rekening mee dat b) dat wel is
waarschijnlijk makkelijker dan je denkt. De dieharder handhavers mei een handje kunnen helpen
mee als je in de problemen komt, maar geen beloftes.

WAARSCHUWING!

Een waarschuwing voor degenen die bestanden met willekeurige getallen testen. dieharder is een hulpmiddel dat
testen willekeurige aantal generatoren, niet bestanden of willekeurige nummers! Het is buitengewoon
ongepast om te proberen een bestand met willekeurige getallen als willekeurig te "certificeren", alleen omdat het zo is
slaagt er niet in om een ​​van de dieharder-tests te "mislukken" in bijvoorbeeld een dieharder-a-run. Bot gezegd,
als men al dergelijke bestanden afwijst die niet slagen voor een test op het 0.05-niveau (of een andere), de ene
ding waarvan men zeker kan zijn, is dat de bestanden in kwestie zijn niet willekeurige, als een echt
willekeurige volgorde zou elke test op het 0.05-niveau 5% van de tijd mislukken!

Anders gezegd, elk bestand met getallen geproduceerd door a generator dat "niet faalt"
de dieharder suite moet als "willekeurig" worden beschouwd, zelfs als deze sequenties bevat die
zou wel eens kunnen "mislukken" voor een bepaalde test op een bepaalde grens. Men moet aannemen dat passeren
de bredere tests van de generator zelf, werd vastgesteld dat de p-waarden voor de
proef betrokken was wereldwijd correct verdeeld, zodat bijv. uitvalt op het 0.01-niveau
komt gemiddeld niet meer of minder dan 1% van de tijd voor bij veel tests. Als
één bepaald bestand genereert een storing op dit niveau, dus men kan er gerust vanuit gaan
dat het een willekeurige bestand getrokken uit vele duizenden vergelijkbare bestanden die de generator zou kunnen
creëren die de juiste verdeling van p-waarden hebben op alle testniveaus en
aggregatie.

Kortom, gebruik dieharder om uw generator te valideren (via input van bestanden of een ingesloten
stroom). Gebruik dan in ieder geval uw generator om willekeurige bestanden of streams te produceren
nummers. Gebruik dieharder niet als hulpmiddel voor accepteren/weigeren om te valideren the bestanden zich!

Voorbeelden

Om alle tests te demonstreren, voer je uit op de standaard GSL rng, voer je in:

dieharder-a

Om een ​​test van een externe generator van een onbewerkte binaire bitstroom te demonstreren, gebruikt u de
stdin (onbewerkte) interface:

kat /dev/urandom | dieharder -g 200 -a

Om het te gebruiken met een ascii-geformatteerd bestand:

dieharder -g 202 -f testrands.txt -a

(testrands.txt moet bestaan ​​uit een header zoals:

#============================================== =================
# generator mt19937_1999 zaad = 1274511046
#============================================== =================
soort: d
aantal: 100000
aantal: 32
3129711816
85411969
2545911541

enzovoort).

Om het te gebruiken met een binair bestand

dieharder -g 201 -f testrands.bin -a

or

kat testrands.bin | dieharder -g 200 -a

Een voorbeeld dat het gebruik van "voorvoegsels" demonstreert op de uitvoerregels die het maken
relatief eenvoudig om de verschillende delen van het uitvoerrapport uit te filteren en op te knippen
in getallen die in andere programma's of in spreadsheets kunnen worden gebruikt, probeert u:

dieharder -a -c ',' -D standaard -D voorvoegsel

DISPLAY OPTIES

Vanaf versie 3.xx heeft dieharder een enkele uitvoerinterface die tabelgegevens produceert
per test, met algemene informatie in headers. De weergavebesturingsopties en vlaggen kunnen
worden gebruikt om de uitvoer aan te passen aan uw individuele specifieke behoeften.

De opties worden gecontroleerd door binaire vlaggen. De vlaggen en hun tekstversies zijn
weergegeven als u invoert:

dieharder-F

vanzelf op een lijn.

De vlaggen kunnen in één keer worden ingevoerd door alle gewenste optievlaggen bij elkaar op te tellen. Voor
een zeer schaarse uitvoer kan bijvoorbeeld worden geselecteerd door de vlaggen voor de test_name (8) toe te voegen
en de bijbehorende pwaarden (128) om 136 te krijgen:

dieharder-a-D 136

Aangezien de vlaggen worden gecumuleerd vanaf nul (tenzij er geen vlag is ingevoerd en de standaardwaarde is
gebruikt) zou je dezelfde weergave kunnen bereiken via:

dieharder -a -D 8 -D pwaarden

Merk op dat u vlaggen kunt invoeren op waarde of op naam, in elke combinatie. Omdat mensen gebruiken
dieharder om waarden te verkrijgen en ze vervolgens te exporteren naar spreadsheets (door komma's gescheiden
waarden) of in filterscripts, kunt u het veldscheidingsteken wijzigen. Voor
voorbeeld:

dieharder -a -c ',' -D standaard -D -1 -D -2

produceert uitvoer die ideaal is om in een spreadsheet te importeren (merk op dat men kan aftrekken
veldwaarden uit de basisset van velden die door de standaardoptie worden geleverd, zolang deze bestaat
eerst gegeven).

Een interessante optie is de prefixvlag -D, die een veldidentificatievoorvoegsel aanzet
maken het gemakkelijk om bepaalde soorten gegevens eruit te filteren. Het is echter even gemakkelijk om te draaien
op een bepaald soort output met uitsluiting van anderen rechtstreeks door middel van de
vlaggen.

Twee andere vlaggen die van belang zijn voor beginners bij het testen van willekeurige getallengeneratoren zijn de -D
histogram (zet een histogram aan van de onderliggende pwaarden, per test) en -D beschrijving
(schakelt een volledige testbeschrijving in, per test). Deze vlaggen veranderen de uitvoertabel in
meer een reeks "rapporten" van elke test.

RELEASE REGLEMENT

dieharder is volledig originele code en kan door elke gebruiker naar believen worden gewijzigd en gebruikt,
op voorwaarde dat:

a) De originele copyrightvermeldingen worden gehandhaafd en dat de bron, inclusief alle
wijzigingen, wordt openbaar gemaakt op het moment van een afgeleide publicatie. Dit
is open source software volgens de voorschriften en de geest van de Gnu Public License.
Zie het bijbehorende bestand KOPIËREN, dat ook bij elke herverdeling moet worden meegestuurd.

b) De primaire auteur van de code (Robert G. Brown) wordt naar behoren erkend en
waarnaar wordt verwezen in een afgeleide publicatie. Er wordt sterk gesuggereerd dat George Marsaglia en
de Diehard-suite en de verschillende auteurs van de Statistical Test Suite zijn op dezelfde manier
erkend, hoewel deze suite geen echte code deelt met deze willekeurige nummertest
vervolg.

c) Volledige verantwoordelijkheid voor de nauwkeurigheid, geschiktheid en effectiviteit van het programma
berust bij de gebruikers en/of modifiers. Zoals duidelijk vermeld in de bijgevoegde
auteursrecht.h:

DE AUTEURSRECHTHOUDERS WIJZEN ALLE GARANTIES MET BETREKKING TOT DEZE SOFTWARE AF, INCLUSIEF ALLE
IMPLICIETE GARANTIES VAN VERKOOPBAARHEID EN GESCHIKTHEID, IN GEEN GEVAL ZULLEN DE AUTEURSRECHTHOUDERS
AANSPRAKELIJK ZIJN VOOR ENIGE BIJZONDERE, INDIRECTE OF GEVOLGSCHADE OF WELKE SCHADE DAN OOK
ALS GEVOLG VAN VERLIES VAN GEBRUIK, GEGEVENS OF WINST, HETZIJ IN EEN HANDELING VAN OVEREENKOMST, NALATIGHEID
OF ANDERE ONRECHTMATIGE HANDELINGEN, VOORTVLOEIEND UIT OF IN VERBAND MET HET GEBRUIK OF DE PRESTATIES VAN
DEZE SOFTWARE.

DANKBETUIGINGEN

De auteur van deze suite erkent dankbaar George Marsaglia (de auteur van de
diehard test suite) en de verschillende auteurs van NIST Special Publication 800-22 (die
beschrijft de Statistical Test Suite voor het testen van pseudotoevalsgeneratoren voor
cryptografische toepassingen), voor uitstekende beschrijvingen van de tests daarin. Deze
Dankzij beschrijvingen kon deze suite worden ontwikkeld met een GPL.

De auteur wil ook herhalen dat de academische correctheid en nauwkeurigheid van de
de uitvoering van deze tests is zijn eigen verantwoordelijkheid en niet die van de auteurs van
de Diehard- of STS-suites. Dit is met name het geval wanneer hij het nodig heeft geacht deze te wijzigen
tests van hun strikte originele beschrijvingen.

COPYRIGHT

GPL 2b; zie het bestand COPYING dat bij de broncode van dit programma hoort. Dit is de
"standaard Gnu General Public License versie 2 of een latere versie", met de enige minor
(humoristisch) Wijziging "Drank" hieronder vermeld. Merk op dat deze wijziging waarschijnlijk is
juridisch niet verdedigbaar en kan eigenlijk vrijwel volgens de ereregel worden gevolgd.

Wat betreft mijn persoonlijke voorkeuren in dranken, rode wijn is geweldig, bier is heerlijk, en
Coca Cola of koffie of thee of zelfs melk acceptabel voor degenen die religieus of persoonlijk zijn
redenen willen voorkomen dat ik mijn lever belast.

De Drank Wijziging naar the LPG:

Elke tevreden gebruiker van deze software zal, na ontmoeting met de primaire auteur(s) hiervan
software voor het eerst onder de juiste omstandigheden aanbieden om hem of haar te kopen
of ze een drankje. Deze drank kan al dan niet alcoholisch zijn, afhankelijk van het persoonlijke
ethische en morele opvattingen van de aanbieder. De drankkosten hoeven niet hoger te zijn dan één Amerikaanse dollar
(hoewel het zeker kan in de gril van de aanbieder:-) en kan worden geaccepteerd of geweigerd
zonder verdere verplichtingen van de aanbieder. Het is niet nodig om de
bieden na de eerste ontmoeting, maar het kan geen kwaad...

Gebruik dieharder online met behulp van onworks.net-services