🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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
#308766
Author: Norbert Cielecki
Date: Mon, 04 Jul 2016 12:36
41 lines
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
#308763
Author: bartekltg
Date: Mon, 04 Jul 2016 21:09
43 lines
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
#308764
Author: M.M.
Date: Mon, 04 Jul 2016 21:44
46 lines
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
#308765
Author: bartekltg
Date: Mon, 04 Jul 2016 22:13
19 lines
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
#308762
Author: bartekltg
Date: Tue, 05 Jul 2016 13:46
120 lines
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
#308767
Author: slawek
Date: Fri, 08 Jul 2016 08:21
30 lines
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
#308768
Author: Norbert Cielecki
Date: Tue, 12 Jul 2016 10:17
13 lines
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
#308769
Author: bartekltg
Date: Tue, 12 Jul 2016 15:54
21 lines
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
#308770
Author: bartekltg
Date: Tue, 12 Jul 2016 21:01
31 lines
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
#308771
Author: bartekltg
Date: Tue, 12 Jul 2016 21:09
37 lines
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
#308772
Author: keiichi
Date: Wed, 13 Jul 2016 18:23
25 lines
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
#308758
Author: bartekltg
Date: Mon, 26 Sep 2016 21:17
149 lines
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
#308759
Author: Borneq
Date: Mon, 26 Sep 2016 21:25
12 lines
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
#308760
Author: bartekltg
Date: Mon, 26 Sep 2016 21:35
44 lines
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
#308761
Author: Borneq
Date: Mon, 26 Sep 2016 21:48
25 lines
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
#308752
Author: bartekltg
Date: Tue, 27 Sep 2016 17:02
86 lines
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
#308753
Author: Borneq
Date: Tue, 27 Sep 2016 17:54
9 lines
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
#308748
Author: M.M.
Date: Tue, 27 Sep 2016 18:12
123 lines
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
#308750
Author: bartekltg
Date: Wed, 28 Sep 2016 11:00
36 lines
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
#308749
Author: bartekltg
Date: Wed, 28 Sep 2016 11:01
14 lines
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
#308754
Author: bartekltg
Date: Wed, 28 Sep 2016 11:02
17 lines
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
#308751
Author: bartekltg
Date: Wed, 28 Sep 2016 11:04
9 lines
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
#308747
Author: bartekltg
Date: Wed, 28 Sep 2016 11:06
20 lines
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
#308755
Author: Borneq
Date: Wed, 28 Sep 2016 11:37
17 lines
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
#308746
Author: Borneq
Date: Wed, 28 Sep 2016 11:49
18 lines
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
#308756
Author: Borneq
Date: Wed, 28 Sep 2016 11:57
18 lines
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
#308757
Author: Borneq
Date: Wed, 28 Sep 2016 12:10
7 lines
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