Thread View: pl.comp.lang.c
78 messages
78 total messages
Page 2 of 2
Started by Norbert Cielecki
Sat, 02 Jul 2016 17:05
Page 2 of 2 • 78 total messages
Re: test randomizacyjny w C
Author: Norbert Cielecki
Date: Mon, 04 Jul 2016 12:36
Date: Mon, 04 Jul 2016 12:36
41 lines
2395 bytes
2395 bytes
Matt D. <no-spam@invalid.local> wrote: > > W praktyce: Istniejace implementacje `rand` _zdecydowanie_ zawala kazde > porzadne testy losowosci. > > A wiec jesli Twoim celem jest odpowiedzenie na pytanie, "czy `rand` > przejdzie test(y) losowosci", to natychmiast -- i bez dalszej straty > czasu -- odpowiedz jest prosta i bezwzgledna: ABSOLUTNIE NIE! (bez > szans, bez wyjatkow, bez przeprosin). > > (W teorii, zachowanie `rand` jest implementation-defined, wiec mozna > sobie wyobrazic implementacje ktore zrobia cos innego -- osobiscie nie > znam takowej.) > > Jesli chodzi o czysta ciekawosc (i przekonanie sie, ze, faktycznie, > zawali :]): Diehard i TestU01 to podstawowe testy (a raczej cale > kolekcje tychze)--wiec mozesz zaczac od nich: > https://en.wikipedia.org/wiki/Diehard_tests > https://en.wikipedia.org/wiki/TestU01 > > Tutaj jest implementacja TestU01 w ANSI C: > http://www.iro.umontreal.ca/~simardr/testu01/tu01.html > > Patrz tez: > http://csrc.nist.gov/groups/ST/toolkit/rng/batteries_stats_test.html > http://stackoverflow.com/questions/778718/how-to-test-random-numbers > > Jak chcesz porzadny generator, to przyjrzyj sie: > http://www.pcg-random.org/ > > Tutaj przykladowe wyniki testow (ktorym mozesz sie przyjrzec takze--jako > przyklad, jak testowac): > http://www.pcg-random.org/statistical-tests.html > > Pozdrawiam, > > Matt Dziękuję za wyczerpujące temat wskazówki. -- pzdr NTC
Re: test randomizacyjny w C
Author: bartekltg
Date: Mon, 04 Jul 2016 21:09
Date: Mon, 04 Jul 2016 21:09
43 lines
2731 bytes
2731 bytes
On 04.07.2016 20:06, M.M. wrote: > On Monday, July 4, 2016 at 5:57:17 PM UTC+2, M.M. wrote: >> On Monday, July 4, 2016 at 3:23:47 AM UTC+2, Matt D. wrote: >> >>> W praktyce: Istniejace implementacje `rand` _zdecydowanie_ zawala kazde >>> porzadne testy losowosci. >> >> Poprawny generator liniowy, zaimplementowany na dużym zakresie >> powinien przejść doskonale wszystkie testy na równomierność rozkładu, ponieważ >> generuje wszystkie liczby z zakresu od 0 do N-1. Moim zdaniem problem tego >> generatora polega na tym, że przechodzi te testy zbyt dokładnie. >> >> Problemy ten generator dopiero ma przy testach na zależność, bo >> liczba losowa numer [i] zależy bezpośrednio od liczby [i-1]. >> W ciut lepszych odmianach zależy od dwóch lub trzech poprzednich. >> >> Pozdrawiam > > Spoglądam na tę stronę z testami generatorów: > http://www.cacert.at/cgi-bin/rngresults > > stdlib rand() - nie przechodzi ich testów. > java.util.Random.Random - też nie przechodzi > MT19337(java) nie przechodzi? czy to to jest merseen twister??? > MersenneTwister19937 Gaussian - to na pewno MT, nie przechodzi??? > Mersenne Twister (with some speed optimization) - prawie przeszedł, ale tylko 6Mbajtów na sekundę. > > Czy ja czegoś nie rozumiem? MT nie przechodzi testów? Tak, MT nie przechodzi wszystkich testów. Od dawna. > Aż musiałem wrzucić generator mojego autorstwa: > my generator no have any important name yet, version 0.00 > Wygląda na to że przechodzi ichniejsze testy. Wysłałeś im gigabajt liczb? ;> Włóż go w dieharder, ale wcześniej przecztyaj, jak należy interpretować wyniki. pzdr bartekltg
Re: test randomizacyjny w C
Author: M.M.
Date: Mon, 04 Jul 2016 21:44
Date: Mon, 04 Jul 2016 21:44
46 lines
3297 bytes
3297 bytes
On Monday, July 4, 2016 at 11:09:45 PM UTC+2, bartekltg wrote: > On 04.07.2016 20:06, M.M. wrote: > > On Monday, July 4, 2016 at 5:57:17 PM UTC+2, M.M. wrote: > >> On Monday, July 4, 2016 at 3:23:47 AM UTC+2, Matt D. wrote: > >> > >>> W praktyce: Istniejace implementacje `rand` _zdecydowanie_ zawala kazde > >>> porzadne testy losowosci. > >> > >> Poprawny generator liniowy, zaimplementowany na dużym zakresie > >> powinien przejść doskonale wszystkie testy na równomierność rozkładu, ponieważ > >> generuje wszystkie liczby z zakresu od 0 do N-1. Moim zdaniem problem tego > >> generatora polega na tym, że przechodzi te testy zbyt dokładnie. > >> > >> Problemy ten generator dopiero ma przy testach na zależność, bo > >> liczba losowa numer [i] zależy bezpośrednio od liczby [i-1]. > >> W ciut lepszych odmianach zależy od dwóch lub trzech poprzednich. > >> > >> Pozdrawiam > > > > Spoglądam na tę stronę z testami generatorów: > > http://www.cacert.at/cgi-bin/rngresults > > > > stdlib rand() - nie przechodzi ich testów. > > java.util.Random.Random - też nie przechodzi > > MT19337(java) nie przechodzi? czy to to jest merseen twister??? > > MersenneTwister19937 Gaussian - to na pewno MT, nie przechodzi??? > > Mersenne Twister (with some speed optimization) - prawie przeszedł, ale tylko 6Mbajtów na sekundę. > > > > Czy ja czegoś nie rozumiem? MT nie przechodzi testów? > > Tak, MT nie przechodzi wszystkich testów. Od dawna. > > > > Aż musiałem wrzucić generator mojego autorstwa: > > my generator no have any important name yet, version 0.00 > > Wygląda na to że przechodzi ichniejsze testy. > > Wysłałeś im gigabajt liczb? ;> Trochę mniej. Szkoda że się nie zipują ;-) > Włóż go w dieharder, ale wcześniej przecztyaj, jak należy interpretować > wyniki. Hmmm kusząca propozycja, może spróbuję :) Pozdrawiam
Re: test randomizacyjny w C
Author: bartekltg
Date: Mon, 04 Jul 2016 22:13
Date: Mon, 04 Jul 2016 22:13
19 lines
1604 bytes
1604 bytes
On 04.07.2016 23:44, M.M. wrote: >>> >>> Czy ja czegoś nie rozumiem? MT nie przechodzi testów? Ściągnij sobier ze strony dieharder paczkę ze źródłami. Będie tam katalog manual, skompiluj co jest w środku, powinien wyjsc pdf na 132 strony. (nie udało mi się znalesc tego wywieszonego na www). Zerknij do rozdiału 7.0.1 A Good Generator: mt19937 1999 podrozdziału 7.0.2 Comments. Jest tam opisane, co nie do końca działą w MT. pzdr bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Tue, 05 Jul 2016 13:46
Date: Tue, 05 Jul 2016 13:46
120 lines
5302 bytes
5302 bytes
On 04.07.2016 21:12, Matt D. wrote: > On 7/4/2016 20:06, M.M. wrote: >> On Monday, July 4, 2016 at 5:57:17 PM UTC+2, M.M. wrote: >>> On Monday, July 4, 2016 at 3:23:47 AM UTC+2, Matt D. wrote: >>> >>>> W praktyce: Istniejace implementacje `rand` _zdecydowanie_ zawala kazde >>>> porzadne testy losowosci. >>> >>> Poprawny generator liniowy, zaimplementowany na dużym zakresie >>> powinien przejść doskonale wszystkie testy na równomierność rozkładu, >>> ponieważ >>> generuje wszystkie liczby z zakresu od 0 do N-1. Moim zdaniem problem >>> tego >>> generatora polega na tym, że przechodzi te testy zbyt dokładnie. > > Byc moze, ale... > >>> Problemy ten generator dopiero ma przy testach na zależność, bo >>> liczba losowa numer [i] zależy bezpośrednio od liczby [i-1]. >>> W ciut lepszych odmianach zależy od dwóch lub trzech poprzednich. > > ...wlasnie. I w testach losowosci w sensie ogolnym musimy miec > zaliczenie baterii (t.j., calej kolekcji) -- zawalenie jednego implikuje > zawalenie baterii. > >> Spoglądam na tę stronę z testami generatorów: >> http://www.cacert.at/cgi-bin/rngresults >> >> stdlib rand() - nie przechodzi ich testów. >> java.util.Random.Random - też nie przechodzi >> MT19337(java) nie przechodzi? czy to to jest merseen twister??? >> MersenneTwister19937 Gaussian - to na pewno MT, nie przechodzi??? >> Mersenne Twister (with some speed optimization) - prawie przeszedł, >> ale tylko 6Mbajtów na sekundę. >> >> Czy ja czegoś nie rozumiem? MT nie przechodzi testów? > > Oczywiscie -- tutaj nie ma zadnego zaskoczenia, MT zdecydowanie nie > nadaje sie do krypto --- bardziej nadaje sie do obliczen numerycznych Tu nawet nie zbliżaamy się jeszczse do kryptograficznych PRNG, te testy sprawdzają, jak dany generator sprawdza się w numeryce. > (n.p., naukowe symulacje), gdzie statystyczne wlasciwosci rozkladu sa > wazniejsze od nieprzewidywalnosci (ale tez nie jest najlepszy, to bardzo > ciezki -- duzy stan -- i powolny generator). Skąd ten mit o powolności MT? On jest równie szybki jak badziewny rand. Nie jest to jakoś super szybko, ale też trudno nazwać to wolnym generatorem. Duży stan przeszkadza przy próbie wsadzenia tego na GPU czy jeśli martwimy się o cache (jak pomiędzy losowaniami mamy dużo do roboty, to i mały stan wyleci z L1), ale najczzęścij nie jekst to problemem. MT aktualizuje jedną komurkę stanu przy jednym losowaniu, nie wszystkie. Jedynie co 623 (624?) losowania aktualizuje dodatkowo wszystkie 624 komórki. > // Dla szybkosci (numeryka, nie krypto) to raczej > http://www.agner.org/random/ Ciekawe. (Przydało by się uwspółcześnić, ale to tylko moje marudzenie, bo mi range-for nie ). Odpaliłęm i porównałem z gotowym mt z gcc. Czasy (Ranvec1(3) , mt_199937): 0.262284 0.158556 0.282353 0.158565 0.283082 0.158531 0.283313 0.158554 0.283461 0.158525 Czasy (Ranvec1(2) , mt_199937): 0.232953 0.158655 0.252857 0.158578 0.25301 0.158577 0.25347 0.158534 0.25326 0.158584 Czasy (Ranvec1(1) , mt_199937): 0.205057 0.159159 0.196595 0.159009 0.195505 0.158919 0.196932 0.158682 0.196955 0.158765 Gotowy MT_19993 (pewnie też napisany wektorowo) jest ciut szybszy dla float. Dla double jest lepiej: Czasy (Ranvec1(3) , mt_199937): 0.314738 0.433556 0.310824 0.43496 0.310764 0.434656 0.310771 0.433265 0.310793 0.434174 Ranvec1 może mieć lepsze własności, dodatkowe 25% predkośći to też nie byle co, ale zareklamowałeś to neico na wyrost. Oczywisćie, mogłem coś zwalić (http://pastebin.com/pdbaF76E) > Drastyczny przyklad dlaczego numeryki nie zawsze obchodza problemy > kryptografow -- QRNG (quasi-random number generator -- w odroznieniu od > PRNG/pseudo): > https://en.wikipedia.org/wiki/Low-discrepancy_sequence > http://www.johndcook.com/blog/2009/03/16/quasi-random-sequences-in-art-and-integration/ Nie miasząłbym w ogole QRNG i PRNG. To zupełnie inne zagadnienia, QRNG ma dość ograniczone (choć bardzo potrzebne) zastosowanie. MT i QMT to nie co tamo, tylko ze względów reklamowych nazywa się podobnie ;-) Nijak nie obniża wartości zwykłych PRNG. pzdr bartekltg
Re: test randomizacyjny w C
Author: slawek
Date: Fri, 08 Jul 2016 08:21
Date: Fri, 08 Jul 2016 08:21
30 lines
2978 bytes
2978 bytes
Użytkownik "Norbert Cielecki" napisał w wiadomości grup
dyskusyjnych:5777f44e$0$12548$65785112@news.neostrada.pl...
>Czy ktoś mógłby mi wytłumaczyć, wjaki sposób funkcja rand() może | ma
>skorzystać z 10 ziaren losowych srand(time(0)), przy generowaniu 1000
>liczb pseudolosowych z zakresu 1-10. Chodzi mi dokładnie o zbadanie
>losowości generatora liczb pseudolosowych. Wdzięczny będę za wskazówki.
Ściśle i poprawnie rzecz ujmując: nie da się. Tzn. nie da się udowodnić
losowości jako takiej, więc nie da się udowodnić losowości w tym konkretnym
przypadku.
Nieco mniej ściśle: liczby nazywają się "pseudolosowe", więc jedyne co
możesz to udowadniać "pseudolosowość".
Praktycznie: bierzesz jakiś test statystyczny (tzw. nieparametryczny) i
przepuszczasz przez ten test wygenerowane liczby. W istocie rzeczy nic ci
ten test nie daje więcej niż dawało gapienie na wygenerowaną sekwencję, ale
możesz dzięki niemu napisać "na poziomie istotności nn% test taki a taki nie
prowadzi do odrzucenia hipotezy zerowej zakładającej że liczby są losowe".
Konkretnie: 1000 liczb to mało - odpowiednik trzech myszy ("test leku
wykazał poprawę zdrowia u 1/3 populacji zwierząt doświadczalnych, u 1/3 stan
się nie zmienił, trzecia mysz uciekła").
A tak do pomyślenia: kolejne wywołania time(NULL) nie dają liczb losowych
(m.i. dlatego że każda kolejna jest większa od poprzedniej), jeżeli
następują szybko po sobie to mogą dawać nawet ten sam wynik. Czyli metodyka
badań jest trochę kulawa. (Z drugiej strony wygląda to jak zadanie -
ostatnia szansa - na zaliczenie przedmiotu - więc pal lich metodykę - ważne
aby program był jakoś sklecony i działał przynajmniej w czasie zaliczenia.)
Re: test randomizacyjny w C
Author: Norbert Cielecki
Date: Tue, 12 Jul 2016 10:17
Date: Tue, 12 Jul 2016 10:17
13 lines
1478 bytes
1478 bytes
Norbert Cielecki <apvryrpxv@bc.cy> wrote: > > Witam! > Czy ktoś mógłby mi wytłumaczyć, wjaki sposób funkcja rand() może | ma > skorzystać z 10 ziaren losowych srand(time(0)), przy generowaniu 1000 > liczb pseudolosowych z zakresu 1-10. Chodzi mi dokładnie o zbadanie > losowości generatora liczb pseudolosowych. Wdzięczny będę za wskazówki. > Dobrze, wszystko się ładnie składa, tylko nie mogę zrozumieć po cholerę im 10 ziaren w jednym programie i w jaki sposób mam za ich pomocą przeprowadzać (używając wszystkich) "losowania"? -- pzdr NTC.
Re: test randomizacyjny w C
Author: bartekltg
Date: Tue, 12 Jul 2016 15:54
Date: Tue, 12 Jul 2016 15:54
21 lines
1831 bytes
1831 bytes
On 12.07.2016 12:17, Norbert Cielecki wrote: > Norbert Cielecki <apvryrpxv@bc.cy> wrote: >> >> Witam! >> Czy ktoś mógłby mi wytłumaczyć, wjaki sposób funkcja rand() może | ma >> skorzystać z 10 ziaren losowych srand(time(0)), przy generowaniu 1000 >> liczb pseudolosowych z zakresu 1-10. Chodzi mi dokładnie o zbadanie >> losowości generatora liczb pseudolosowych. Wdzięczny będę za wskazówki. >> > Dobrze, wszystko się ładnie składa, tylko nie mogę zrozumieć po cholerę > im 10 ziaren w jednym programie i w jaki sposób mam za ich pomocą przeprowadzać (używając wszystkich) "losowania"? Po prostu to zrób. To nie jest ćwicenie na badanie losowości czy nawet na to jak generować liczby pseudolosowe, ale jak tego _nie_ robić. Wypisz liczby na ekran/ do pliku, nie rób żanych pauz czy niepotrzebnych operacji. Obejrzyj liczby. pzdr bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Tue, 12 Jul 2016 21:01
Date: Tue, 12 Jul 2016 21:01
31 lines
2070 bytes
2070 bytes
On 12.07.2016 17:54, bartekltg wrote:
> On 12.07.2016 12:17, Norbert Cielecki wrote:
>> Norbert Cielecki <apvryrpxv@bc.cy> wrote:
>>>
>>> Witam!
>>> Czy ktoś mógłby mi wytłumaczyć, wjaki sposób funkcja rand() może | ma
>>> skorzystać z 10 ziaren losowych srand(time(0)), przy generowaniu 1000
>>> liczb pseudolosowych z zakresu 1-10. Chodzi mi dokładnie o zbadanie
>>> losowości generatora liczb pseudolosowych. Wdzięczny będę za wskazówki.
>>>
>> Dobrze, wszystko się ładnie składa, tylko nie mogę zrozumieć po cholerę
>> im 10 ziaren w jednym programie i w jaki sposób mam za ich pomocą
>> przeprowadzać (używając wszystkich) "losowania"?
>
> Po prostu to zrób. To nie jest ćwicenie na badanie losowości
> czy nawet na to jak generować liczby pseudolosowe, ale jak
> tego _nie_ robić.
>
> Wypisz liczby na ekran/ do pliku, nie rób żanych pauz
> czy niepotrzebnych operacji. Obejrzyj liczby.
Hint, odpal to:
while (cin)
{
cout<<(time(0))<<endl;
this_thread::sleep_for(chrono::milliseconds(100));
}
pzdr
bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Tue, 12 Jul 2016 21:09
Date: Tue, 12 Jul 2016 21:09
37 lines
2229 bytes
2229 bytes
On 12.07.2016 23:01, bartekltg wrote:
> On 12.07.2016 17:54, bartekltg wrote:
>> On 12.07.2016 12:17, Norbert Cielecki wrote:
>>> Norbert Cielecki <apvryrpxv@bc.cy> wrote:
>>>>
>>>> Witam!
>>>> Czy ktoś mógłby mi wytłumaczyć, wjaki sposób funkcja rand() może | ma
>>>> skorzystać z 10 ziaren losowych srand(time(0)), przy generowaniu 1000
>>>> liczb pseudolosowych z zakresu 1-10. Chodzi mi dokładnie o zbadanie
>>>> losowości generatora liczb pseudolosowych. Wdzięczny będę za
>>>> wskazówki.
>>>>
>>> Dobrze, wszystko się ładnie składa, tylko nie mogę zrozumieć po cholerę
>>> im 10 ziaren w jednym programie i w jaki sposób mam za ich pomocą
>>> przeprowadzać (używając wszystkich) "losowania"?
>>
>> Po prostu to zrób. To nie jest ćwicenie na badanie losowości
>> czy nawet na to jak generować liczby pseudolosowe, ale jak
>> tego _nie_ robić.
>>
>> Wypisz liczby na ekran/ do pliku, nie rób żanych pauz
>> czy niepotrzebnych operacji. Obejrzyj liczby.
>
> Hint, odpal to:
>
> while (cin)
Sorry, to dla zmylenia przeciwnika;]
for(;;)
> {
> cout<<(time(0))<<endl;
> this_thread::sleep_for(chrono::milliseconds(100));
> }
pzdr
bartekltg
Re: test randomizacyjny w C
Author: keiichi
Date: Wed, 13 Jul 2016 18:23
Date: Wed, 13 Jul 2016 18:23
25 lines
2138 bytes
2138 bytes
W dniu 2016-07-12 o 12:17, Norbert Cielecki pisze: > Norbert Cielecki <apvryrpxv@bc.cy> wrote: >> >> Witam! >> Czy ktoś mógłby mi wytłumaczyć, wjaki sposób funkcja rand() może | ma >> skorzystać z 10 ziaren losowych srand(time(0)), przy generowaniu 1000 >> liczb pseudolosowych z zakresu 1-10. Chodzi mi dokładnie o zbadanie >> losowości generatora liczb pseudolosowych. Wdzięczny będę za wskazówki. >> > Dobrze, wszystko się ładnie składa, tylko nie mogę zrozumieć po cholerę > im 10 ziaren w jednym programie i w jaki sposób mam za ich pomocą przeprowadzać (używając wszystkich) "losowania"? > Mi to wygląda na jakieś zadanie, więc pominę wywody, czy to losowanie i sprawdzanie ma sens, czy nie, bo nie o to chodzi. Czy masz tam napisane, że masz *jednocześnie* używać 10 ziaren? Standardowymi funkcjami srand/rand tego nie osiągniesz. Może masz po prostu użyć 10 ziaren. Zainicjuj srand, wylosuj 1000 liczb, potem zainicjuj kolejne ziarno, 1000 liczb itd. 10 razy. Zapamiętaj, podsumuj, porównaj, wyświetl i gotowe. Pozdrawiam
Re: test randomizacyjny w C
Author: bartekltg
Date: Mon, 26 Sep 2016 21:17
Date: Mon, 26 Sep 2016 21:17
149 lines
8700 bytes
8700 bytes
On 26.09.2016 22:33, Borneq wrote:
> W dniu 26.09.2016 o 21:36, bartekltg pisze:
>> Nie, nie przechodzi testów; mt19937 przechodzi testy;p
>> dieharder -g 201 -f random10.dat -a
>
> Ranlux w każdej wersji LUX nie przechodzi diehard_operm5, co więcej -
> fizyczny random nie przechodzi diehard_opso, podczas gdy mt19937
> przechodzi wszystkie ? Myślałem że Ranlux lepiej się spisuje niż mt19937.
Coś zepsułeś.
[Co? Któż to wie, znów nie napisałeś, _co_ dokąłdnie zrobiłeś.]
Sprawadźmy te ranluxy.
for i in {43..49}; do dieharder -g $i -d 1; echo;echo; done
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlux| 1.78e+07 |2775139678|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.31240470| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlux389| 1.07e+07 |1235841629|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.85423943| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxd1| 1.16e+07 |3090234114|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.99705872| WEAK
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxd2| 6.25e+06 |3221774477|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.92391596| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxs0| 2.82e+07 |1766173486|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.60530086| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxs1| 1.93e+07 |3269615808|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.03864195| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxs2| 1.13e+07 |1751257048|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.41419599| PASSED
ranlxd1 jest podejrzeny, ale miałem 0.6% sanszy na każym generratorze
uzyskać taki wynik przez przypadek, więć 1-(1-0.006)^7= 4% uzyskać
go rpzypadkiem.
Powtórzmy, ze trzy razy:
for i in {1..3}; do dieharder -g 45 -d 1; echo;echo; done
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxd1| 1.14e+07 |2458088494|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.21088550| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxd1| 1.15e+07 |4264844718|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.58660050| PASSED
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown
#
#=============================================================================#
rng_name |rands/second| Seed |
ranlxd1| 1.14e+07 |2473325856|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_operm5| 0| 1000000| 100|0.31103629| PASSED
Wszystkie generatory z rodziny ranlux przechodzą diehard_operm5 na
standardowych ustawieniach.
pzdr
bartekltg
Re: test randomizacyjny w C
Author: Borneq
Date: Mon, 26 Sep 2016 21:25
Date: Mon, 26 Sep 2016 21:25
12 lines
2121 bytes
2121 bytes
W dniu 26.09.2016 o 23:17, bartekltg pisze: > Coś zepsułeś. > [Co? Któż to wie, znów nie napisałeś, _co_ dokąłdnie zrobiłeś.] Pliki powinny być dostatecznie duże. Nawet 10 megowy z fizycznym losowaniem jest za mały i bierze go kilka razy pod rząd. Teraz wygenerowałem 450 megowe i na razie ranlux(lux=24 czyli 0) oblewa pierwszy test urodzinowy a inne na razie przechodzi. Zastanawiam się: dla stopnia 1 czyli 48 przejdzie test urodzinowy. U mnie stopień 0 przechodzi pozostałe, ale widocznie nie dotarłem do testu spektralnego, jedynka nie przechodzi testu spektralnego a i stopień dwa jest teoretycznie niepewny.
Re: test randomizacyjny w C
Author: bartekltg
Date: Mon, 26 Sep 2016 21:35
Date: Mon, 26 Sep 2016 21:35
44 lines
3266 bytes
3266 bytes
On 26.09.2016 23:25, Borneq wrote: > W dniu 26.09.2016 o 23:17, bartekltg pisze: >> Coś zepsułeś. >> [Co? Któż to wie, znów nie napisałeś, _co_ dokąłdnie zrobiłeś.] > > Pliki powinny być dostatecznie duże. Nawet 10 megowy z fizycznym > losowaniem jest za mały i bierze go kilka razy pod rząd. > Teraz wygenerowałem 450 megowe i na razie ranlux(lux=24 czyli 0) oblewa > pierwszy test urodzinowy a inne na razie przechodzi. Swój własny generator? To czemu tego nie napsiałeś, choćby, z jakiej biblioteki. Znów nie widzę linii wywołania i wyników. (umówmy się tak, jak tego nie podejesz, uznaję, żę wyniki są zmyślone;> OK? ) Wracając do ranlux, widać coś popsułeś ;-) Np ustawiłeś LUX na 0, bo masz pamieć przysłowiowej złotej rybki, trzy dni temu o tym rozmawialiśmy: http://hep.fi.infn.it/cernlib.pdf Level p t 0 24 1 Equivalent to the original RCARRY of Marsaglia and Zaman, very long period, but fails many tests. 1 48 1.5 Considerable improvement in quality over level 0, now passes the gap test, but still fails spectral test. 2 97 2 Passes all known tests, but theoretically still defective. 3 223 3 DEFAULT VALUE. Any theoretically possible correlations have very small chance of being observed. 4 389 5 Highest possible luxury, all 24 bits chaotic. Jak kazałeś generatorowi być kiepskim, to jest kiepski. > Zastanawiam się: dla stopnia 1 czyli 48 przejdzie test urodzinowy. U > mnie stopień 0 przechodzi pozostałe, ale widocznie nie dotarłem do testu > spektralnego, jedynka nie przechodzi testu spektralnego a i stopień dwa > jest teoretycznie niepewny. No widzisz, dokaldnie tak, jak napisano w dokumentacji, którą dostałeś na tacy trzy dni temu ;-) pzdr bartekltg
Re: test randomizacyjny w C
Author: Borneq
Date: Mon, 26 Sep 2016 21:48
Date: Mon, 26 Sep 2016 21:48
25 lines
2744 bytes
2744 bytes
W dniu 26.09.2016 o 23:35, bartekltg pisze: > z jakiej biblioteki. Znów nie widzę linii wywołania i wyników. > (umówmy się tak, jak tego nie podejesz, uznaję, żę wyniki są zmyślone;> > OK? ) > > Wracając do ranlux, widać coś popsułeś ;-) > Np ustawiłeś LUX na 0, bo masz pamieć przysłowiowej złotej rybki, > trzy dni temu o tym rozmawialiśmy: dieharder -g 201 -f lux0.bin -a wygenerowałem lux0.bin..lux4.bin wszystkie po 450 mega gdy były małe np 3 mega, wtedy takie testy jak diehard_operm5 nie przechodziły. Tutaj chciałem zobaczyć, jaki test oprócz urodzinowego jeszcze nie przejdzie. Stopień zerowy celowo, bo interesują mnie nie przebyte testy. Jeszcze dla stopnia 1 pisali o spektralnym, nie widzę go w DieHarder, ale może jest w ten w pakiecie TestU01. Jest kilka pakietów: w http://stackoverflow.com/questions/778718/how-to-test-random-numbers podane jest: Dieharder - http://www.phy.duke.edu/~rgb/General/dieharder.php TestU01 - http://simul.iro.umontreal.ca/testu01/tu01.html RaBiGeTe - http://cristianopi.altervista.org/RaBiGeTe_MT/ NIST STS - http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html PractRand - http://pracrand.sourceforge.net/
Re: test randomizacyjny w C
Author: bartekltg
Date: Tue, 27 Sep 2016 17:02
Date: Tue, 27 Sep 2016 17:02
86 lines
5094 bytes
5094 bytes
On 27.09.2016 15:55, Borneq wrote: > W dniu 26.09.2016 o 23:39, bartekltg pisze: >> I chce mieć jakieś przesłanki by wierzyc, że nawet tak długi ciąg nadal >> ma statystyczne własności liczb losowych i że moja całeczka wyjdzie >> z dokąłdnością do tych 6 miejsc po przecinku. Testy działajace w sekundę >> to trochę mało ;-) > > Z czego wynika dobra chaotyczność RanLuxa? Na poziomie 0 działa jak > algorytm o nazwie RCarry, poziom 1 to połowa wyników idzie do śmietnika: > najpierw wypluwa 24 wyniki, potem opuszcza 24. > potem jest > level 2 (luxury=97) > level 3 (luxury=223) > level 4 (luxury=389) > opuszcza luxury-24. Liczby 97,223 i 389 przypuszcam dobrane > nieprzypadkowo, nawet opuszczenie 200 działało by gorzej niż 223-24. Jest to doskonale opisane w linku, który sam podałeś: http://arxiv.org/pdf/hep-lat/9309020.pdf Idea jest taka: Jak weżmiesz kolejne r zmiennych, potraktujmy je jako wektor X1, a potem popatrzysz na jeszcze koljene r (X2), to pomiędzy tym dwoma zestawami mamy przekształcenie liniowe (jeśli pominiemy carry) X2 = M X1 (modulo b). To źle wróży, bo przekształcenia liniowe są ciągłe, bliskie punkty przechodzą na bliskie (mówimy w tej chwili już o liczbach rzeczywistych). No i zwykły subtract-with-borrow zachowuje się kiepskawo (patrz też std::subtract_with_carry_engine). Ale... jest to przekształcenie jest 'rozciągające'. Okazuje się, że ma dodatni wykłądnik Lapunowa. A to oznacza, że po wielu itaracjach punkty, które były blisko, będą daleko. Ponieważ siedzimy na r-wymairowym torusie, że będą rozsiane po całej przestrzeni. Więc po odczytaniu r (a moze r-1) wartośći należy odrzucić ilos kolejnych (czyli jakby odrzuciź X2, X3... X_kilkaknaście) i dobiera użyć X_kilkanaśćie+1, bo w tym zestawie korelacji z poprzednim nie będzie. To szkic, szczególy masz w pdf. Siedzą tam pewne subtelne pułapki, np wartosći całkowite mogą być na wrednym małym podzbiorze, który jest okresowy z jakimś nieprzyzwoicie małym okresem (patrz https://en.wikipedia.org/wiki/Arnold%27s_cat_map). > Chciałem zrobić RCarry do kwadratu, w którym RCarry byłby sterowany > drugim RCarry. > Działał by w ten sposób, że drugi losował by liczbę z przedziału 1..32, > pierwszy wypluwał by tyle wyników, potem drugie losowanie i pierwszy by > tyle wyników opuszczał. Myślałem że byłby lepszy, bo nawet jak RanLux > opuści blisko 200, to mamy regularność: bierze 24, opuszcza 199 itd.. > Napisałem https://gist.github.com/borneq/abc66f4c861950cf87275523b1262bd9 > i działa z prędkością RanLux level 1 opuszczając połowę (dodanie > drugiego praktycznie nie zwalnia, bo jest rzadko wołany) > Tylko problem: na teście Birthday jest WEAK, nawet gdy sprawdziłem dla > innego seeda. Czyli zachowuje się gorzej niż RanLux Level 1. A masz pewność, że wynikowy rozkłąd jest jednostajny? > A więc chaotyczność spowodowana jest tym, że pomijamy około 200 wyników, > a nawet zmienna ilość pomijanych jest gorsza. > Jeśli chodzi o prędkość to RanLux przegrywa z MT19937? O czynnik 20 ;-) Jeden z grupowiczów chwalił PCG. Bierze się taki sobie generator, ale użytkownikowi nie daje się tego ciągu, ale liczby tego ciągu przepuszczone przez jakąś lepszą funkcję hashującą. Szybkie są, a do tego małe. pzdr bartekltg pzdr bartekltg
Re: test randomizacyjny w C
Author: Borneq
Date: Tue, 27 Sep 2016 17:54
Date: Tue, 27 Sep 2016 17:54
9 lines
2004 bytes
2004 bytes
W dniu 27.09.2016 o 19:02, bartekltg pisze: >> Jeśli chodzi o prędkość to RanLux przegrywa z MT19937? > > O czynnik 20 ;-) A co myślisz o dyskusji Marsaglii na temat tego generatora (linki z polskiej Wikipedii na temat MT19937): https://groups.google.com/forum/#!topic/comp.lang.c/qZFQgKRCQGg https://groups.google.com/forum/#!topic/sci.crypt/MFxQfvvoW-Q
Re: test randomizacyjny w C
Author: M.M.
Date: Tue, 27 Sep 2016 18:12
Date: Tue, 27 Sep 2016 18:12
123 lines
10260 bytes
10260 bytes
On Tuesday, September 27, 2016 at 7:52:20 PM UTC+2, Borneq wrote:
> W dniu 27.09.2016 o 19:12, M.M. pisze:
> > Hmmmm mój generator (złożenie generatorów fibonaciego) ostatnio przeszedł
> > test birthday, na dole wkleję.
>
> To ciekawe, bo mój jest złożeniem i to mającym losowo pomijać pewną
> ilość a i tak dla birthday jest break nie mówiąc o innych
> właściwościach: gdy przejdziemy RanLuxem birthday to jeszcze jakiś test
> spektralny, ale jak i go przejdziemy to teoretyczne nieścisłości.
Włączyłem jeszcze raz na m = 1, te testy które się już zakończyły, są passed:
time ./rnd | dieharder -a -g 200 -m 1
#=============================================================================#
# dieharder version 3.31.1 Copyright 2003 Robert G. Brown #
#=============================================================================#
rng_name |rands/second| Seed |
stdin_input_raw| 2.71e+07 |2664392413|
#=============================================================================#
test_name |ntup| tsamples |psamples| p-value |Assessment
#=============================================================================#
diehard_birthdays| 0| 100| 100|0.64349609| PASSED
diehard_operm5| 0| 1000000| 100|0.97377736| PASSED
diehard_rank_32x32| 0| 40000| 100|0.44768640| PASSED
diehard_rank_6x8| 0| 100000| 100|0.90602258| PASSED
diehard_bitstream| 0| 2097152| 100|0.97214777| PASSED
diehard_opso| 0| 2097152| 100|0.51326223| PASSED
diehard_oqso| 0| 2097152| 100|0.90361549| PASSED
diehard_dna| 0| 2097152| 100|0.81001827| PASSED
diehard_count_1s_str| 0| 256000| 100|0.77859285| PASSED
diehard_count_1s_byt| 0| 256000| 100|0.07964640| PASSED
diehard_parking_lot| 0| 12000| 100|0.18589551| PASSED
diehard_2dsphere| 2| 8000| 100|0.35338027| PASSED
diehard_3dsphere| 3| 4000| 100|0.99275707| PASSED
diehard_squeeze| 0| 100000| 100|0.54099159| PASSED
diehard_sums| 0| 100| 100|0.08354464| PASSED
diehard_runs| 0| 100000| 100|0.65197195| PASSED
diehard_runs| 0| 100000| 100|0.99354055| PASSED
diehard_craps| 0| 200000| 100|0.47291673| PASSED
diehard_craps| 0| 200000| 100|0.14326505| PASSED
marsaglia_tsang_gcd| 0| 10000000| 100|0.26640208| PASSED
marsaglia_tsang_gcd| 0| 10000000| 100|0.35730344| PASSED
sts_monobit| 1| 100000| 100|0.05379196| PASSED
sts_runs| 2| 100000| 100|0.76729525| PASSED
sts_serial| 1| 100000| 100|0.68784776| PASSED
sts_serial| 2| 100000| 100|0.73905649| PASSED
sts_serial| 3| 100000| 100|0.68219636| PASSED
sts_serial| 3| 100000| 100|0.96346581| PASSED
sts_serial| 4| 100000| 100|0.37617476| PASSED
sts_serial| 4| 100000| 100|0.70189906| PASSED
sts_serial| 5| 100000| 100|0.73583887| PASSED
sts_serial| 5| 100000| 100|0.83511384| PASSED
sts_serial| 6| 100000| 100|0.22251082| PASSED
sts_serial| 6| 100000| 100|0.53936899| PASSED
sts_serial| 7| 100000| 100|0.48970835| PASSED
sts_serial| 7| 100000| 100|0.36652650| PASSED
sts_serial| 8| 100000| 100|0.71000549| PASSED
sts_serial| 8| 100000| 100|0.92361925| PASSED
sts_serial| 9| 100000| 100|0.94874280| PASSED
sts_serial| 9| 100000| 100|0.24776664| PASSED
sts_serial| 10| 100000| 100|0.85990907| PASSED
sts_serial| 10| 100000| 100|0.84886387| PASSED
sts_serial| 11| 100000| 100|0.39742672| PASSED
sts_serial| 11| 100000| 100|0.24629784| PASSED
sts_serial| 12| 100000| 100|0.00524632| PASSED
sts_serial| 12| 100000| 100|0.01946086| PASSED
sts_serial| 13| 100000| 100|0.05985317| PASSED
sts_serial| 13| 100000| 100|0.96823046| PASSED
sts_serial| 14| 100000| 100|0.10707524| PASSED
sts_serial| 14| 100000| 100|0.48174459| PASSED
sts_serial| 15| 100000| 100|0.32279683| PASSED
sts_serial| 15| 100000| 100|0.98407243| PASSED
sts_serial| 16| 100000| 100|0.94296835| PASSED
sts_serial| 16| 100000| 100|0.44146129| PASSED
rgb_bitdist| 1| 100000| 100|0.30183244| PASSED
rgb_bitdist| 2| 100000| 100|0.91119214| PASSED
rgb_bitdist| 3| 100000| 100|0.89466943| PASSED
rgb_bitdist| 4| 100000| 100|0.05590017| PASSED
rgb_bitdist| 5| 100000| 100|0.36688055| PASSED
rgb_bitdist| 6| 100000| 100|0.77392593| PASSED
rgb_bitdist| 7| 100000| 100|0.28969866| PASSED
rgb_bitdist| 8| 100000| 100|0.98039972| PASSED
rgb_bitdist| 9| 100000| 100|0.76775322| PASSED
rgb_bitdist| 10| 100000| 100|0.07049677| PASSED
rgb_bitdist| 11| 100000| 100|0.56941133| PASSED
rgb_bitdist| 12| 100000| 100|0.49093420| PASSED
rgb_minimum_distance| 2| 10000| 1000|0.68776581| PASSED
rgb_minimum_distance| 3| 10000| 1000|0.59036998| PASSED
rgb_minimum_distance| 4| 10000| 1000|0.66458777| PASSED
rgb_minimum_distance| 5| 10000| 1000|0.16046081| PASSED
rgb_permutations| 2| 100000| 100|0.27160029| PASSED
rgb_permutations| 3| 100000| 100|0.50305842| PASSED
rgb_permutations| 4| 100000| 100|0.11321640| PASSED
rgb_permutations| 5| 100000| 100|0.87148790| PASSED
rgb_lagged_sum| 0| 1000000| 100|0.98684886| PASSED
rgb_lagged_sum| 1| 1000000| 100|0.38439509| PASSED
rgb_lagged_sum| 2| 1000000| 100|0.14787893| PASSED
rgb_lagged_sum| 3| 1000000| 100|0.93062217| PASSED
rgb_lagged_sum| 4| 1000000| 100|0.66233457| PASSED
rgb_lagged_sum| 5| 1000000| 100|0.62381592| PASSED
rgb_lagged_sum| 6| 1000000| 100|0.07828622| PASSED
rgb_lagged_sum| 7| 1000000| 100|0.51410646| PASSED
rgb_lagged_sum| 8| 1000000| 100|0.40648930| PASSED
rgb_lagged_sum| 9| 1000000| 100|0.66302547| PASSED
rgb_lagged_sum| 10| 1000000| 100|0.71404866| PASSED
rgb_lagged_sum| 11| 1000000| 100|0.11459871| PASSED
rgb_lagged_sum| 12| 1000000| 100|0.42678698| PASSED
rgb_lagged_sum| 13| 1000000| 100|0.15434806| PASSED
rgb_lagged_sum| 14| 1000000| 100|0.91374028| PASSED
rgb_lagged_sum| 15| 1000000| 100|0.45952282| PASSED
rgb_lagged_sum| 16| 1000000| 100|0.78111231| PASSED
rgb_lagged_sum| 17| 1000000| 100|0.63766496| PASSED
rgb_lagged_sum| 18| 1000000| 100|0.81629503| PASSED
rgb_lagged_sum| 19| 1000000| 100|0.01276499| PASSED
rgb_lagged_sum| 20| 1000000| 100|0.74495368| PASSED
rgb_lagged_sum| 21| 1000000| 100|0.71906805| PASSED
rgb_lagged_sum| 22| 1000000| 100|0.69127852| PASSED
rgb_lagged_sum| 23| 1000000| 100|0.77827353| PASSED
rgb_lagged_sum| 24| 1000000| 100|0.90263304| PASSED
rgb_lagged_sum| 25| 1000000| 100|0.91181598| PASSED
rgb_lagged_sum| 26| 1000000| 100|0.96264282| PASSED
rgb_lagged_sum| 27| 1000000| 100|0.95390491| PASSED
rgb_lagged_sum| 28| 1000000| 100|0.36189939| PASSED
Re: test randomizacyjny w C
Author: bartekltg
Date: Wed, 28 Sep 2016 11:00
Date: Wed, 28 Sep 2016 11:00
36 lines
3148 bytes
3148 bytes
On 27.09.2016 19:12, M.M. wrote: > On Tuesday, September 27, 2016 at 3:55:07 PM UTC+2, Borneq wrote: >> W dniu 26.09.2016 o 23:39, bartekltg pisze: >>> I chce mieć jakieś przesłanki by wierzyc, że nawet tak długi ciąg nadal >>> ma statystyczne własności liczb losowych i że moja całeczka wyjdzie >>> z dokąłdnością do tych 6 miejsc po przecinku. Testy działajace w sekundę >>> to trochę mało ;-) >> >> Z czego wynika dobra chaotyczność RanLuxa? Na poziomie 0 działa jak >> algorytm o nazwie RCarry, poziom 1 to połowa wyników idzie do śmietnika: >> najpierw wypluwa 24 wyniki, potem opuszcza 24. >> potem jest >> level 2 (luxury=97) >> level 3 (luxury=223) >> level 4 (luxury=389) >> opuszcza luxury-24. Liczby 97,223 i 389 przypuszcam dobrane >> nieprzypadkowo, nawet opuszczenie 200 działało by gorzej niż 223-24. > > Technika ciekawa, aczkolwiek na pierwszy rzut oka wydaje się marnowaniem > wygenerowanych liczb. Dokładnie tym jest, Za to zwiększa precyzje. Z drugiej strony, jeśli buduje się za kosmiczne pieniądze wielkie urzedzenie, można dodać parę groszy na większy komputer by wyniki uzyskane za jego pomocą były pewniejsze i nieco oddalić możliwosć tego, że odkrycie higsa stanie się koljenym testem na jakość generatora ;-) Ranluxa zrobił cość z CERN, miał powody ;-) Próbuję czytać o PCG, do końca jeszcze przekonany nie jestem;-) pzdr bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Wed, 28 Sep 2016 11:01
Date: Wed, 28 Sep 2016 11:01
14 lines
2268 bytes
2268 bytes
On 27.09.2016 19:52, Borneq wrote: > W dniu 27.09.2016 o 19:12, M.M. pisze: >> Hmmmm mój generator (złożenie generatorów fibonaciego) ostatnio przeszedł >> test birthday, na dole wkleję. > > To ciekawe, bo mój jest złożeniem i to mającym losowo pomijać pewną > ilość a i tak dla birthday jest break nie mówiąc o innych > właściwościach: gdy przejdziemy RanLuxem birthday to jeszcze jakiś test > spektralny, ale jak i go przejdziemy to teoretyczne nieścisłości. Jak wylosujesz ma małe pominięcie, to masz korelacje. pzdr bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Wed, 28 Sep 2016 11:02
Date: Wed, 28 Sep 2016 11:02
17 lines
2186 bytes
2186 bytes
On 27.09.2016 19:54, Borneq wrote: > W dniu 27.09.2016 o 19:02, bartekltg pisze: >>> Jeśli chodzi o prędkość to RanLux przegrywa z MT19937? >> >> O czynnik 20 ;-) > > A co myślisz o dyskusji Marsaglii na temat tego generatora (linki z > polskiej Wikipedii na temat MT19937): > https://groups.google.com/forum/#!topic/comp.lang.c/qZFQgKRCQGg > https://groups.google.com/forum/#!topic/sci.crypt/MFxQfvvoW-Q Chcesz mie nakierować na jakiś konkretny fragment? pzdr bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Wed, 28 Sep 2016 11:04
Date: Wed, 28 Sep 2016 11:04
9 lines
1903 bytes
1903 bytes
On 27.09.2016 19:12, M.M. wrote: > Hmmmm mój generator (złożenie generatorów fibonaciego) ostatnio przeszedł > test birthday, na dole wkleję. XOR z dwóch ciągów, czy coś ciekawszego? pzdr bartekltg
Re: test randomizacyjny w C
Author: bartekltg
Date: Wed, 28 Sep 2016 11:06
Date: Wed, 28 Sep 2016 11:06
20 lines
2502 bytes
2502 bytes
On 27.09.2016 22:30, M.M. wrote: > On Tuesday, September 27, 2016 at 10:25:29 PM UTC+2, Borneq wrote: >> W dniu 27.09.2016 o 21:56, M.M. pisze: >>> Opcja -g 200 czyli wypluwa na stdout w formacie binarnym. >> >> A jak? Bo na stdout to zwykle piszę za pomocą printfa tekstowo > > Ja mam fwrite( out , 8 , 128 , stdout ) - wyrzucam 128 liczby > typu uint64 w jednym wywołaniu. > > A tutaj testy z MT, wszystkie przeszedł. Test działał około 2 razy > szybciej niż mojego generatora, ale MT nie korzystał z stdout, jest > wkompilowany w diehardera. Zawszde mozesz użyć tego z std::random, pewnie 5 minut pisania, a niknie nieuczciwa przewaga ;> pzdr bartekltg
Re: test randomizacyjny w C
Author: Borneq
Date: Wed, 28 Sep 2016 11:37
Date: Wed, 28 Sep 2016 11:37
17 lines
2369 bytes
2369 bytes
W dniu 28.09.2016 o 13:02, bartekltg pisze: >> https://groups.google.com/forum/#!topic/comp.lang.c/qZFQgKRCQGg >> https://groups.google.com/forum/#!topic/sci.crypt/MFxQfvvoW-Q > > Chcesz mie nakierować na jakiś konkretny fragment? The Mersenne Twister (check Google) is an excellent RNG, with k=624. But it requires an elaborate C program and is slower than many RNGs that do as well in tests, have comparable or longer periods and require only a few lines of code. Here is a complimentary-multiply-with-carry RNG with k=4097 and a near-record period, more than 10^33000 times as long as that of the Twister. (2^131104 vs. 2^19937)
Re: test randomizacyjny w C
Author: Borneq
Date: Wed, 28 Sep 2016 11:49
Date: Wed, 28 Sep 2016 11:49
18 lines
2712 bytes
2712 bytes
W dniu 27.09.2016 o 23:00, M.M. pisze:
> Ta ostatnia wersja to 5 generatorów fibonacciego. Jeden
> generator wybiera jeden z czterech.
>
> switch( rand1() % 4 ) {
> case 0: return rand2();
Jeśli przed każdym losowaniem z tych czterech będzie losowanie z
rand1(), mamy 100% narzut czasowy. U mnie tego narzutu nie było
(jedynie 50% marnotrawstwo wyników) ponieważ gdy sterujący coś wybrał,
to średnio 16 razy wypluwał wyniki albo nie.
Gdy żaden z tych czterech nie przechodzi testu Birthday, to dlaczego ich
przemienny wybór ma potrafić?
Dla tych czterech parametry r i s dobrałeś eksperymentalnie, a tylko nie
które r i s dadzą długie okresy.
A próbowałeś zamiast pięciu użyć trzech? Jeden steruje między drugim a
trzecim? Czy zamiast wybierać co każde losowanie wybierałbyś z rand1
liczbę 1..16 i tyle razy miałby szansę każdy z nich?
Re: test randomizacyjny w C
Author: Borneq
Date: Wed, 28 Sep 2016 11:57
Date: Wed, 28 Sep 2016 11:57
18 lines
2529 bytes
2529 bytes
W dniu 28.09.2016 o 13:37, Borneq pisze: > W dniu 28.09.2016 o 13:02, bartekltg pisze: >>> https://groups.google.com/forum/#!topic/comp.lang.c/qZFQgKRCQGg >>> https://groups.google.com/forum/#!topic/sci.crypt/MFxQfvvoW-Q >> >> Chcesz mie nakierować na jakiś konkretny fragment? > > Here is a complimentary-multiply-with-carry RNG > with k=4097 and a near-record period, more than > 10^33000 times as long as that of the Twister. > (2^131104 vs. 2^19937) http://school.anhb.uwa.edu.au/personalpages/kwessen/shared/Marsaglia03.html https://en.wikipedia.org/wiki/Multiply-with-carry Mnożenie na szybkich procesorach Intel/Athlon wykonuje się szybko, choć gdyby chcieć to zaimplementować w sprzęcie wtedy mnożenie będzie bardziej złożone od takich xor i shift.
Re: test randomizacyjny w C
Author: Borneq
Date: Wed, 28 Sep 2016 12:10
Date: Wed, 28 Sep 2016 12:10
7 lines
2138 bytes
2138 bytes
W dniu 28.09.2016 o 13:57, Borneq pisze: > http://school.anhb.uwa.edu.au/personalpages/kwessen/shared/Marsaglia03.html > https://en.wikipedia.org/wiki/Multiply-with-carry Jest jeszcze KISS: W Wikipedii mało: https://en.wikipedia.org/wiki/KISS_(algorithm) jest jeszcze http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
Page 2 of 2 • 78 total messages
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads