🚀 go-pugleaf

sobota, 21 sierpnia 2021 o 00:11:26 UTC+2 M.M. napisał(a):
> On Friday, August 20, 2021 at 11:56:42 PM UTC+2, osobli...@gmail.com wrote: 
> > Jeśli zrobiłem wszystko dobrze, to mam debug error - "abort() has been called". Próbowałem opcji z plikiem .data.
> Nie ma w pliku jakiś innych znaków niż 0 i 1? Nie ma np. znaku końca linii? 
> 
> U siebie zmniejszyłem bufor do jednego bajtu: 
> #define SIZE_OUT (1<<0) 
> 
> I uruchomiłem taką komendę: 
> echo '01010101111111110000000010101001' | ./01ToBin 
> 
> Nic się nie wywaliło, wyrzuciło na ekran krzaczki - zgodnie z oczekiwaniami. 
> 
> Pozdrawiam

U mnie po komendzie echo '01010101111111110000000010101001' | ./konwerter.exe 

nie pokazało niczego.

On Saturday, August 21, 2021 at 4:53:36 PM UTC+2, osobli...@gmail.com wrote:
> sobota, 21 sierpnia 2021 o 00:11:26 UTC+2 M.M. napisał(a): 
> > On Friday, August 20, 2021 at 11:56:42 PM UTC+2, osobli...@gmail.com wrote: 
> > > Jeśli zrobiłem wszystko dobrze, to mam debug error - "abort() has been called". Próbowałem opcji z plikiem .data. 
> > Nie ma w pliku jakiś innych znaków niż 0 i 1? Nie ma np. znaku końca linii? 
> > 
> > U siebie zmniejszyłem bufor do jednego bajtu: 
> > #define SIZE_OUT (1<<0) 
> > 
> > I uruchomiłem taką komendę: 
> > echo '01010101111111110000000010101001' | ./01ToBin 
> > 
> > Nic się nie wywaliło, wyrzuciło na ekran krzaczki - zgodnie z oczekiwaniami. 
> > 
> > Pozdrawiam
> U mnie po komendzie echo '01010101111111110000000010101001' | ./konwerter.exe 
> 
> nie pokazało niczego.

Nie pokazało, bo ten minimalistyczny program umie tylko czytać pełnymi buforami, albo
konsola ukryła binarne znaki. By trzeba ustawić przed kompilacją mały rozmiar buforu,
ale teraz to nie ma sens, bo jest już specjalny generator do testowania:

https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp

U mnie nawet działa:

./SimpPRNG 2 | ../../01ToBin/release/01ToBin | ../../PractRand/RNG_test stdin
RNG_test using PractRand version 0.94
RNG = RNG_stdin, seed = unknown
test set = core, folding = standard(unknown format)

rng=RNG_stdin, seed=unknown
length= 64 megabytes (2^26 bytes), time= 2.8 seconds
  no anomalies in 179 test result(s)

rng=RNG_stdin, seed=unknown
length= 128 megabytes (2^27 bytes), time= 6.2 seconds
  no anomalies in 196 test result(s)

rng=RNG_stdin, seed=unknown
length= 256 megabytes (2^28 bytes), time= 12.3 seconds
  no anomalies in 213 test result(s)

rng=RNG_stdin, seed=unknown
length= 512 megabytes (2^29 bytes), time= 23.4 seconds
  no anomalies in 229 test result(s)

rng=RNG_stdin, seed=unknown
length= 1 gigabyte (2^30 bytes), time= 45.4 seconds
  no anomalies in 248 test result(s)

rng=RNG_stdin, seed=unknown
length= 2 gigabytes (2^31 bytes), time= 88.6 seconds
  no anomalies in 266 test result(s)

rng=RNG_stdin, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 173 seconds
  no anomalies in 282 test result(s)

rng=RNG_stdin, seed=unknown
length= 8 gigabytes (2^33 bytes), time= 341 seconds
  no anomalies in 299 test result(s)

rng=RNG_stdin, seed=unknown
length= 16 gigabytes (2^34 bytes), time= 683 seconds
  no anomalies in 315 test result(s)

rng=RNG_stdin, seed=unknown
length= 32 gigabytes (2^35 bytes), time= 1425 seconds
  no anomalies in 328 test result(s)

rng=RNG_stdin, seed=unknown
length= 64 gigabytes (2^36 bytes), time= 2808 seconds
  no anomalies in 344 test result(s)

rng=RNG_stdin, seed=unknown
length= 128 gigabytes (2^37 bytes), time= 5577 seconds
  no anomalies in 359 test result(s)

^C


Pozdrawiam

On Saturday, August 21, 2021 at 10:55:35 PM UTC+2, osobli...@gmail.com wrote:
> sobota, 21 sierpnia 2021 o 21:57:26 UTC+2 M.M. napisał(a): 
> > On Saturday, August 21, 2021 at 7:16:13 PM UTC+2, osobli...@gmail.com wrote: 
> > > A czy mój generator może być napisany w Pythonie? I czy pojedyncze wywołanie generatora ma dawać pojedynczy bit, czy może dawać np. liczbę 128-bitową zapisaną binarnie "01010101...11110101"? Jak bity zamienić na ascii? 
> > Zrozumiałem, że masz gotowy program (plik) co generuje ciąg zer i jedynek w formacie tekstowym 
> > (innymi słowy w formacie ASCII).
> Tak. Czy program ma wypisywać te zera i jedynki za pomocą printa, czy po prostu wywołanie funkcji ma je generować, a print nie jest potrzebny? I czy muszę to ciąć tak, żeby program wypisywał: 
> 1 
> 0 
> 0 
> 1 

Rozmawialiśmy kilka postów wcześniej w ten sposób:
[
> > Teraz nie mogę, potem dam kod program który przekonwertuje plik tekstowy do binarnego. Proszę, pokaż ( i jeśli trzeba to opisz )
> > jak wygląda oryginalny plik tekstowy.

> Jeżeli zapisuję dane to pliku .txt, to wygląda to tak:

> "0101010101010001011110101010101011101001011111010110111110...01010101010101010010101010101001010101010100101010101011111"

> Po prostu pseudolosowy ciąg zer i jedynek, nic więcej.
]

Więc konwerter takie dane umie odczytać i zamienia je na format binarny dla PractRand. To co zapisujesz do pliku, po prostu
wyświetl teraz na konsolę (a nie do pliku). Konwerter to odczyta z konsoli i poda dalej do PractRand. Tylko trzeba te trzy
programy połączyć komendą shell:

TwójProgram | Konwerter | PractRand

> Czy może wypisywać liczba po liczbie w formacie binarnym: 

Jeśli w formacie binarnym, to nie jest potrzebny żaden konwerter. Wystarczy użyć
TwójProgram | PractRand

> 
> 10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010 
> 11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100 
> 11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000 
> 1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000 
> 
> Po uruchomieniu komendy: 
> 
> Mojgenerator.py | ./Konwerter.exe | ./RNG_test stdin 
> 
> Dostaję komunikat: 
> 
> "Mojgenerator.py: command not found 
> RNG_test using PractRand version 0.93 
> RNG = RNG_stdin, seed = 0xe345c308 
> test set = normal, folding = standard(unknown format) 
> 
> Segmentation fault (core dumped)" 
> 
> Niezależnie, czy wpiszę Mojgenerator, Mojgenerator.py, czy Mojgenerator.exe.

Konwerter się wywali jeśli dostanie na wejście cokolwiek innego niż znak ASCII '0' lub '1'. 

Pozdrawiam

On Saturday, August 21, 2021 at 11:37:18 PM UTC+2, osobli...@gmail.com wrote:
> PS Program w konsoli działa normalnie, wypisuje liczby binarnie: 
> 
> 10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010 
> 11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100 
> 11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000 
> 1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000

Nie wiem co naprawdę wypisuje Twój program na konsolę, ale to co wkleiłeś wygląda jak dane tekstowe w dodatku oddzielone znakiem (lub nawet dwoma znakami!) nowej linii. Upewnij się w edytorze hexadecymalnym.

Pozdrawiam

On Saturday, August 21, 2021 at 11:37:18 PM UTC+2, osobli...@gmail.com wrote:
> PS Program w konsoli działa normalnie, wypisuje liczby binarnie: 
> 
> 10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010 
> 11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100 
> 11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000 
> 1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000

I jeszcze jedno, wszystkie te liczby zaczynają się od jedynki i nie są równej długości, zobacz co usuwa zera wiodące - w teście muszą być.

Pozdrawiam

niedziela, 22 sierpnia 2021 o 02:46:22 UTC+2 M.M. napisał(a):
> On Saturday, August 21, 2021 at 11:37:18 PM UTC+2, osobli...@gmail.com wrote: 
> > PS Program w konsoli działa normalnie, wypisuje liczby binarnie: 
> > 
> > 10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010 
> > 11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100 
> > 11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000 
> > 1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000
> I jeszcze jedno, wszystkie te liczby zaczynają się od jedynki i nie są równej długości, zobacz co usuwa zera wiodące - w teście muszą być. 
> 
> Pozdrawiam

Nie mam pojęcia skąd było to "0a31", zmieniłem seed i już go nie ma (choć nie mam żadnej pewności, że znów się gdzieś nie pojawi). Wiodące zera usuwa konwerter pythona na liczby binarne. Jeśli liczba jest mniejsza niż 128-bitów, to żadne zera na przodzie nie zostaną wypisane. Po zmianie seeda mam problem "Segmentation fault (core dumped)", zarówno z konwerterem jak i bez:

RNG_test using PractRand version 0.93
RNG = RNG_stdin, seed = 0xc3b8ea62
test set = normal, folding = standard(unknown format)

Segmentation fault (core dumped)

Plik po komendzie:

cat LCGtest.data | ./konwerter1.exe | ./RNG_test stdin

Daje znów pełno faili:

RNG_test using PractRand version 0.93
RNG = RNG_stdin, seed = 0xa06e3586
test set = normal, folding = standard(unknown format)

rng=RNG_stdin, seed=0xa06e3586
length= 32 megabytes (2^25 bytes), time= 3.0 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-4,T)                  R=+765.7  p =  1.7e-334   FAIL !!!!!!!
  BCFN(2+1,13-4,T)                  R=+524.0  p =  6.8e-229   FAIL !!!!!!
  BCFN(2+2,13-5,T)                  R=+413.4  p =  5.0e-162   FAIL !!!!!
  BCFN(2+3,13-5,T)                  R=+566.9  p =  4.3e-222   FAIL !!!!!!
  BCFN(2+4,13-5,T)                  R=+415.2  p =  1.0e-162   FAIL !!!!!
  BCFN(2+5,13-6,T)                  R=+389.9  p =  5.8e-134   FAIL !!!!!
  BCFN(2+6,13-6,T)                  R=+430.2  p =  8.9e-148   FAIL !!!!!
  BCFN(2+7,13-7,T)                  R=+544.9  p =  1.6e-164   FAIL !!!!!
  BCFN(2+8,13-8,T)                  R=+325.1  p =  1.9e-83    FAIL !!!!
  BCFN(2+9,13-8,T)                  R=+297.7  p =  1.7e-76    FAIL !!!!
  BCFN(2+10,13-9,T)                 R=+360.5  p =  3.9e-82    FAIL !!!!
  BCFN(2+11,13-9,T)                 R=+366.1  p =  2.2e-83    FAIL !!!!
  DC6-9x1Bytes-1                    R=+33591  p = 0           FAIL !!!!!!!!
  Gap-16:A                          R=+26160  p = 0           FAIL !!!!!!!!
  Gap-16:B                          R=+23825  p = 0           FAIL !!!!!!!!
  FPF-14+6/16:(0,14-0)              R=+11268  p = 0           FAIL !!!!!!!!
  FPF-14+6/16:(1,14-1)              R= +5130  p =  9e-4547    FAIL !!!!!!!!
  FPF-14+6/16:(2,14-2)              R= +3671  p =  2e-3210    FAIL !!!!!!!!
  FPF-14+6/16:(3,14-2)              R= +3658  p =  7e-3199    FAIL !!!!!!!!
  FPF-14+6/16:(4,14-3)              R= +2779  p =  7e-2436    FAIL !!!!!!!!
  FPF-14+6/16:(5,14-4)              R= +1863  p =  1e-1522    FAIL !!!!!!!!
  FPF-14+6/16:(6,14-5)              R= +1247  p =  2e-1033    FAIL !!!!!!!!
  FPF-14+6/16:(7,14-5)              R= +1382  p =  1e-1145    FAIL !!!!!!!!
  FPF-14+6/16:(8,14-6)              R= +1129  p =  9.8e-864   FAIL !!!!!!!
  FPF-14+6/16:(9,14-7)              R=+806.2  p =  1.7e-641   FAIL !!!!!!!
  FPF-14+6/16:(10,14-8)             R=+540.7  p =  4.3e-389   FAIL !!!!!!!
  FPF-14+6/16:(11,14-8)             R=+545.1  p =  2.5e-392   FAIL !!!!!!!
  FPF-14+6/16:(12,14-9)             R=+377.5  p =  5.3e-238   FAIL !!!!!!
  FPF-14+6/16:(13,14-10)            R=+181.9  p =  2.5e-97    FAIL !!!!!
  FPF-14+6/16:(14,14-11)            R=+203.5  p =  1.6e-89    FAIL !!!!
  FPF-14+6/16:(15,14-11)            R=+112.6  p =  6.3e-50    FAIL !!!!
  FPF-14+6/16:all                   R=+13755  p = 0           FAIL !!!!!!!!
  FPF-14+6/16:all2                  R=+47731771 p = 0           FAIL !!!!!!!!
  FPF-14+6/16:cross                 R=+289.3  p =  5.2e-228   FAIL !!!!!!
  [Low1/8]BCFN(2+0,13-6,T)          R=+706.6  p =  2.0e-242   FAIL !!!!!!
  [Low1/8]BCFN(2+1,13-6,T)          R=+721.6  p =  1.5e-247   FAIL !!!!!!
  [Low1/8]BCFN(2+2,13-6,T)          R=+806.5  p =  1.2e-276   FAIL !!!!!!
  [Low1/8]BCFN(2+3,13-6,T)          R=+665.4  p =  2.6e-228   FAIL !!!!!!
  [Low1/8]BCFN(2+4,13-7,T)          R=+385.8  p =  1.0e-116   FAIL !!!!!
  [Low1/8]BCFN(2+5,13-8,T)          R=+486.7  p =  1.8e-124   FAIL !!!!!
  [Low1/8]BCFN(2+6,13-8,T)          R=+519.9  p =  6.8e-133   FAIL !!!!!
  [Low1/8]BCFN(2+7,13-9,T)          R=+358.6  p =  1.0e-81    FAIL !!!!
  [Low1/8]BCFN(2+8,13-9,T)          R=+447.6  p =  1.0e-101   FAIL !!!!!
  [Low1/8]DC6-9x1Bytes-1            R= +3199  p =  2e-1803    FAIL !!!!!!!!
  [Low1/8]Gap-16:A                  R= +3726  p =  7e-2999    FAIL !!!!!!!!
  [Low1/8]Gap-16:B                  R= +2964  p =  3e-2236    FAIL !!!!!!!!
  [Low1/8]FPF-14+6/16:(0,14-2)      R=+391.2  p =  6.5e-342   FAIL !!!!!!!
  [Low1/8]FPF-14+6/16:(1,14-3)      R=+277.3  p =  7.6e-243   FAIL !!!!!!
  [Low1/8]FPF-14+6/16:(2,14-4)      R=+189.6  p =  7.2e-155   FAIL !!!!!
  [Low1/8]FPF-14+6/16:(3,14-5)      R=+130.4  p =  5.7e-108   FAIL !!!!!
  [Low1/8]FPF-14+6/16:(4,14-5)      R=+134.6  p =  1.9e-111   FAIL !!!!!
  [Low1/8]FPF-14+6/16:(5,14-6)      R= +98.4  p =  2.4e-75    FAIL !!!!
  [Low1/8]FPF-14+6/16:(6,14-7)      R= +75.2  p =  1.0e-59    FAIL !!!!
  [Low1/8]FPF-14+6/16:(7,14-8)      R= +50.8  p =  1.3e-36    FAIL !!!
  [Low1/8]FPF-14+6/16:(8,14-8)      R= +44.4  p =  5.7e-32    FAIL !!!
  [Low1/8]FPF-14+6/16:(9,14-9)      R= +30.4  p =  1.9e-19    FAIL !
  [Low1/8]FPF-14+6/16:(10,14-10)    R= +15.7  p =  6.0e-9   very suspicious
  [Low1/8]FPF-14+6/16:all           R=+568.7  p =  1.2e-511   FAIL !!!!!!!
  [Low1/8]FPF-14+6/16:all2          R=+76806  p = 0           FAIL !!!!!!!!
  [Low1/8]FPF-14+6/16:cross         R= +34.6  p =  5.6e-30    FAIL !!!
  [Low4/32]BCFN(2+0,13-6,T)         R=+249.3  p =  8.0e-86    FAIL !!!!
  [Low4/32]BCFN(2+1,13-6,T)         R=+183.4  p =  2.9e-63    FAIL !!!!
  [Low4/32]BCFN(2+2,13-6,T)         R=+189.0  p =  3.6e-65    FAIL !!!!
  [Low4/32]BCFN(2+3,13-6,T)         R=+193.6  p =  9.8e-67    FAIL !!!!
  [Low4/32]BCFN(2+4,13-7,T)         R=+257.1  p =  5.6e-78    FAIL !!!!
  [Low4/32]BCFN(2+5,13-8,T)         R=+220.6  p =  6.3e-57    FAIL !!!!
  [Low4/32]BCFN(2+6,13-8,T)         R=+225.8  p =  2.9e-58    FAIL !!!!
  [Low4/32]BCFN(2+7,13-9,T)         R=+249.4  p =  3.6e-57    FAIL !!!!
  [Low4/32]BCFN(2+8,13-9,T)         R=+281.0  p =  2.9e-64    FAIL !!!!
  [Low4/32]DC6-9x1Bytes-1           R= +2718  p =  5e-1532    FAIL !!!!!!!!
  [Low4/32]Gap-16:A                 R= +2190  p =  3e-1762    FAIL !!!!!!!!
  [Low4/32]Gap-16:B                 R= +2717  p =  5e-2050    FAIL !!!!!!!!
  [Low4/32]FPF-14+6/16:(0,14-2)     R=+372.0  p =  4.1e-325   FAIL !!!!!!
  [Low4/32]FPF-14+6/16:(1,14-3)     R=+295.5  p =  9.4e-259   FAIL !!!!!!
  [Low4/32]FPF-14+6/16:(2,14-4)     R=+197.3  p =  3.9e-161   FAIL !!!!!
  [Low4/32]FPF-14+6/16:(3,14-5)     R=+123.6  p =  2.7e-102   FAIL !!!!!
  [Low4/32]FPF-14+6/16:(4,14-5)     R=+124.0  p =  1.2e-102   FAIL !!!!!
  [Low4/32]FPF-14+6/16:(5,14-6)     R= +90.8  p =  1.5e-69    FAIL !!!!
  [Low4/32]FPF-14+6/16:(6,14-7)     R= +68.9  p =  1.2e-54    FAIL !!!!
  [Low4/32]FPF-14+6/16:(7,14-8)     R= +66.9  p =  3.2e-48    FAIL !!!
  [Low4/32]FPF-14+6/16:(8,14-8)     R= +49.8  p =  6.6e-36    FAIL !!!
  [Low4/32]FPF-14+6/16:(9,14-9)     R= +36.5  p =  2.9e-23    FAIL !!
  [Low4/32]FPF-14+6/16:(10,14-10)   R= +13.4  p =  1.0e-7   mildly suspicious
  [Low4/32]FPF-14+6/16:(11,14-11)   R= +34.2  p =  9.4e-16    FAIL
  [Low4/32]FPF-14+6/16:(12,14-11)   R= +22.4  p =  1.3e-10  very suspicious
  [Low4/32]FPF-14+6/16:all          R=+563.6  p =  4.4e-507   FAIL !!!!!!!
  [Low4/32]FPF-14+6/16:all2         R=+75468  p = 0           FAIL !!!!!!!!
  [Low4/32]FPF-14+6/16:cross        R= +18.6  p =  2.9e-16    FAIL !
  [Low1/32]BCFN(2+0,13-7,T)         R=+239.6  p =  1.0e-72    FAIL !!!!
  [Low1/32]BCFN(2+1,13-7,T)         R=+153.4  p =  8.9e-47    FAIL !!!
  [Low1/32]BCFN(2+2,13-8,T)         R=+124.4  p =  1.6e-32    FAIL !!!
  [Low1/32]BCFN(2+3,13-8,T)         R= +72.9  p =  1.9e-19    FAIL !
  [Low1/32]BCFN(2+4,13-8,T)         R= +92.1  p =  2.5e-24    FAIL !!
  [Low1/32]BCFN(2+5,13-9,T)         R=+103.7  p =  2.0e-24    FAIL !!
  [Low1/32]BCFN(2+6,13-9,T)         R=+145.0  p =  1.0e-33    FAIL !!!
  [Low1/32]DC6-9x1Bytes-1           R=+453.3  p =  1.2e-261   FAIL !!!!!!
  [Low1/32]Gap-16:A                 R=+393.3  p =  6.7e-319   FAIL !!!!!!
  [Low1/32]Gap-16:B                 R=+321.4  p =  1.6e-244   FAIL !!!!!!
  [Low1/32]FPF-14+6/16:(0,14-4)     R= +32.4  p =  2.2e-26    FAIL !!
  [Low1/32]FPF-14+6/16:(1,14-5)     R= +21.5  p =  1.0e-17    FAIL !
  [Low1/32]FPF-14+6/16:(2,14-5)     R= +17.7  p =  1.6e-14    FAIL
  [Low1/32]FPF-14+6/16:(3,14-6)     R= +17.5  p =  1.9e-13    FAIL
  [Low1/32]FPF-14+6/16:(4,14-7)     R= +14.6  p =  2.1e-11   VERY SUSPICIOUS
  [Low1/32]FPF-14+6/16:(5,14-8)     R= +14.0  p =  4.0e-10  very suspicious
  [Low1/32]FPF-14+6/16:(6,14-8)     R= +11.0  p =  6.2e-8   suspicious
  [Low1/32]FPF-14+6/16:all          R= +50.7  p =  1.1e-42    FAIL !!!
  [Low1/32]FPF-14+6/16:all2         R=+534.1  p =  5.8e-165   FAIL !!!!!
  [Low1/32]FPF-14+6/16:cross        R=  +4.2  p =  1.0e-3   unusual
  ...and 22 test result(s) without anomalies

Bez konwertera mniej faili, ale też dużo. Faili jest więcej niż na moim własnym generatorze.

Ale uruchomienie samego programu z konwerterem lub bez powoduje, że nie wyświetla się nic, tylko migający kursor, tak jakby coś było liczone. Nie wyświetla się nawet:

RNG_test using PractRand version 0.93
RNG = RNG_stdin, seed = 0x684ea43b
test set = normal, folding = standard(unknown format)

co chyba powinno się wyświetlić, jeśli program zacząłby testy. Także znów niewiele tego rozumiem. Jeśli już oblewa, powinien oblać zarówno plik jak i program. Jeśli nie oblewa, dlaczego plik oblał? Dlaczego nie ma żadnej informacji, że test chociażby się uruchomił? Czy Tobie wyświetla się jakiś komunikat, zanim generator po jakimś czasie obleje testy?

On Sunday, August 22, 2021 at 11:28:24 PM UTC+2, osobli...@gmail.com wrote:
> Z nowym plikiem i z nowym konwerterem znowu mam pełno faili. Napisałem generator: 
> 
> x=440298129029124338965764381130484736423 
> 
> key1 = 47026247687942121848144207491837523525 
> key2 = 83866140218348733064738400095399246195 
> 
> def LCG(x,key1,key2): 
> x=(x * key1 + key2) & 340282366920938463463374607431768211455 
> x = x >> 96 
> return x 
> 
> Nie wiem, czy stałe są dobrze dobrane, ale chyba powinno być ok. Zaraz go przetestuję.

U mnie generator tego typu przeszedł  kilkugodzinne testy:

x = 1;
A = 79908886691;
B = 8143076871913;
x = x * A + B;
return x >> 123;

Uwaga, tylko 5 bitów jest pseudo losowych. Początkowych 500 bitów odrzucałem.

Pozdrawiam

On Monday, August 23, 2021 at 12:29:36 AM UTC+2, osobli...@gmail.com wrote:
> Plik po komendzie: 
> 
> cat LCGtest.data | ./konwerter1.exe | ./RNG_test stdin 
> 
> Daje znów pełno faili:
> RNG_test using PractRand version 0.93
> RNG = RNG_stdin, seed = 0xa06e3586
> test set = normal, folding = standard(unknown format)
> rng=RNG_stdin, seed=0xa06e3586 
> length= 32 megabytes (2^25 bytes), time= 3.0 seconds
> Test Name Raw Processed Evaluation
> BCFN(2+0,13-4,T) R=+765.7 p = 1.7e-334 FAIL !!!!!!! 
> BCFN(2+1,13-4,T) R=+524.0 p = 6.8e-229 FAIL !!!!!! 
> BCFN(2+2,13-5,T) R=+413.4 p = 5.0e-162 FAIL !!!!! 
> BCFN(2+3,13-5,T) R=+566.9 p = 4.3e-222 FAIL !!!!!! 
> BCFN(2+4,13-5,T) R=+415.2 p = 1.0e-162 FAIL !!!!! 
> BCFN(2+5,13-6,T) R=+389.9 p = 5.8e-134 FAIL !!!!! 
> BCFN(2+6,13-6,T) R=+430.2 p = 8.9e-148 FAIL !!!!! 
> BCFN(2+7,13-7,T) R=+544.9 p = 1.6e-164 FAIL !!!!! 
> BCFN(2+8,13-8,T) R=+325.1 p = 1.9e-83 FAIL !!!! 
> BCFN(2+9,13-8,T) R=+297.7 p = 1.7e-76 FAIL !!!! 
> BCFN(2+10,13-9,T) R=+360.5 p = 3.9e-82 FAIL !!!! 
> BCFN(2+11,13-9,T) R=+366.1 p = 2.2e-83 FAIL !!!! 
> DC6-9x1Bytes-1 R=+33591 p = 0 FAIL !!!!!!!! 
> Gap-16:A R=+26160 p = 0 FAIL !!!!!!!! 
> Gap-16:B R=+23825 p = 0 FAIL !!!!!!!! 
> FPF-14+6/16:(0,14-0) R=+11268 p = 0 FAIL !!!!!!!! 
> FPF-14+6/16:(1,14-1) R= +5130 p = 9e-4547 FAIL !!!!!!!! 
> FPF-14+6/16:(2,14-2) R= +3671 p = 2e-3210 FAIL !!!!!!!! 
> FPF-14+6/16:(3,14-2) R= +3658 p = 7e-3199 FAIL !!!!!!!! 
> FPF-14+6/16:(4,14-3) R= +2779 p = 7e-2436 FAIL !!!!!!!! 
> FPF-14+6/16:(5,14-4) R= +1863 p = 1e-1522 FAIL !!!!!!!! 
> FPF-14+6/16:(6,14-5) R= +1247 p = 2e-1033 FAIL !!!!!!!! 
> FPF-14+6/16:(7,14-5) R= +1382 p = 1e-1145 FAIL !!!!!!!! 
> FPF-14+6/16:(8,14-6) R= +1129 p = 9.8e-864 FAIL !!!!!!! 
> FPF-14+6/16:(9,14-7) R=+806.2 p = 1.7e-641 FAIL !!!!!!! 
> FPF-14+6/16:(10,14-8) R=+540.7 p = 4.3e-389 FAIL !!!!!!! 
> FPF-14+6/16:(11,14-8) R=+545.1 p = 2.5e-392 FAIL !!!!!!! 
> FPF-14+6/16:(12,14-9) R=+377.5 p = 5.3e-238 FAIL !!!!!! 
> FPF-14+6/16:(13,14-10) R=+181.9 p = 2.5e-97 FAIL !!!!! 
> FPF-14+6/16:(14,14-11) R=+203.5 p = 1.6e-89 FAIL !!!! 
> FPF-14+6/16:(15,14-11) R=+112.6 p = 6.3e-50 FAIL !!!! 
> FPF-14+6/16:all R=+13755 p = 0 FAIL !!!!!!!! 
> FPF-14+6/16:all2 R=+47731771 p = 0 FAIL !!!!!!!! 
> FPF-14+6/16:cross R=+289.3 p = 5.2e-228 FAIL !!!!!! 
> [Low1/8]BCFN(2+0,13-6,T) R=+706.6 p = 2.0e-242 FAIL !!!!!! 
> [Low1/8]BCFN(2+1,13-6,T) R=+721.6 p = 1.5e-247 FAIL !!!!!! 
> [Low1/8]BCFN(2+2,13-6,T) R=+806.5 p = 1.2e-276 FAIL !!!!!! 
> [Low1/8]BCFN(2+3,13-6,T) R=+665.4 p = 2.6e-228 FAIL !!!!!! 
> [Low1/8]BCFN(2+4,13-7,T) R=+385.8 p = 1.0e-116 FAIL !!!!! 
> [Low1/8]BCFN(2+5,13-8,T) R=+486.7 p = 1.8e-124 FAIL !!!!! 
> [Low1/8]BCFN(2+6,13-8,T) R=+519.9 p = 6.8e-133 FAIL !!!!! 
> [Low1/8]BCFN(2+7,13-9,T) R=+358.6 p = 1.0e-81 FAIL !!!! 
> [Low1/8]BCFN(2+8,13-9,T) R=+447.6 p = 1.0e-101 FAIL !!!!! 
> [Low1/8]DC6-9x1Bytes-1 R= +3199 p = 2e-1803 FAIL !!!!!!!! 
> [Low1/8]Gap-16:A R= +3726 p = 7e-2999 FAIL !!!!!!!! 
> [Low1/8]Gap-16:B R= +2964 p = 3e-2236 FAIL !!!!!!!! 
> [Low1/8]FPF-14+6/16:(0,14-2) R=+391.2 p = 6.5e-342 FAIL !!!!!!! 
> [Low1/8]FPF-14+6/16:(1,14-3) R=+277.3 p = 7.6e-243 FAIL !!!!!! 
> [Low1/8]FPF-14+6/16:(2,14-4) R=+189.6 p = 7.2e-155 FAIL !!!!! 
> [Low1/8]FPF-14+6/16:(3,14-5) R=+130.4 p = 5.7e-108 FAIL !!!!! 
> [Low1/8]FPF-14+6/16:(4,14-5) R=+134.6 p = 1.9e-111 FAIL !!!!! 
> [Low1/8]FPF-14+6/16:(5,14-6) R= +98.4 p = 2.4e-75 FAIL !!!! 
> [Low1/8]FPF-14+6/16:(6,14-7) R= +75.2 p = 1.0e-59 FAIL !!!! 
> [Low1/8]FPF-14+6/16:(7,14-8) R= +50.8 p = 1.3e-36 FAIL !!! 
> [Low1/8]FPF-14+6/16:(8,14-8) R= +44.4 p = 5.7e-32 FAIL !!! 
> [Low1/8]FPF-14+6/16:(9,14-9) R= +30.4 p = 1.9e-19 FAIL ! 
> [Low1/8]FPF-14+6/16:(10,14-10) R= +15.7 p = 6.0e-9 very suspicious 
> [Low1/8]FPF-14+6/16:all R=+568.7 p = 1.2e-511 FAIL !!!!!!! 
> [Low1/8]FPF-14+6/16:all2 R=+76806 p = 0 FAIL !!!!!!!! 
> [Low1/8]FPF-14+6/16:cross R= +34.6 p = 5.6e-30 FAIL !!! 
> [Low4/32]BCFN(2+0,13-6,T) R=+249.3 p = 8.0e-86 FAIL !!!! 
> [Low4/32]BCFN(2+1,13-6,T) R=+183.4 p = 2.9e-63 FAIL !!!! 
> [Low4/32]BCFN(2+2,13-6,T) R=+189.0 p = 3.6e-65 FAIL !!!! 
> [Low4/32]BCFN(2+3,13-6,T) R=+193.6 p = 9.8e-67 FAIL !!!! 
> [Low4/32]BCFN(2+4,13-7,T) R=+257.1 p = 5.6e-78 FAIL !!!! 
> [Low4/32]BCFN(2+5,13-8,T) R=+220.6 p = 6.3e-57 FAIL !!!! 
> [Low4/32]BCFN(2+6,13-8,T) R=+225.8 p = 2.9e-58 FAIL !!!! 
> [Low4/32]BCFN(2+7,13-9,T) R=+249.4 p = 3.6e-57 FAIL !!!! 
> [Low4/32]BCFN(2+8,13-9,T) R=+281.0 p = 2.9e-64 FAIL !!!! 
> [Low4/32]DC6-9x1Bytes-1 R= +2718 p = 5e-1532 FAIL !!!!!!!! 
> [Low4/32]Gap-16:A R= +2190 p = 3e-1762 FAIL !!!!!!!! 
> [Low4/32]Gap-16:B R= +2717 p = 5e-2050 FAIL !!!!!!!! 
> [Low4/32]FPF-14+6/16:(0,14-2) R=+372.0 p = 4.1e-325 FAIL !!!!!! 
> [Low4/32]FPF-14+6/16:(1,14-3) R=+295.5 p = 9.4e-259 FAIL !!!!!! 
> [Low4/32]FPF-14+6/16:(2,14-4) R=+197.3 p = 3.9e-161 FAIL !!!!! 
> [Low4/32]FPF-14+6/16:(3,14-5) R=+123.6 p = 2.7e-102 FAIL !!!!! 
> [Low4/32]FPF-14+6/16:(4,14-5) R=+124.0 p = 1.2e-102 FAIL !!!!! 
> [Low4/32]FPF-14+6/16:(5,14-6) R= +90.8 p = 1.5e-69 FAIL !!!! 
> [Low4/32]FPF-14+6/16:(6,14-7) R= +68.9 p = 1.2e-54 FAIL !!!! 
> [Low4/32]FPF-14+6/16:(7,14-8) R= +66.9 p = 3.2e-48 FAIL !!! 
> [Low4/32]FPF-14+6/16:(8,14-8) R= +49.8 p = 6.6e-36 FAIL !!! 
> [Low4/32]FPF-14+6/16:(9,14-9) R= +36.5 p = 2.9e-23 FAIL !! 
> [Low4/32]FPF-14+6/16:(10,14-10) R= +13.4 p = 1.0e-7 mildly suspicious 
> [Low4/32]FPF-14+6/16:(11,14-11) R= +34.2 p = 9.4e-16 FAIL 
> [Low4/32]FPF-14+6/16:(12,14-11) R= +22.4 p = 1.3e-10 very suspicious 
> [Low4/32]FPF-14+6/16:all R=+563.6 p = 4.4e-507 FAIL !!!!!!! 
> [Low4/32]FPF-14+6/16:all2 R=+75468 p = 0 FAIL !!!!!!!! 
> [Low4/32]FPF-14+6/16:cross R= +18.6 p = 2.9e-16 FAIL ! 
> [Low1/32]BCFN(2+0,13-7,T) R=+239.6 p = 1.0e-72 FAIL !!!! 
> [Low1/32]BCFN(2+1,13-7,T) R=+153.4 p = 8.9e-47 FAIL !!! 
> [Low1/32]BCFN(2+2,13-8,T) R=+124.4 p = 1.6e-32 FAIL !!! 
> [Low1/32]BCFN(2+3,13-8,T) R= +72.9 p = 1.9e-19 FAIL ! 
> [Low1/32]BCFN(2+4,13-8,T) R= +92.1 p = 2.5e-24 FAIL !! 
> [Low1/32]BCFN(2+5,13-9,T) R=+103.7 p = 2.0e-24 FAIL !! 
> [Low1/32]BCFN(2+6,13-9,T) R=+145.0 p = 1.0e-33 FAIL !!! 
> [Low1/32]DC6-9x1Bytes-1 R=+453.3 p = 1.2e-261 FAIL !!!!!! 
> [Low1/32]Gap-16:A R=+393.3 p = 6.7e-319 FAIL !!!!!! 
> [Low1/32]Gap-16:B R=+321.4 p = 1.6e-244 FAIL !!!!!! 
> [Low1/32]FPF-14+6/16:(0,14-4) R= +32.4 p = 2.2e-26 FAIL !! 
> [Low1/32]FPF-14+6/16:(1,14-5) R= +21.5 p = 1.0e-17 FAIL ! 
> [Low1/32]FPF-14+6/16:(2,14-5) R= +17.7 p = 1.6e-14 FAIL 
> [Low1/32]FPF-14+6/16:(3,14-6) R= +17.5 p = 1.9e-13 FAIL 
> [Low1/32]FPF-14+6/16:(4,14-7) R= +14.6 p = 2.1e-11 VERY SUSPICIOUS 
> [Low1/32]FPF-14+6/16:(5,14-8) R= +14.0 p = 4.0e-10 very suspicious 
> [Low1/32]FPF-14+6/16:(6,14-8) R= +11.0 p = 6.2e-8 suspicious 
> [Low1/32]FPF-14+6/16:all R= +50.7 p = 1.1e-42 FAIL !!! 
> [Low1/32]FPF-14+6/16:all2 R=+534.1 p = 5.8e-165 FAIL !!!!! 
> [Low1/32]FPF-14+6/16:cross R= +4.2 p = 1.0e-3 unusual 
> ...and 22 test result(s) without anomalies 
> 
> Bez konwertera mniej faili, ale też dużo. Faili jest więcej niż na moim własnym generatorze. 
> 
> Ale uruchomienie samego programu z konwerterem lub bez powoduje, że nie wyświetla się nic, tylko migający kursor, tak jakby coś było liczone. Nie wyświetla się nawet:
> RNG_test using PractRand version 0.93
> RNG = RNG_stdin, seed = 0x684ea43b
> test set = normal, folding = standard(unknown format)
> co chyba powinno się wyświetlić, jeśli program zacząłby testy. Także znów niewiele tego rozumiem. Jeśli już oblewa, powinien oblać zarówno plik jak i program. Jeśli nie oblewa, dlaczego plik oblał? Dlaczego nie ma żadnej informacji, że test chociażby się uruchomił? Czy Tobie wyświetla się jakiś komunikat, zanim generator po jakimś czasie obleje testy?

Nie czekałem aż obleje testy. Poprzednio po 2h zakończyłem przy pomocy Ctrl+C. Teraz po 120s 
zakończyłem. U mnie ekran wygląda tak:

./SimpPRNG 1 | ../../01ToBin/release/01ToBin | ../../PractRand/RNG_test stdin
RNG_test using PractRand version 0.94
RNG = RNG_stdin, seed = unknown
test set = core, folding = standard(unknown format)

rng=RNG_stdin, seed=unknown
length= 8 megabytes (2^23 bytes), time= 2.2 seconds
  no anomalies in 135 test result(s)

rng=RNG_stdin, seed=unknown
length= 16 megabytes (2^24 bytes), time= 4.2 seconds
  no anomalies in 151 test result(s)

rng=RNG_stdin, seed=unknown
length= 32 megabytes (2^25 bytes), time= 8.5 seconds
  no anomalies in 167 test result(s)

rng=RNG_stdin, seed=unknown
length= 64 megabytes (2^26 bytes), time= 14.1 seconds
  no anomalies in 179 test result(s)

rng=RNG_stdin, seed=unknown
length= 128 megabytes (2^27 bytes), time= 22.1 seconds
  no anomalies in 196 test result(s)

rng=RNG_stdin, seed=unknown
length= 256 megabytes (2^28 bytes), time= 38.8 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/32]BCFN(2+2,13-6,T)         R= +10.4  p =  5.5e-4   unusual          
  ...and 212 test result(s) without anomalies

rng=RNG_stdin, seed=unknown
length= 512 megabytes (2^29 bytes), time= 69.9 seconds
  no anomalies in 229 test result(s)

rng=RNG_stdin, seed=unknown
length= 1 gigabyte (2^30 bytes), time= 129 seconds
  no anomalies in 248 test result(s)

^C

Wszystko bez statystycznych anomalii, choć jeden test niezwykły:
[Low1/32]BCFN(2+2,13-6,T)         R= +10.4  p =  5.5e-4   unusual     


Pozdrawiam

poniedziałek, 23 sierpnia 2021 o 00:58:55 UTC+2 M.M. napisał(a):
> On Sunday, August 22, 2021 at 11:28:24 PM UTC+2, osobli...@gmail.com wrote: 
> > Z nowym plikiem i z nowym konwerterem znowu mam pełno faili. Napisałem generator: 
> > 
> > x=440298129029124338965764381130484736423 
> > 
> > key1 = 47026247687942121848144207491837523525 
> > key2 = 83866140218348733064738400095399246195 
> > 
> > def LCG(x,key1,key2): 
> > x=(x * key1 + key2) & 340282366920938463463374607431768211455 
> > x = x >> 96 
> > return x 
> > 
> > Nie wiem, czy stałe są dobrze dobrane, ale chyba powinno być ok. Zaraz go przetestuję.
> U mnie generator tego typu przeszedł kilkugodzinne testy: 
> 
> x = 1; 
> A = 79908886691; 
> B = 8143076871913; 
> x = x * A + B; 
> return x >> 123; 
> 
> Uwaga, tylko 5 bitów jest pseudo losowych. Początkowych 500 bitów odrzucałem. 
> 
> Pozdrawiam

Rozumiem, że liczysz x = x * A + B mod 2^128, a jako nowe wejście traktujesz x, a nie tylko 5 bitów, czyli x >> 123? Taki generator radzi sobie u mnie lepiej niż mój autorski generator:

RNG_test using PractRand version 0.93
RNG = RNG_stdin, seed = 0x7f77051e
test set = normal, folding = standard(unknown format)

rng=RNG_stdin, seed=0x7f77051e
length= 2 megabytes (2^21 bytes), time= 3.2 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+3,13-7,T)                  R= +14.8  p =  4.4e-5   mildly suspicious
  DC6-9x1Bytes-1                    R= +11.7  p =  1.5e-6   very suspicious
  Gap-16:A                          R= +16.4  p =  9.7e-13    FAIL
  Gap-16:B                          R= +66.6  p =  8.0e-48    FAIL !!!!
  FPF-14+6/16:(0,14-3)              R=+371.6  p =  1.7e-325   FAIL !!!!!!
  FPF-14+6/16:all                   R=+249.4  p =  1.0e-220   FAIL !!!!!!
  FPF-14+6/16:all2                  R=+36026  p = 0           FAIL !!!!!!!!
  [Low1/8]BCFN(2+0,13-8,T)          R= +13.6  p =  2.1e-4   mildly suspicious
  [Low1/8]BCFN(2+2,13-9,T)          R= +17.3  p =  5.3e-5   mildly suspicious
  [Low1/8]BCFN(2+3,13-9,T)          R= +22.8  p =  3.1e-6   suspicious
  [Low1/8]BCFN(2+4,13-9,T)          R= +18.8  p =  2.4e-5   mildly suspicious
  [Low4/32]BCFN(2+0,13-8,T)         R= +10.0  p =  1.8e-3   unusual
  [Low4/32]BCFN(2+2,13-9,T)         R= +13.1  p =  4.7e-4   unusual
  ...and 75 test result(s) without anomalies

Traceback (most recent call last):
  File "LCGkeyed.py", line 27, in <module>
    print(binary, end='')
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe

Ale oblewa zaledwie po 2 MB. Czyli znów zupełnie inaczej niż u Ciebie. Bez konwertera oblewa standardowo bardzo wiele testów, z konwerterem jest lepiej, ale nadal inaczej, niż u Ciebie. Nie ucinałem pierwszych bitów. Podam kilka pierwszych wyników:

0000000000000001111110101001000001101001010010011111001011000111110000110000101110100011101100111011101010101010000011011000010101010011000011101001101111011100010001000111100000010100001
0001100111000001011101010010011001111001001100010000011110010110111000010100110011100100011010110000110011111110001111101100100110110000101111001000100010000110000001110100101110010100110
1010001111010110101001010110011001110100101000001011010011010010010100001100001111010110111001011101010011101101100100101000000001111101110000011111000010110111110010101101100010001001110
1111000001110010011010001101111111000001111101011100100000110110110011010001011001001100101110111111010001110110110010111011011000010001111101000011001000100000101101011111101101101111100
0000110111010011101010010010000101000111110000110011111001110010101101010111101000110100110000001101110000001011001010011000010011001110011101110001100100111110100111011001101001100100110
0100010110100010110111111010010000101101111010111001011111110001110110101010101111011000010001001110100100001110001011011110011001010000010011011011001010001000111101110010010100100000001
0110010111010001110100100111110010000000001101100110110110011100100001101110010101101011001001101000000101001110010111011100011000111011101001100111101110111000001100100010010011111001101
1101110000110011010101101101100101000100000111001000010101001000001011101010110011001001110111011000111000000010000000011100000111010000101100110010111100010100011101000000100100110010111
0100001110110111111000001111000110001001011101110010001101110011100111111000000100011010000011010101100100111011101000100010110001111111110100111111100010110010011101111011001000100001110
1111100100011000110000100100001100000000010111001001011110101001111000010011010111110010110111111001010011001011001000011010101100000010010110001000000010011110100000101111111010100100111
1100101010111011110101100100111010101010011000101110101000100110010100110000011000111010111100100010111111001001011001100111000001011111011111110111101011111010000101000110111110010001000
1100111110010000101011111011010010001101011001110101100111111011100100000110000000110111111101100100010010101111110010100101101111110101110011111100001001000111100100000000101111011111011
1000011111010001010111011010011001111000111110110010010001111010111111110001110000000101001011010100000000110101011100001011001010100010110101101111000000011000110111010010000110110000010
0011110111001101111001111111100011011001010010111000100000111100100001011111001101111011011000010100111100000101001000111110001010100001111110111111100011100101001011111010101011110101101
1111110001101001001001100000110011001000111011111111100100011010110000010011010001111010001111100001111110101100010100111000110011101100110100011100100000001101110111011111111101101100000
0010100110110011110111000011010011101110000101111101011000010000111010010001000001000110001001010000000000001011100010000100001000101011111111110001110100110111010111110101000000001100111
0101100111010011000010000101010101000011001010001001110110100011110100110100101001010110111011000111101001001001001111011110001000101010011001101000000011010001100010001111001110000100101
0010110110001101011010011111001100010011001100001001000010000011000110111011001110101110010001110001001010111110011001110011011101110110101010010001110000110101110100011011010111010010111
1111110010001110011000000101101010001010001000001110111111111111010110010001010100110011011110010000011110110001011011010010110000000011111001100001110001011011101111100100001011010010010
1100010101111110000101111000011010001000011110100111010101000001101000010010010100100011110101010101000111111010001011010000000101011100111110010101011011100001001011011001011101010111111
1111100111011001000011000010101010101000100110000110110011010101000001011110010110101101011110101111110101101011011001010100110101000000010101000010101110101110101000101111010001000000100
1010000100000111110000001110100110110111011111110011011110101101110010001100011001100001001110010101010111011010111010001110010011101101011010001110010001000000111010101100001000110011001
0011000100000010101011011101111010110100111011111000000110101010100110011100011110010010111100111001101000000000001111010101100000001000011100010010000111111111001101001010011101101011000
0101011101001100111100111100010000001001001010011110110000000000100010100100010011000111010100110100100110101101011100000110100111100011001000101100111011100000001000110111101100010100101
1100101000100101101001011000101101110111010111000111101011111011100011001010110000011001110101100000010111001001101001001110110010011001010011111001111101101111001110101111111010010011010
1100110101001100100111100101010111100100100010000000100010001010100111000100111000100101010010101111101100100000001111001001100000010110111001001101101110001011000000000111000101101001001
101110110010001011110101110000111110011000110101011101001100101100100011000010111000110001011001100100101101000100100000111110101011111010

Czy testujesz to samo?

Właściwie to mój generator oblewa po 16 MB:

length= 16 megabytes (2^24 bytes), time= 2.1 seconds

A ten LCG oblewa po 2 MB:

length= 2 megabytes (2^21 bytes), time= 3.3 seconds

Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów.

On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote:
> Właściwie to mój generator oblewa po 16 MB: 
> 
> length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> 
> A ten LCG oblewa po 2 MB: 
> 
> length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> 
> Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów.

Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak
u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle
istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe.

Moje początkowe 1000 bitów wygląda tak:
./SimpPRNG 1 1000
1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101

Wyświetlam z tych 5 bitów począwszy od najmłodszego:

https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp
type_out v = r();
for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) {
                buff[j] = '0' + (v & 1);
                v >>= 1;
            }

Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego.

Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
(np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań.

Pozdrawiam

poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a):
> On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > Właściwie to mój generator oblewa po 16 MB: 
> > 
> > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > 
> > A ten LCG oblewa po 2 MB: 
> > 
> > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > 
> > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów.
> Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> 
> Moje początkowe 1000 bitów wygląda tak: 
> ./SimpPRNG 1 1000 
> 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> 
> Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> 
> https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> type_out v = r(); 
> for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> buff[j] = '0' + (v & 1); 
> v >>= 1; 
> } 
> 
> Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> 
> Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> 
> Pozdrawiam

Mam inne wyniki. Oto wyniki w formacie dziesiętnym:

x = 1

x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604

8222985758604 >> 123  = 0

x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277

657089637254136791211277 >> 123 = 0

x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320

52507301369171109219924401511286320 >> 123 = 0

x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801

333442790507095493699328894974793383801 >> 123 = 31

x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980

225174366013576153541971350915313012980 >> 123 = 21

Czyli uzyskuję: 

0
0
0
31
21

I tak dalej. Jak mogą tu wychodzić inne wyniki?

On Monday, August 23, 2021 at 2:31:39 PM UTC+2, osobli...@gmail.com wrote:
> poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a): 
> > On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > > Właściwie to mój generator oblewa po 16 MB: 
> > > 
> > > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > > 
> > > A ten LCG oblewa po 2 MB: 
> > > 
> > > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > > 
> > > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów. 
> > Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> > początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> > u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> > istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> > 
> > Moje początkowe 1000 bitów wygląda tak: 
> > ./SimpPRNG 1 1000 
> > 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> > 
> > Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> > 
> > https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> > type_out v = r(); 
> > for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> > buff[j] = '0' + (v & 1); 
> > v >>= 1; 
> > } 
> > 
> > Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> > 
> > Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> > (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> > 
> > Pozdrawiam
> Mam inne wyniki. Oto wyniki w formacie dziesiętnym: 
> 
> x = 1 
> 
> x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604 
> 
> 8222985758604 >> 123 = 0 
> 
> x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277 
> 
> 657089637254136791211277 >> 123 = 0 
> 
> x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320 
> 
> 52507301369171109219924401511286320 >> 123 = 0 
> 
> x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801 
> 
> 333442790507095493699328894974793383801 >> 123 = 31 
> 
> x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980 
> 
> 225174366013576153541971350915313012980 >> 123 = 21 
> 
> Czyli uzyskuję: 
> 
> 0 
> 0 
> 0 
> 31 
> 21 
> 
> I tak dalej. Jak mogą tu wychodzić inne wyniki?

Jeśli nie ma błędów, to w tym przypadku nie można uzyskać innych wyników. Jeśli nie pomijam 100 początkowych
wygenerowanych liczb, to mam takie same liczby jak Ty:

0
0
0
31
21
4
3
9
9
7
25
12
15
16
24
11
20
14
25
27

Jeśli pomijam to mam takie:

3
29
24
7
24
11
15
18
22
24
17
7
15
0
28
19
8
27
31
0

W wielu generatorach początkowe liczby uznawane są za kiepskie. Jeśli to jest ważne, pomija 
się wiele początkowych liczb. Ten generator jest tylko do minimalnego sprawdzenia, ale jakoś 
odruchowo pominąłem chociaż 100 początkowych liczb. Generalnie, pobieranie co N-tego bitu to 
najprostsza technika zwiększająca jakość generatora - ale spowalniająca generator.

poniedziałek, 23 sierpnia 2021 o 15:05:27 UTC+2 M.M. napisał(a):
> On Monday, August 23, 2021 at 2:31:39 PM UTC+2, osobli...@gmail.com wrote: 
> > poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a): 
> > > On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > > > Właściwie to mój generator oblewa po 16 MB: 
> > > > 
> > > > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > > > 
> > > > A ten LCG oblewa po 2 MB: 
> > > > 
> > > > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > > > 
> > > > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów. 
> > > Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> > > początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> > > u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> > > istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> > > 
> > > Moje początkowe 1000 bitów wygląda tak: 
> > > ./SimpPRNG 1 1000 
> > > 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> > > 
> > > Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> > > 
> > > https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> > > type_out v = r(); 
> > > for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> > > buff[j] = '0' + (v & 1); 
> > > v >>= 1; 
> > > } 
> > > 
> > > Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> > > 
> > > Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> > > (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> > > 
> > > Pozdrawiam 
> > Mam inne wyniki. Oto wyniki w formacie dziesiętnym: 
> > 
> > x = 1 
> > 
> > x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604 
> > 
> > 8222985758604 >> 123 = 0 
> > 
> > x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277 
> > 
> > 657089637254136791211277 >> 123 = 0 
> > 
> > x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320 
> > 
> > 52507301369171109219924401511286320 >> 123 = 0 
> > 
> > x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801 
> > 
> > 333442790507095493699328894974793383801 >> 123 = 31 
> > 
> > x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980 
> > 
> > 225174366013576153541971350915313012980 >> 123 = 21 
> > 
> > Czyli uzyskuję: 
> > 
> > 0 
> > 0 
> > 0 
> > 31 
> > 21 
> > 
> > I tak dalej. Jak mogą tu wychodzić inne wyniki?
> Jeśli nie ma błędów, to w tym przypadku nie można uzyskać innych wyników. Jeśli nie pomijam 100 początkowych 
> wygenerowanych liczb, to mam takie same liczby jak Ty:
> 0 
> 0 
> 0 
> 31 
> 21
> 4 
> 3 
> 9 
> 9 
> 7 
> 25 
> 12 
> 15 
> 16 
> 24 
> 11 
> 20 
> 14 
> 25 
> 27 
> 
> Jeśli pomijam to mam takie: 
> 
> 3 
> 29 
> 24 
> 7 
> 24 
> 11 
> 15 
> 18 
> 22 
> 24 
> 17 
> 7 
> 15 
> 0 
> 28 
> 19 
> 8 
> 27 
> 31 
> 0 
> 
> W wielu generatorach początkowe liczby uznawane są za kiepskie. Jeśli to jest ważne, pomija 
> się wiele początkowych liczb. Ten generator jest tylko do minimalnego sprawdzenia, ale jakoś 
> odruchowo pominąłem chociaż 100 początkowych liczb. Generalnie, pobieranie co N-tego bitu to 
> najprostsza technika zwiększająca jakość generatora - ale spowalniająca generator.

Wychodzi nam to samo, myślałem, że pominąłem pierwsze 500 bitów, a pominąłeś 100. Oczywiście zdaję sobie sprawę z tych słabości początkowych bitów, sam projektowałem moje generatory, żeby unikać podobnych problemów. Niemniej mam przekonanie, że nawet bez pominięcia pierwszych bitów ten generator też dobrze by sobie poradził.

Ale mniejsza z tym. Mamy te same generatory i ewidentnie problem jest z formatem danych.

On Monday, August 23, 2021 at 3:21:47 PM UTC+2, osobli...@gmail.com wrote:
> poniedziałek, 23 sierpnia 2021 o 15:05:27 UTC+2 M.M. napisał(a): 
> > On Monday, August 23, 2021 at 2:31:39 PM UTC+2, osobli...@gmail.com wrote: 
> > > poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a): 
> > > > On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > > > > Właściwie to mój generator oblewa po 16 MB: 
> > > > > 
> > > > > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > > > > 
> > > > > A ten LCG oblewa po 2 MB: 
> > > > > 
> > > > > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > > > > 
> > > > > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów. 
> > > > Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> > > > początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> > > > u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> > > > istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> > > > 
> > > > Moje początkowe 1000 bitów wygląda tak: 
> > > > ./SimpPRNG 1 1000 
> > > > 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> > > > 
> > > > Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> > > > 
> > > > https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> > > > type_out v = r(); 
> > > > for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> > > > buff[j] = '0' + (v & 1); 
> > > > v >>= 1; 
> > > > } 
> > > > 
> > > > Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> > > > 
> > > > Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> > > > (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> > > > 
> > > > Pozdrawiam 
> > > Mam inne wyniki. Oto wyniki w formacie dziesiętnym: 
> > > 
> > > x = 1 
> > > 
> > > x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604 
> > > 
> > > 8222985758604 >> 123 = 0 
> > > 
> > > x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277 
> > > 
> > > 657089637254136791211277 >> 123 = 0 
> > > 
> > > x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320 
> > > 
> > > 52507301369171109219924401511286320 >> 123 = 0 
> > > 
> > > x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801 
> > > 
> > > 333442790507095493699328894974793383801 >> 123 = 31 
> > > 
> > > x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980 
> > > 
> > > 225174366013576153541971350915313012980 >> 123 = 21 
> > > 
> > > Czyli uzyskuję: 
> > > 
> > > 0 
> > > 0 
> > > 0 
> > > 31 
> > > 21 
> > > 
> > > I tak dalej. Jak mogą tu wychodzić inne wyniki? 
> > Jeśli nie ma błędów, to w tym przypadku nie można uzyskać innych wyników. Jeśli nie pomijam 100 początkowych 
> > wygenerowanych liczb, to mam takie same liczby jak Ty: 
> > 0 
> > 0 
> > 0 
> > 31 
> > 21 
> > 4 
> > 3 
> > 9 
> > 9 
> > 7 
> > 25 
> > 12 
> > 15 
> > 16 
> > 24 
> > 11 
> > 20 
> > 14 
> > 25 
> > 27 
> > 
> > Jeśli pomijam to mam takie: 
> > 
> > 3 
> > 29 
> > 24 
> > 7 
> > 24 
> > 11 
> > 15 
> > 18 
> > 22 
> > 24 
> > 17 
> > 7 
> > 15 
> > 0 
> > 28 
> > 19 
> > 8 
> > 27 
> > 31 
> > 0 
> > 
> > W wielu generatorach początkowe liczby uznawane są za kiepskie. Jeśli to jest ważne, pomija 
> > się wiele początkowych liczb. Ten generator jest tylko do minimalnego sprawdzenia, ale jakoś 
> > odruchowo pominąłem chociaż 100 początkowych liczb. Generalnie, pobieranie co N-tego bitu to 
> > najprostsza technika zwiększająca jakość generatora - ale spowalniająca generator.
> Wychodzi nam to samo, myślałem, że pominąłem pierwsze 500 bitów, a pominąłeś 100. Oczywiście zdaję sobie sprawę z tych słabości początkowych bitów, sam projektowałem moje generatory, żeby unikać podobnych problemów. Niemniej mam przekonanie, że nawet bez pominięcia pierwszych bitów ten generator też dobrze by sobie poradził. 
> 
> Ale mniejsza z tym. Mamy te same generatory i ewidentnie problem jest z formatem danych.

Super, zawęziłeś obszar w którym jest problem :)

Pozdrawiam

poniedziałek, 23 sierpnia 2021 o 15:58:45 UTC+2 M.M. napisał(a):
> On Monday, August 23, 2021 at 3:21:47 PM UTC+2, osobli...@gmail.com wrote:
> > poniedziałek, 23 sierpnia 2021 o 15:05:27 UTC+2 M.M. napisał(a): 
> > > On Monday, August 23, 2021 at 2:31:39 PM UTC+2, osobli...@gmail.com wrote: 
> > > > poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a): 
> > > > > On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > > > > > Właściwie to mój generator oblewa po 16 MB: 
> > > > > > 
> > > > > > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > > > > > 
> > > > > > A ten LCG oblewa po 2 MB: 
> > > > > > 
> > > > > > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > > > > > 
> > > > > > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów. 
> > > > > Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> > > > > początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> > > > > u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> > > > > istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> > > > > 
> > > > > Moje początkowe 1000 bitów wygląda tak: 
> > > > > ./SimpPRNG 1 1000 
> > > > > 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> > > > > 
> > > > > Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> > > > > 
> > > > > https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> > > > > type_out v = r(); 
> > > > > for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> > > > > buff[j] = '0' + (v & 1); 
> > > > > v >>= 1; 
> > > > > } 
> > > > > 
> > > > > Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> > > > > 
> > > > > Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> > > > > (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> > > > > 
> > > > > Pozdrawiam 
> > > > Mam inne wyniki. Oto wyniki w formacie dziesiętnym: 
> > > > 
> > > > x = 1 
> > > > 
> > > > x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604 
> > > > 
> > > > 8222985758604 >> 123 = 0 
> > > > 
> > > > x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277 
> > > > 
> > > > 657089637254136791211277 >> 123 = 0 
> > > > 
> > > > x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320 
> > > > 
> > > > 52507301369171109219924401511286320 >> 123 = 0 
> > > > 
> > > > x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801 
> > > > 
> > > > 333442790507095493699328894974793383801 >> 123 = 31 
> > > > 
> > > > x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980 
> > > > 
> > > > 225174366013576153541971350915313012980 >> 123 = 21 
> > > > 
> > > > Czyli uzyskuję: 
> > > > 
> > > > 0 
> > > > 0 
> > > > 0 
> > > > 31 
> > > > 21 
> > > > 
> > > > I tak dalej. Jak mogą tu wychodzić inne wyniki? 
> > > Jeśli nie ma błędów, to w tym przypadku nie można uzyskać innych wyników. Jeśli nie pomijam 100 początkowych 
> > > wygenerowanych liczb, to mam takie same liczby jak Ty: 
> > > 0 
> > > 0 
> > > 0 
> > > 31 
> > > 21 
> > > 4 
> > > 3 
> > > 9 
> > > 9 
> > > 7 
> > > 25 
> > > 12 
> > > 15 
> > > 16 
> > > 24 
> > > 11 
> > > 20 
> > > 14 
> > > 25 
> > > 27 
> > > 
> > > Jeśli pomijam to mam takie: 
> > > 
> > > 3 
> > > 29 
> > > 24 
> > > 7 
> > > 24 
> > > 11 
> > > 15 
> > > 18 
> > > 22 
> > > 24 
> > > 17 
> > > 7 
> > > 15 
> > > 0 
> > > 28 
> > > 19 
> > > 8 
> > > 27 
> > > 31 
> > > 0 
> > > 
> > > W wielu generatorach początkowe liczby uznawane są za kiepskie. Jeśli to jest ważne, pomija 
> > > się wiele początkowych liczb. Ten generator jest tylko do minimalnego sprawdzenia, ale jakoś 
> > > odruchowo pominąłem chociaż 100 początkowych liczb. Generalnie, pobieranie co N-tego bitu to 
> > > najprostsza technika zwiększająca jakość generatora - ale spowalniająca generator. 
> > Wychodzi nam to samo, myślałem, że pominąłem pierwsze 500 bitów, a pominąłeś 100. Oczywiście zdaję sobie sprawę z tych słabości początkowych bitów, sam projektowałem moje generatory, żeby unikać podobnych problemów. Niemniej mam przekonanie, że nawet bez pominięcia pierwszych bitów ten generator też dobrze by sobie poradził. 
> > 
> > Ale mniejsza z tym. Mamy te same generatory i ewidentnie problem jest z formatem danych.
> Super, zawęziłeś obszar w którym jest problem :) 
> 
> Pozdrawiam

Czy możesz mi powiedzieć co konkretnie robisz z uzyskaną liczbą w formacie dziesiętnym w C++, że zamieniasz ją na format binarny (ten właściwy format, nie stringa binarnego jak w Pythonie). Spróbuję popytać i znaleźć tego odpowiednik w Pythonie.

On Monday, August 23, 2021 at 9:11:14 PM UTC+2, osobli...@gmail.com wrote:
> poniedziałek, 23 sierpnia 2021 o 15:58:45 UTC+2 M.M. napisał(a): 
> > On Monday, August 23, 2021 at 3:21:47 PM UTC+2, osobli...@gmail.com wrote: 
> > > poniedziałek, 23 sierpnia 2021 o 15:05:27 UTC+2 M.M. napisał(a): 
> > > > On Monday, August 23, 2021 at 2:31:39 PM UTC+2, osobli...@gmail.com wrote: 
> > > > > poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a): 
> > > > > > On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > > > > > > Właściwie to mój generator oblewa po 16 MB: 
> > > > > > > 
> > > > > > > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > > > > > > 
> > > > > > > A ten LCG oblewa po 2 MB: 
> > > > > > > 
> > > > > > > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > > > > > > 
> > > > > > > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów. 
> > > > > > Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> > > > > > początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> > > > > > u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> > > > > > istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> > > > > > 
> > > > > > Moje początkowe 1000 bitów wygląda tak: 
> > > > > > ./SimpPRNG 1 1000 
> > > > > > 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> > > > > > 
> > > > > > Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> > > > > > 
> > > > > > https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> > > > > > type_out v = r(); 
> > > > > > for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> > > > > > buff[j] = '0' + (v & 1); 
> > > > > > v >>= 1; 
> > > > > > } 
> > > > > > 
> > > > > > Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> > > > > > 
> > > > > > Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> > > > > > (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> > > > > > 
> > > > > > Pozdrawiam 
> > > > > Mam inne wyniki. Oto wyniki w formacie dziesiętnym: 
> > > > > 
> > > > > x = 1 
> > > > > 
> > > > > x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604 
> > > > > 
> > > > > 8222985758604 >> 123 = 0 
> > > > > 
> > > > > x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277 
> > > > > 
> > > > > 657089637254136791211277 >> 123 = 0 
> > > > > 
> > > > > x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320 
> > > > > 
> > > > > 52507301369171109219924401511286320 >> 123 = 0 
> > > > > 
> > > > > x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801 
> > > > > 
> > > > > 333442790507095493699328894974793383801 >> 123 = 31 
> > > > > 
> > > > > x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980 
> > > > > 
> > > > > 225174366013576153541971350915313012980 >> 123 = 21 
> > > > > 
> > > > > Czyli uzyskuję: 
> > > > > 
> > > > > 0 
> > > > > 0 
> > > > > 0 
> > > > > 31 
> > > > > 21 
> > > > > 
> > > > > I tak dalej. Jak mogą tu wychodzić inne wyniki? 
> > > > Jeśli nie ma błędów, to w tym przypadku nie można uzyskać innych wyników. Jeśli nie pomijam 100 początkowych 
> > > > wygenerowanych liczb, to mam takie same liczby jak Ty: 
> > > > 0 
> > > > 0 
> > > > 0 
> > > > 31 
> > > > 21 
> > > > 4 
> > > > 3 
> > > > 9 
> > > > 9 
> > > > 7 
> > > > 25 
> > > > 12 
> > > > 15 
> > > > 16 
> > > > 24 
> > > > 11 
> > > > 20 
> > > > 14 
> > > > 25 
> > > > 27 
> > > > 
> > > > Jeśli pomijam to mam takie: 
> > > > 
> > > > 3 
> > > > 29 
> > > > 24 
> > > > 7 
> > > > 24 
> > > > 11 
> > > > 15 
> > > > 18 
> > > > 22 
> > > > 24 
> > > > 17 
> > > > 7 
> > > > 15 
> > > > 0 
> > > > 28 
> > > > 19 
> > > > 8 
> > > > 27 
> > > > 31 
> > > > 0 
> > > > 
> > > > W wielu generatorach początkowe liczby uznawane są za kiepskie. Jeśli to jest ważne, pomija 
> > > > się wiele początkowych liczb. Ten generator jest tylko do minimalnego sprawdzenia, ale jakoś 
> > > > odruchowo pominąłem chociaż 100 początkowych liczb. Generalnie, pobieranie co N-tego bitu to 
> > > > najprostsza technika zwiększająca jakość generatora - ale spowalniająca generator. 
> > > Wychodzi nam to samo, myślałem, że pominąłem pierwsze 500 bitów, a pominąłeś 100. Oczywiście zdaję sobie sprawę z tych słabości początkowych bitów, sam projektowałem moje generatory, żeby unikać podobnych problemów. Niemniej mam przekonanie, że nawet bez pominięcia pierwszych bitów ten generator też dobrze by sobie poradził. 
> > > 
> > > Ale mniejsza z tym. Mamy te same generatory i ewidentnie problem jest z formatem danych. 
> > Super, zawęziłeś obszar w którym jest problem :) 
> > 
> > Pozdrawiam
> Czy możesz mi powiedzieć co konkretnie robisz z uzyskaną liczbą w formacie dziesiętnym w C++, że zamieniasz ją na format binarny (ten właściwy format, nie stringa binarnego jak w Pythonie). Spróbuję popytać i znaleźć tego odpowiednik w Pythonie.

Nie wiem jak mogę pomóc i trochę się gubię kiedy jaki dokładnie format masz na myśli :)

Zobacz, poniżej jest format binarny, bo ma same zera i jedynki:
01010111010101001001010
Ale przecież czytasz to jako tekst, więc może to jest format tekstowy? ;-)

Może tego szukasz:

https://stackoverflow.com/questions/908331/how-to-write-binary-data-to-stdout-in-python-3

import sys
sys.stdout.buffer.write(b"some binary data")

Pozdrawiam

poniedziałek, 23 sierpnia 2021 o 22:29:45 UTC+2 M.M. napisał(a):
> On Monday, August 23, 2021 at 9:11:14 PM UTC+2, osobli...@gmail.com wrote:
> > poniedziałek, 23 sierpnia 2021 o 15:58:45 UTC+2 M.M. napisał(a): 
> > > On Monday, August 23, 2021 at 3:21:47 PM UTC+2, osobli...@gmail.com wrote: 
> > > > poniedziałek, 23 sierpnia 2021 o 15:05:27 UTC+2 M.M. napisał(a): 
> > > > > On Monday, August 23, 2021 at 2:31:39 PM UTC+2, osobli...@gmail.com wrote: 
> > > > > > poniedziałek, 23 sierpnia 2021 o 11:18:03 UTC+2 M.M. napisał(a): 
> > > > > > > On Monday, August 23, 2021 at 5:23:14 AM UTC+2, osobli...@gmail.com wrote: 
> > > > > > > > Właściwie to mój generator oblewa po 16 MB: 
> > > > > > > > 
> > > > > > > > length= 16 megabytes (2^24 bytes), time= 2.1 seconds 
> > > > > > > > 
> > > > > > > > A ten LCG oblewa po 2 MB: 
> > > > > > > > 
> > > > > > > > length= 2 megabytes (2^21 bytes), time= 3.3 seconds 
> > > > > > > > 
> > > > > > > > Czyli mój radzi sobie chyba lepiej. O ile to ma w ogóle jakiekolwiek znaczenie, skoro testy prawdopodobnie nie są wykonywane poprawnie. Raczej wróżenie z fusów. 
> > > > > > > Jeśli użyłeś tego samego generatora co ja, tych samych stałych A i B, jeśli zainicjowałeś x=1, jeśli odrzuciłeś sto 
> > > > > > > początkowych wygenerowanych liczb (500 bitów), jeśli bierzesz tylko 5 najstarszych bitów - to powinno być tak samo jak 
> > > > > > > u mnie... chociaż ja mam wersję PractRanda 0.94 a Ty 0.93 - nie wiem czy zostało zmienione coś na tyle 
> > > > > > > istotnego aby wyniki testów były całkiem inne. Raczej w nowszej wersji testy powinny być bardziej surowe. 
> > > > > > > 
> > > > > > > Moje początkowe 1000 bitów wygląda tak: 
> > > > > > > ./SimpPRNG 1 1000 
> > > > > > > 1100010111000111110000011110101111001001011010001110001111001111000000001111100100010110111111100000111111101001001100000110110011001011101000100100110111011111001010111011011101001101100110001001111000101011000001000001110101101001111110111111000001011001011111100010101001010000000101111110000110010011100111101011010111110000100101100110100001110100000110101010001100010000011000111101110001110011111000101101110100110010110011011000001001101100011011011111100101000010110101110111011010111111100001101101011101011011100000100001110010011100010001101100011110011000100010011011001100010100010011110011101001010010000011010101000101111100100101110010011000001000001101101100110101110000101011010011110101101000100010110000000101001111110101110011001110001110110011110011101011101000001001001001100100111110111110110000110010101011011001100010100010111000010010100100100000011101010101001101001011101011110001000111000000000110000000101110000010110100110111011000100010101110000010010011001101000101 
> > > > > > > 
> > > > > > > Wyświetlam z tych 5 bitów począwszy od najmłodszego: 
> > > > > > > 
> > > > > > > https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp 
> > > > > > > type_out v = r(); 
> > > > > > > for( int k=0 ; k<bits && j<BUFF_SIZE && i<size ; k++, j++, i++ ) { 
> > > > > > > buff[j] = '0' + (v & 1); 
> > > > > > > v >>= 1; 
> > > > > > > } 
> > > > > > > 
> > > > > > > Ale na jakość generatora i zaliczenie testów nie powinno wpłynąć wyświetlanie od najstarszego. 
> > > > > > > 
> > > > > > > Początkowe liczby z tego generatora są statystycznie bardzo słabe jeśli inicjuje się małą liczbą 
> > > > > > > (np. jedynką), jest dużo zer na początku, warto odrzucić np. 100 początkowych generowań. 
> > > > > > > 
> > > > > > > Pozdrawiam 
> > > > > > Mam inne wyniki. Oto wyniki w formacie dziesiętnym: 
> > > > > > 
> > > > > > x = 1 
> > > > > > 
> > > > > > x = (x * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 8222985758604 
> > > > > > 
> > > > > > 8222985758604 >> 123 = 0 
> > > > > > 
> > > > > > x = (8222985758604 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 657089637254136791211277 
> > > > > > 
> > > > > > 657089637254136791211277 >> 123 = 0 
> > > > > > 
> > > > > > x = (657089637254136791211277 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 52507301369171109219924401511286320 
> > > > > > 
> > > > > > 52507301369171109219924401511286320 >> 123 = 0 
> > > > > > 
> > > > > > x = (52507301369171109219924401511286320 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 333442790507095493699328894974793383801 
> > > > > > 
> > > > > > 333442790507095493699328894974793383801 >> 123 = 31 
> > > > > > 
> > > > > > x = (333442790507095493699328894974793383801 * 79908886691 + 8143076871913) & 340282366920938463463374607431768211455 = 225174366013576153541971350915313012980 
> > > > > > 
> > > > > > 225174366013576153541971350915313012980 >> 123 = 21 
> > > > > > 
> > > > > > Czyli uzyskuję: 
> > > > > > 
> > > > > > 0 
> > > > > > 0 
> > > > > > 0 
> > > > > > 31 
> > > > > > 21 
> > > > > > 
> > > > > > I tak dalej. Jak mogą tu wychodzić inne wyniki? 
> > > > > Jeśli nie ma błędów, to w tym przypadku nie można uzyskać innych wyników. Jeśli nie pomijam 100 początkowych 
> > > > > wygenerowanych liczb, to mam takie same liczby jak Ty: 
> > > > > 0 
> > > > > 0 
> > > > > 0 
> > > > > 31 
> > > > > 21 
> > > > > 4 
> > > > > 3 
> > > > > 9 
> > > > > 9 
> > > > > 7 
> > > > > 25 
> > > > > 12 
> > > > > 15 
> > > > > 16 
> > > > > 24 
> > > > > 11 
> > > > > 20 
> > > > > 14 
> > > > > 25 
> > > > > 27 
> > > > > 
> > > > > Jeśli pomijam to mam takie: 
> > > > > 
> > > > > 3 
> > > > > 29 
> > > > > 24 
> > > > > 7 
> > > > > 24 
> > > > > 11 
> > > > > 15 
> > > > > 18 
> > > > > 22 
> > > > > 24 
> > > > > 17 
> > > > > 7 
> > > > > 15 
> > > > > 0 
> > > > > 28 
> > > > > 19 
> > > > > 8 
> > > > > 27 
> > > > > 31 
> > > > > 0 
> > > > > 
> > > > > W wielu generatorach początkowe liczby uznawane są za kiepskie. Jeśli to jest ważne, pomija 
> > > > > się wiele początkowych liczb. Ten generator jest tylko do minimalnego sprawdzenia, ale jakoś 
> > > > > odruchowo pominąłem chociaż 100 początkowych liczb. Generalnie, pobieranie co N-tego bitu to 
> > > > > najprostsza technika zwiększająca jakość generatora - ale spowalniająca generator. 
> > > > Wychodzi nam to samo, myślałem, że pominąłem pierwsze 500 bitów, a pominąłeś 100. Oczywiście zdaję sobie sprawę z tych słabości początkowych bitów, sam projektowałem moje generatory, żeby unikać podobnych problemów. Niemniej mam przekonanie, że nawet bez pominięcia pierwszych bitów ten generator też dobrze by sobie poradził. 
> > > > 
> > > > Ale mniejsza z tym. Mamy te same generatory i ewidentnie problem jest z formatem danych. 
> > > Super, zawęziłeś obszar w którym jest problem :) 
> > > 
> > > Pozdrawiam 
> > Czy możesz mi powiedzieć co konkretnie robisz z uzyskaną liczbą w formacie dziesiętnym w C++, że zamieniasz ją na format binarny (ten właściwy format, nie stringa binarnego jak w Pythonie). Spróbuję popytać i znaleźć tego odpowiednik w Pythonie.
> Nie wiem jak mogę pomóc i trochę się gubię kiedy jaki dokładnie format masz na myśli :) 
> 
> Zobacz, poniżej jest format binarny, bo ma same zera i jedynki: 
> 01010111010101001001010 
> Ale przecież czytasz to jako tekst, więc może to jest format tekstowy? ;-) 

Ja sam już nie wiem co to jest. To jest oczywiście format binarny, ale jak się to wypisuje, to są to ostatecznie znaki ASCII. Więc w bitach, to nie będzie ten sam ciąg, pomimo, że to nie jest ostatecznie ciąg bitów, tylko zer i jedynek w ASCII.

> Może tego szukasz: 
> 
> https://stackoverflow.com/questions/908331/how-to-write-binary-data-to-stdout-in-python-3 
> 
> import sys 
> sys.stdout.buffer.write(b"some binary data") 

Dzisiaj to testowałem. Próbowałem:

sys.stdout.buffer.write(b"binary")

gdzie binary to moja liczba zapisana binarnie za pomocą:

split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))]

 binary = struct.pack('qqqq', split[0], split[1], split[2], split[3])

Ale to skutkuje tylko wypisaniem:

binarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinarybinary

Natomiast sys.stdout.buffer.write(binary) nie działa, oblewa testy jak zwykle.

PS Na pewno ładuję do sys.stdout.buffer.write() bajty albo "bytes-like objects", bo, gdy próbuję tam umieścić zwykłe binary, typu binary = 101010101111, to dostaję błąd:

TypeError: a bytes-like object is required, not 'str'

Więc cokolwiek to znaczy, do sys.stdout.buffer.write() trafiają "bytes-like objects".

Widzę jeszcze możliwość problemu z tym jak pociąłem liczby 128-bitowe:

split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))]

binary = struct.pack('qqqq', split[0], split[1], split[2], split[3])

Pociąłem je na liczby 32 bitowe i w strukt.pack użyłem formatu C Type nazwanego 'q', który oznacza long long:

https://docs.python.org/3/library/struct.html

Jeżeli long long może być dłuższy niż to co tam umieszczam, struct.pack może wypełniać resztę np. zerami. Ale long long ma chyba właśnie 32-bity.

On Monday, August 23, 2021 at 11:19:41 PM UTC+2, osobli...@gmail.com wrote:
> Widzę jeszcze możliwość problemu z tym jak pociąłem liczby 128-bitowe:
> split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))] 
> 
> binary = struct.pack('qqqq', split[0], split[1], split[2], split[3])
> Pociąłem je na liczby 32 bitowe i w strukt.pack użyłem formatu C Type nazwanego 'q', który oznacza long long: 
> 
> https://docs.python.org/3/library/struct.html 
> 
> Jeżeli long long może być dłuższy niż to co tam umieszczam, struct.pack może wypełniać resztę np. zerami. Ale long long ma chyba właśnie 32-bity.

Nie wiem, to może tam Ciebie coś zainspiruje:

https://stackoverflow.com/questions/4670350/how-do-i-write-a-long-integer-as-binary-in-python

Pozdrawiam

poniedziałek, 23 sierpnia 2021 o 23:46:50 UTC+2 M.M. napisał(a):
> On Monday, August 23, 2021 at 11:19:41 PM UTC+2, osobli...@gmail.com wrote: 
> > Widzę jeszcze możliwość problemu z tym jak pociąłem liczby 128-bitowe: 
> > split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))] 
> > 
> > binary = struct.pack('qqqq', split[0], split[1], split[2], split[3]) 
> > Pociąłem je na liczby 32 bitowe i w strukt.pack użyłem formatu C Type nazwanego 'q', który oznacza long long: 
> > 
> > https://docs.python.org/3/library/struct.html 
> > 
> > Jeżeli long long może być dłuższy niż to co tam umieszczam, struct.pack może wypełniać resztę np. zerami. Ale long long ma chyba właśnie 32-bity.
> Nie wiem, to może tam Ciebie coś zainspiruje: 
> 
> https://stackoverflow.com/questions/4670350/how-do-i-write-a-long-integer-as-binary-in-python 
> 
> Pozdrawiam

Mam błąd:

"ModuleNotFoundError: No module named 'bitarray'"

którego nie da się rozwiązać. Zainstalowałem bitarray i dalej mam ten problem. Google nie ma to więcej rozwiązań.

Inna metoda z tego wątku:

def binify(x):
    h = hex(x)[2:].rstrip('L')
    return binascii.unhexlify('0'*(32-len(h))+h)

Też nie działa.

To też nie działa:

def to_bytes(num, size):
        x = num if num >= 0 else 256**size + num
        h = hex(x)[2:].rstrip("L")
        return binascii.unhexlify("0"*((2*size)-len(h))+h)

Wyniki, które otrzymuję są podobne do tego, który podano w przykładzie:

\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Oznacza, to, że prawie na pewno konwertuję dane dobrze. Problem jest nadal z przekazaniem tego do PractRand. Nie wiem, czy używam poprawnie:

sys.stdout.buffer.write(binary)

Skoro nie działa, ale z tego co widzę może tam być po prostu zmienna w nawiasach, więc nie powinno być problemu. Standardowy print zarówno ze znakami nowej linii, jak i bez nie działa. Nie sądzę, że tutaj też jest nadal jakiś błąd. Wydaje mi się, że dane są wciąż źle podawane.

Jak podaje dane program:

#include <cstdio>
#include <cstdint>

#include <random>

int main()
{
    freopen(NULL, "wb", stdout);  // Only necessary on Windows, but harmless. 

    std::mt19937 rng(42);

    while (1) {
        uint32_t value = rng();
        fwrite((void*) &value, sizeof(value), 1, stdout);
    }
}

https://www.pcg-random.org/posts/how-to-test-with-practrand.html

I czym to się różni od mojego sposobu?

On Tuesday, August 24, 2021 at 1:43:54 AM UTC+2, osobli...@gmail.com wrote:
> To też nie działa: 
> 
> def to_bytes(num, size): 
> x = num if num >= 0 else 256**size + num
> h = hex(x)[2:].rstrip("L")
> return binascii.unhexlify("0"*((2*size)-len(h))+h) 
> 
> Wyniki, które otrzymuję są podobne do tego, który podano w przykładzie: 
> 
> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' 
> 
> Oznacza, to, że prawie na pewno konwertuję dane dobrze. Problem jest nadal z przekazaniem tego do PractRand. Nie wiem, czy używam poprawnie: 
> 
> sys.stdout.buffer.write(binary) 
> 
> Skoro nie działa, ale z tego co widzę może tam być po prostu zmienna w nawiasach, więc nie powinno być problemu. Standardowy print zarówno ze znakami nowej linii, jak i bez nie działa. Nie sądzę, że tutaj też jest nadal jakiś błąd. Wydaje mi się, że dane są wciąż źle podawane. 
> 
> Jak podaje dane program: 
> 
> #include <cstdio> 
> #include <cstdint> 
> 
> #include <random> 
> 
> int main() 
> { 
> freopen(NULL, "wb", stdout); // Only necessary on Windows, but harmless. 
> 
> std::mt19937 rng(42); 
> 
> while (1) { 
> uint32_t value = rng(); 
> fwrite((void*) &value, sizeof(value), 1, stdout); 
> } 
> } 
> 
> https://www.pcg-random.org/posts/how-to-test-with-practrand.html 
> 
> I czym to się różni od mojego sposobu?

Nie wiem, ale u mnie działa:

cat test.py
import sys
import struct

class SimpPRNG:
  x = 0
  A = 79908886691
  B = 8143076871913

  def __init__( self, seed ):
    self.x = seed
    for i in range(1,100):
      self.g()

  def g(self):
    self.x = (self.x * self.A + self.B) & (2**128-1)
    return self.x >> 123

r = SimpPRNG( 1 )
buf = 0
s   = 0
while True:
  t = r.g()
  for i in range(1,5):
    buf = buf << 1
    buf = buf | (t & 1)
    t = t >> 1
    s = s + 1
    if s == 32:
      sys.stdout.write( struct.pack('I', buf) )
      s = 0
      buf = 0
  

python test.py | ../c/PractRand/RNG_test stdin
RNG_test using PractRand version 0.94
RNG = RNG_stdin, seed = unknown
test set = core, folding = standard(unknown format)

rng=RNG_stdin, seed=unknown
length= 512 kilobytes (2^19 bytes), time= 2.7 seconds
  no anomalies in 84 test result(s)

rng=RNG_stdin, seed=unknown
length= 1 megabyte (2^20 bytes), time= 5.8 seconds
  no anomalies in 94 test result(s)

rng=RNG_stdin, seed=unknown
length= 2 megabytes (2^21 bytes), time= 11.5 seconds
  no anomalies in 109 test result(s)

rng=RNG_stdin, seed=unknown
length= 4 megabytes (2^22 bytes), time= 22.7 seconds
  no anomalies in 124 test result(s)

rng=RNG_stdin, seed=unknown
length= 8 megabytes (2^23 bytes), time= 44.5 seconds
  no anomalies in 135 test result(s)

rng=RNG_stdin, seed=unknown
length= 16 megabytes (2^24 bytes), time= 87.8 seconds
  no anomalies in 151 test result(s)

^CTraceback (most recent call last):
  File "test.py", line 30, in <module>
    t = t >> 1
KeyboardInterrupt

Pozdrawim

wtorek, 24 sierpnia 2021 o 11:46:47 UTC+2 M.M. napisał(a):
> On Tuesday, August 24, 2021 at 1:43:54 AM UTC+2, osobli...@gmail.com wrote: 
> > To też nie działa: 
> > 
> > def to_bytes(num, size): 
> > x = num if num >= 0 else 256**size + num 
> > h = hex(x)[2:].rstrip("L") 
> > return binascii.unhexlify("0"*((2*size)-len(h))+h) 
> > 
> > Wyniki, które otrzymuję są podobne do tego, który podano w przykładzie: 
> > 
> > \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' 
> > 
> > Oznacza, to, że prawie na pewno konwertuję dane dobrze. Problem jest nadal z przekazaniem tego do PractRand. Nie wiem, czy używam poprawnie: 
> > 
> > sys.stdout.buffer.write(binary) 
> > 
> > Skoro nie działa, ale z tego co widzę może tam być po prostu zmienna w nawiasach, więc nie powinno być problemu. Standardowy print zarówno ze znakami nowej linii, jak i bez nie działa. Nie sądzę, że tutaj też jest nadal jakiś błąd. Wydaje mi się, że dane są wciąż źle podawane. 
> > 
> > Jak podaje dane program: 
> > 
> > #include <cstdio> 
> > #include <cstdint> 
> > 
> > #include <random> 
> > 
> > int main() 
> > { 
> > freopen(NULL, "wb", stdout); // Only necessary on Windows, but harmless. 
> > 
> > std::mt19937 rng(42); 
> > 
> > while (1) { 
> > uint32_t value = rng(); 
> > fwrite((void*) &value, sizeof(value), 1, stdout); 
> > } 
> > } 
> > 
> > https://www.pcg-random.org/posts/how-to-test-with-practrand.html 
> > 
> > I czym to się różni od mojego sposobu?
> Nie wiem, ale u mnie działa: 
> 
> cat test.py 
> import sys 
> import struct 
> 
> class SimpPRNG: 
> x = 0
> A = 79908886691 
> B = 8143076871913
> def __init__( self, seed ): 
> self.x = seed 
> for i in range(1,100): 
> self.g() 
> 
> def g(self): 
> self.x = (self.x * self.A + self.B) & (2**128-1) 
> return self.x >> 123 
> 
> r = SimpPRNG( 1 ) 
> buf = 0 
> s = 0 
> while True: 
> t = r.g() 
> for i in range(1,5): 
> buf = buf << 1 
> buf = buf | (t & 1) 
> t = t >> 1 
> s = s + 1 
> if s == 32: 
> sys.stdout.write( struct.pack('I', buf) ) 
> s = 0 
> buf = 0 
> 
> 
> python test.py | ../c/PractRand/RNG_test stdin
> RNG_test using PractRand version 0.94 
> RNG = RNG_stdin, seed = unknown
> test set = core, folding = standard(unknown format) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 512 kilobytes (2^19 bytes), time= 2.7 seconds 
> no anomalies in 84 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 1 megabyte (2^20 bytes), time= 5.8 seconds 
> no anomalies in 94 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 2 megabytes (2^21 bytes), time= 11.5 seconds 
> no anomalies in 109 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 4 megabytes (2^22 bytes), time= 22.7 seconds 
> no anomalies in 124 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 8 megabytes (2^23 bytes), time= 44.5 seconds
> no anomalies in 135 test result(s) 
> 
> rng=RNG_stdin, seed=unknown
> length= 16 megabytes (2^24 bytes), time= 87.8 seconds
> no anomalies in 151 test result(s)
> ^CTraceback (most recent call last): 
> File "test.py", line 30, in <module> 
> t = t >> 1 
> KeyboardInterrupt 
> 
> Pozdrawim

U mnie sys.stdout.write(struct.pack('I', buf)) od razu podświetla się jako błąd. Po uruchomieniu:

TypeError: write() argument must be str, not bytes

Gdy zrobię z argumentu stringa sys.stdout.write(str(struct.pack('I', buf))), to oczywiście oblewa. Trzeba tam jeszcze coś prawdopodobnie dodać, żeby to write działało w trybie binarnym.

Tu chyba jest odpowiedź:

https://stackoverflow.com/questions/21689365/python-3-typeerror-must-be-str-not-bytes-with-sys-stdout-write

Choć jak na razie nic z tego nie działa. sys.stdout.write(string.decode('utf-8')) nie działa.

wtorek, 24 sierpnia 2021 o 16:26:29 UTC+2 osobli...@gmail.com napisał(a):
> Tu chyba jest odpowiedź: 
> 
> https://stackoverflow.com/questions/21689365/python-3-typeerror-must-be-str-not-bytes-with-sys-stdout-write 
> 
> Choć jak na razie nic z tego nie działa. sys.stdout.write(string.decode('utf-8')) nie działa.

Po zrobieniu tego:

split=[(liczba128bit >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))]

binary = struct.pack('LLLL', split[0], split[1], split[2], split[3])

 string=struct.pack('I',split[0])

 sys.stdout.write(string.decode(sys.stdout.encoding))

Mam błąd:

 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbe in position 1: invalid start byte

 Trzeba to chyba zdekodować w czymś innym niż 'utf-8'. Żebym tylko wiedział w czym.

Jest pewien przełom. Napisałem:

split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))]

binary = struct.pack('IIII', split[0], split[1], split[2], split[3])

sys.stdout.buffer.write(binary)

Czyli zmieniłem 'LLLL' , które już testowałem na 'IIII' i otrzymałem:

RNG_test using PractRand version 0.93
RNG = RNG_stdin, seed = 0x974d705a
test set = normal, folding = standard(unknown format)

rng=RNG_stdin, seed=0x974d705a
length= 16 megabytes (2^24 bytes), time= 2.5 seconds
  no anomalies in 119 test result(s)

free(): invalid size
Traceback (most recent call last):
  File "Mojgenerator.py", line 73, in <module>
    sys.stdout.buffer.write(binary)
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe
Aborted (core dumped)

Z jakichś powodów testy zostały zakończone, a powinno się testować zdaje się dalej, aż do czasu, gdy obleje?

On Tuesday, August 24, 2021 at 4:42:57 PM UTC+2, osobli...@gmail.com wrote:
> wtorek, 24 sierpnia 2021 o 16:26:29 UTC+2 osobli...@gmail.com napisał(a): 
> > Tu chyba jest odpowiedź: 
> > 
> > https://stackoverflow.com/questions/21689365/python-3-typeerror-must-be-str-not-bytes-with-sys-stdout-write 
> > 
> > Choć jak na razie nic z tego nie działa. sys.stdout.write(string.decode('utf-8')) nie działa.
> Po zrobieniu tego: 
> 
> split=[(liczba128bit >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))] 
> 
> binary = struct.pack('LLLL', split[0], split[1], split[2], split[3]) 
> 
> string=struct.pack('I',split[0]) 
> 
> sys.stdout.write(string.decode(sys.stdout.encoding)) 
> 
> Mam błąd: 
> 
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbe in position 1: invalid start byte 
> 
> Trzeba to chyba zdekodować w czymś innym niż 'utf-8'. Żebym tylko wiedział w czym.

U mnie struct.pack zadziałało od razu, nic nie konfigurowałem:
sys.stdout.write( struct.pack('I', buf) )

Pozdrawiam

On Tuesday, August 24, 2021 at 5:49:14 PM UTC+2, osobli...@gmail.com wrote:
> Jest pewien przełom. Napisałem: 
> 
> split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))] 
> 
> binary = struct.pack('IIII', split[0], split[1], split[2], split[3]) 
> 
> sys.stdout.buffer.write(binary) 
> 
> Czyli zmieniłem 'LLLL' , które już testowałem na 'IIII' i otrzymałem:
> RNG_test using PractRand version 0.93
> RNG = RNG_stdin, seed = 0x974d705a 
> test set = normal, folding = standard(unknown format) 
> 
> rng=RNG_stdin, seed=0x974d705a 
> length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> no anomalies in 119 test result(s) 
> 
> free(): invalid size
> Traceback (most recent call last):
> File "Mojgenerator.py", line 73, in <module> 
> sys.stdout.buffer.write(binary)
> BrokenPipeError: [Errno 32] Broken pipe 
> Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'> 
> BrokenPipeError: [Errno 32] Broken pipe
> Aborted (core dumped) 
> 
> Z jakichś powodów testy zostały zakończone, a powinno się testować zdaje się dalej, aż do czasu, gdy obleje?

Może spróbuj wersję 0.94.
Pozdrawiam

wtorek, 24 sierpnia 2021 o 18:15:49 UTC+2 M.M. napisał(a):
> On Tuesday, August 24, 2021 at 5:49:14 PM UTC+2, osobli...@gmail.com wrote: 
> > Jest pewien przełom. Napisałem: 
> > 
> > split=[(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))] 
> > 
> > binary = struct.pack('IIII', split[0], split[1], split[2], split[3]) 
> > 
> > sys.stdout.buffer.write(binary) 
> > 
> > Czyli zmieniłem 'LLLL' , które już testowałem na 'IIII' i otrzymałem: 
> > RNG_test using PractRand version 0.93 
> > RNG = RNG_stdin, seed = 0x974d705a 
> > test set = normal, folding = standard(unknown format) 
> > 
> > rng=RNG_stdin, seed=0x974d705a 
> > length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> > no anomalies in 119 test result(s) 
> > 
> > free(): invalid size 
> > Traceback (most recent call last): 
> > File "Mojgenerator.py", line 73, in <module> 
> > sys.stdout.buffer.write(binary) 
> > BrokenPipeError: [Errno 32] Broken pipe 
> > Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'> 
> > BrokenPipeError: [Errno 32] Broken pipe 
> > Aborted (core dumped) 
> > 
> > Z jakichś powodów testy zostały zakończone, a powinno się testować zdaje się dalej, aż do czasu, gdy obleje?
> Może spróbuj wersję 0.94. 
> Pozdrawiam

Jak ją zainstalować? Instrukcje do poprzedniej mam stąd:

https://www.pcg-random.org/posts/how-to-test-with-practrand.html

Działanie samego programu w konsoli również kończy się szybko. Po wypisaniu kilku krzaków, dostaję błąd:

Traceback (most recent call last):
  File "Collatzgenerator01.py", line 63, in <module>
    sys.stdout.buffer.write(binary)
OSError: [Errno 5] Input/output error
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
OSError: [Errno 5] Input/output error

Takiego zatrzymania nie ma w PyCharmie. Co sugeruje, że program stwarza z jakichś powodów problem dla konsoli. Coś z przepełnieniem pamięci, z tego co czytam. Korzystam z konsoli Linuxowej (Ubuntu) na Windowsa. Może tu jest problem. Rozwiązania znalezione w sieci jak na razie nie działają.

To działa:

"run your python scripts with I/O redirection that discards output:

python foo.py >/dev/null 2>&1"

https://stackoverflow.com/questions/38238139/python-prevent-ioerror-errno-5-input-output-error-when-running-without-stdo

To znaczy konsola niczego nie wyświetla i wygląda na to, że program działa. Napisanie:

python3 Mojgenerator.py >/dev/null 2>&1 ? | ./RNG_test stdin

Skutkuje wyświetleniem:

RNG_test using PractRand version 0.93
RNG = RNG_stdin, seed = 0x2d4abc91
test set = normal, folding = standard(unknown format)

I miganiem kursora. Coś więc cały czas działa lub na coś czeka.

Chodzi mi to w cmd i nie wywala błędu, ale nie mogę uruchomić PractRand w cmd:

Mojgenerator.py | RNG_test stdin

Wywala błąd:

'RNG_test' is not recognized as an internal or external command,
operable program or batch file.

W cmder ten sam problem. 'RNG_test' is not recognized as an internal or external command, operable program or batch file.

Także w cmd mój generator chodzi, ale nie działa PractRand, a w konsoli Ubuntu mój generator nie chodzi, ale za to chodzi  PractRand. Genialnie.

Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona.

Mój generator zdaje testy:

RNG_test using PractRand version 0.95
RNG = RNG_stdin, seed = unknown
test set = core, folding = standard(unknown format)

rng=RNG_stdin, seed=unknown
length= 16 megabytes (2^24 bytes), time= 2.5 seconds
  no anomalies in 153 test result(s)

rng=RNG_stdin, seed=unknown
length= 32 megabytes (2^25 bytes), time= 6.5 seconds
  no anomalies in 169 test result(s)

rng=RNG_stdin, seed=unknown
length= 64 megabytes (2^26 bytes), time= 12.9 seconds
  no anomalies in 182 test result(s)

rng=RNG_stdin, seed=unknown
length= 128 megabytes (2^27 bytes), time= 24.3 seconds
  no anomalies in 199 test result(s)

rng=RNG_stdin, seed=unknown
length= 256 megabytes (2^28 bytes), time= 45.5 seconds
  no anomalies in 217 test result(s)

rng=RNG_stdin, seed=unknown
length= 512 megabytes (2^29 bytes), time= 86.5 seconds
  no anomalies in 232 test result(s)

rng=RNG_stdin, seed=unknown
length= 1 gigabyte (2^30 bytes), time= 167 seconds
  no anomalies in 251 test result(s)

rng=RNG_stdin, seed=unknown
length= 2 gigabytes (2^31 bytes), time= 327 seconds
  no anomalies in 269 test result(s)

rng=RNG_stdin, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 645 seconds
  no anomalies in 283 test result(s)

rng=RNG_stdin, seed=unknown
length= 8 gigabytes (2^33 bytes), time= 1283 seconds
  no anomalies in 300 test result(s)

rng=RNG_stdin, seed=unknown
length= 16 gigabytes (2^34 bytes), time= 2557 seconds
  no anomalies in 315 test result(s)

rng=RNG_stdin, seed=unknown
length= 32 gigabytes (2^35 bytes), time= 5096 seconds
  no anomalies in 328 test result(s)

rng=RNG_stdin, seed=unknown
length= 64 gigabytes (2^36 bytes), time= 10170 seconds
  no anomalies in 344 test result(s)

rng=RNG_stdin, seed=unknown
length= 128 gigabytes (2^37 bytes), time= 20316 seconds
  no anomalies in 359 test result(s)

Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek.

On Sunday, August 29, 2021 at 4:29:12 PM UTC+2, osobli...@gmail.com wrote:
> Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona. 
> 
> Mój generator zdaje testy: 
> 
> RNG_test using PractRand version 0.95
> RNG = RNG_stdin, seed = unknown
> test set = core, folding = standard(unknown format) 
> 
> rng=RNG_stdin, seed=unknown
> length= 16 megabytes (2^24 bytes), time= 2.5 seconds
> no anomalies in 153 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 32 megabytes (2^25 bytes), time= 6.5 seconds 
> no anomalies in 169 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 64 megabytes (2^26 bytes), time= 12.9 seconds 
> no anomalies in 182 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 128 megabytes (2^27 bytes), time= 24.3 seconds 
> no anomalies in 199 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 256 megabytes (2^28 bytes), time= 45.5 seconds 
> no anomalies in 217 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 512 megabytes (2^29 bytes), time= 86.5 seconds
> no anomalies in 232 test result(s)
> rng=RNG_stdin, seed=unknown 
> length= 1 gigabyte (2^30 bytes), time= 167 seconds 
> no anomalies in 251 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 2 gigabytes (2^31 bytes), time= 327 seconds 
> no anomalies in 269 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 4 gigabytes (2^32 bytes), time= 645 seconds 
> no anomalies in 283 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 8 gigabytes (2^33 bytes), time= 1283 seconds 
> no anomalies in 300 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 16 gigabytes (2^34 bytes), time= 2557 seconds 
> no anomalies in 315 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 32 gigabytes (2^35 bytes), time= 5096 seconds 
> no anomalies in 328 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 64 gigabytes (2^36 bytes), time= 10170 seconds 
> no anomalies in 344 test result(s) 
> 
> rng=RNG_stdin, seed=unknown 
> length= 128 gigabytes (2^37 bytes), time= 20316 seconds 
> no anomalies in 359 test result(s) 
> 
> Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek.

Gratulacje. 

Kilka pytań:

Czy możesz gdzieś zamieścić zrozumiały kod samego (wyizolowanego) generatora w
celu przeczytania kodu?

Jakimi generatorami i generalnie jakim algorytmami wzorowałeś się podczas pisania tego generatora?

Czy mogę Twój generator dorzucić do mojej biblioteki i zrobić testy takie jak innych generatorów? - ale to 
kiedyś w przyszłości, pod warunkiem że znajdę czas i będę miał jakiś serwer do testów.

Pozdrawiam

poniedziałek, 30 sierpnia 2021 o 21:38:50 UTC+2 M.M. napisał(a):
> On Sunday, August 29, 2021 at 4:29:12 PM UTC+2, osobli...@gmail.com wrote: 
> > Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona. 
> > 
> > Mój generator zdaje testy: 
> > 
> > RNG_test using PractRand version 0.95 
> > RNG = RNG_stdin, seed = unknown 
> > test set = core, folding = standard(unknown format) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> > no anomalies in 153 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 32 megabytes (2^25 bytes), time= 6.5 seconds 
> > no anomalies in 169 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 64 megabytes (2^26 bytes), time= 12.9 seconds 
> > no anomalies in 182 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 128 megabytes (2^27 bytes), time= 24.3 seconds 
> > no anomalies in 199 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 256 megabytes (2^28 bytes), time= 45.5 seconds 
> > no anomalies in 217 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 512 megabytes (2^29 bytes), time= 86.5 seconds 
> > no anomalies in 232 test result(s) 
> > rng=RNG_stdin, seed=unknown 
> > length= 1 gigabyte (2^30 bytes), time= 167 seconds 
> > no anomalies in 251 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 2 gigabytes (2^31 bytes), time= 327 seconds 
> > no anomalies in 269 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 4 gigabytes (2^32 bytes), time= 645 seconds 
> > no anomalies in 283 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 8 gigabytes (2^33 bytes), time= 1283 seconds 
> > no anomalies in 300 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 16 gigabytes (2^34 bytes), time= 2557 seconds 
> > no anomalies in 315 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 32 gigabytes (2^35 bytes), time= 5096 seconds 
> > no anomalies in 328 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 64 gigabytes (2^36 bytes), time= 10170 seconds 
> > no anomalies in 344 test result(s) 
> > 
> > rng=RNG_stdin, seed=unknown 
> > length= 128 gigabytes (2^37 bytes), time= 20316 seconds 
> > no anomalies in 359 test result(s) 
> > 
> > Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek.
> Gratulacje. 
> 
> Kilka pytań: 
> 
> Czy możesz gdzieś zamieścić zrozumiały kod samego (wyizolowanego) generatora w 
> celu przeczytania kodu? 
> 
> Jakimi generatorami i generalnie jakim algorytmami wzorowałeś się podczas pisania tego generatora? 
> 
> Czy mogę Twój generator dorzucić do mojej biblioteki i zrobić testy takie jak innych generatorów? - ale to 
> kiedyś w przyszłości, pod warunkiem że znajdę czas i będę miał jakiś serwer do testów. 
> 
> Pozdrawiam

Mam pewne plany co do tych generatorów i właściwie aktualnie szukam możliwości ich publikacji lub komercjalizacji, dlatego z publikacją wolałbym zaczekać. Te generatory są dosyć interesującym wynalazkiem z kilku powodów:
- inspiracją były ciągi Collatza i pewne generalizacje tego rodzaju funkcji, teoria stojąca za tymi generatorami jest moim zdaniem naprawdę ciekawa,
- generatory mają klucze, ale są łatwo odwracalne i same w sobie nie są kryptograficznie bezpieczne, jakkolwiek można ich użyć jako budulców algorytmu szyfrującego (stworzyłem taki algorytm),
- wciąż są słabo poznane, poza tym, że dla kilku przetestowanych kluczy generowały dobre wyniki, nie ma teorii, która określałaby ich okres (dla prawdziwie losowej n-elementowej permutacji spodziewamy się okresu (n+1)/2, ale to założenie będzie prawdziwe, jeśli generator daje bardzo dobrej jakości liczby pseudolosowe),
- potrafią generować bloki dowolnej wielkości, przy użyciu odpowiednio dużych kluczy,
- są szybkie (okolice prędkości uzyskiwanych przez generatory PCG).

On Tuesday, August 31, 2021 at 12:57:36 AM UTC+2, osobli...@gmail.com wrote:
> poniedziałek, 30 sierpnia 2021 o 21:38:50 UTC+2 M.M. napisał(a): 
> > On Sunday, August 29, 2021 at 4:29:12 PM UTC+2, osobli...@gmail.com wrote: 
> > > Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona. 
> > > 
> > > Mój generator zdaje testy: 
> > > 
> > > RNG_test using PractRand version 0.95 
> > > RNG = RNG_stdin, seed = unknown 
> > > test set = core, folding = standard(unknown format) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> > > no anomalies in 153 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 32 megabytes (2^25 bytes), time= 6.5 seconds 
> > > no anomalies in 169 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 64 megabytes (2^26 bytes), time= 12.9 seconds 
> > > no anomalies in 182 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 128 megabytes (2^27 bytes), time= 24.3 seconds 
> > > no anomalies in 199 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 256 megabytes (2^28 bytes), time= 45.5 seconds 
> > > no anomalies in 217 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 512 megabytes (2^29 bytes), time= 86.5 seconds 
> > > no anomalies in 232 test result(s) 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 1 gigabyte (2^30 bytes), time= 167 seconds 
> > > no anomalies in 251 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 2 gigabytes (2^31 bytes), time= 327 seconds 
> > > no anomalies in 269 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 4 gigabytes (2^32 bytes), time= 645 seconds 
> > > no anomalies in 283 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 8 gigabytes (2^33 bytes), time= 1283 seconds 
> > > no anomalies in 300 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 16 gigabytes (2^34 bytes), time= 2557 seconds 
> > > no anomalies in 315 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 32 gigabytes (2^35 bytes), time= 5096 seconds 
> > > no anomalies in 328 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 64 gigabytes (2^36 bytes), time= 10170 seconds 
> > > no anomalies in 344 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 128 gigabytes (2^37 bytes), time= 20316 seconds 
> > > no anomalies in 359 test result(s) 
> > > 
> > > Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek. 
> > Gratulacje. 
> > 
> > Kilka pytań: 
> > 
> > Czy możesz gdzieś zamieścić zrozumiały kod samego (wyizolowanego) generatora w 
> > celu przeczytania kodu? 
> > 
> > Jakimi generatorami i generalnie jakim algorytmami wzorowałeś się podczas pisania tego generatora? 
> > 
> > Czy mogę Twój generator dorzucić do mojej biblioteki i zrobić testy takie jak innych generatorów? - ale to 
> > kiedyś w przyszłości, pod warunkiem że znajdę czas i będę miał jakiś serwer do testów. 
> > 
> > Pozdrawiam
> Mam pewne plany co do tych generatorów i właściwie aktualnie szukam możliwości ich publikacji lub komercjalizacji, dlatego z publikacją wolałbym zaczekać. Te generatory są dosyć interesującym wynalazkiem z kilku powodów: 
> - inspiracją były ciągi Collatza i pewne generalizacje tego rodzaju funkcji, teoria stojąca za tymi generatorami jest moim zdaniem naprawdę ciekawa, 
> - generatory mają klucze, ale są łatwo odwracalne i same w sobie nie są kryptograficznie bezpieczne, jakkolwiek można ich użyć jako budulców algorytmu szyfrującego (stworzyłem taki algorytm), 
> - wciąż są słabo poznane, poza tym, że dla kilku przetestowanych kluczy generowały dobre wyniki, nie ma teorii, która określałaby ich okres (dla prawdziwie losowej n-elementowej permutacji spodziewamy się okresu (n+1)/2, ale to założenie będzie prawdziwe, jeśli generator daje bardzo dobrej jakości liczby pseudolosowe), 
> - potrafią generować bloki dowolnej wielkości, przy użyciu odpowiednio dużych kluczy, 
> - są szybkie (okolice prędkości uzyskiwanych przez generatory PCG).

Brzmi ciekawiej i bardziej poważnie niż początkowo sądziłem. Myślałem że to czysta
zabawa czymś znacznie  prostszym od strony teoretycznej, dlatego poprosiłem o wcielenie 
tego generatora do mojej biblioteki - przepraszam.

Życzę zatem udanej publikacji i pozdrawiam.


Nawiasem pisząc, mi się spodobał generator whyhash. Dostałem do niego link
tutaj na grupie. Jest ekstremalnie prosty, a zatem i ekstremalnie szybki:

https://github.com/mmarszik/MRndCPP/blob/master/rnd_wyhash64.h

U mnie przeszedł test na ponad 11.5 terabajta danych:
[
rng=RNG_stdin, seed=0x4175954b
length= 11.544 terabytes (2^43.529 bytes), time= 345602 seconds  no anomalies in 327 test result(s)
real	5760m3.249s
user	5636m4.175s
sys	121m47.242s
]

https://github.com/mmarszik/MRndCPP/blob/master/use_rnd_wyhash64_0.h

Pozdrawiam

On Tuesday, August 31, 2021 at 12:57:36 AM UTC+2, osobli...@gmail.com wrote:
> poniedziałek, 30 sierpnia 2021 o 21:38:50 UTC+2 M.M. napisał(a): 
> > On Sunday, August 29, 2021 at 4:29:12 PM UTC+2, osobli...@gmail.com wrote: 
> > > Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona. 
> > > 
> > > Mój generator zdaje testy: 
> > > 
> > > RNG_test using PractRand version 0.95 
> > > RNG = RNG_stdin, seed = unknown 
> > > test set = core, folding = standard(unknown format) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> > > no anomalies in 153 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 32 megabytes (2^25 bytes), time= 6.5 seconds 
> > > no anomalies in 169 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 64 megabytes (2^26 bytes), time= 12.9 seconds 
> > > no anomalies in 182 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 128 megabytes (2^27 bytes), time= 24.3 seconds 
> > > no anomalies in 199 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 256 megabytes (2^28 bytes), time= 45.5 seconds 
> > > no anomalies in 217 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 512 megabytes (2^29 bytes), time= 86.5 seconds 
> > > no anomalies in 232 test result(s) 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 1 gigabyte (2^30 bytes), time= 167 seconds 
> > > no anomalies in 251 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 2 gigabytes (2^31 bytes), time= 327 seconds 
> > > no anomalies in 269 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 4 gigabytes (2^32 bytes), time= 645 seconds 
> > > no anomalies in 283 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 8 gigabytes (2^33 bytes), time= 1283 seconds 
> > > no anomalies in 300 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 16 gigabytes (2^34 bytes), time= 2557 seconds 
> > > no anomalies in 315 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 32 gigabytes (2^35 bytes), time= 5096 seconds 
> > > no anomalies in 328 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 64 gigabytes (2^36 bytes), time= 10170 seconds 
> > > no anomalies in 344 test result(s) 
> > > 
> > > rng=RNG_stdin, seed=unknown 
> > > length= 128 gigabytes (2^37 bytes), time= 20316 seconds 
> > > no anomalies in 359 test result(s) 
> > > 
> > > Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek. 
> > Gratulacje. 
> > 
> > Kilka pytań: 
> > 
> > Czy możesz gdzieś zamieścić zrozumiały kod samego (wyizolowanego) generatora w 
> > celu przeczytania kodu? 
> > 
> > Jakimi generatorami i generalnie jakim algorytmami wzorowałeś się podczas pisania tego generatora? 
> > 
> > Czy mogę Twój generator dorzucić do mojej biblioteki i zrobić testy takie jak innych generatorów? - ale to 
> > kiedyś w przyszłości, pod warunkiem że znajdę czas i będę miał jakiś serwer do testów. 
> > 
> > Pozdrawiam
> Mam pewne plany co do tych generatorów i właściwie aktualnie szukam możliwości ich publikacji lub komercjalizacji, dlatego z publikacją wolałbym zaczekać. Te generatory są dosyć interesującym wynalazkiem z kilku powodów: 
> - inspiracją były ciągi Collatza i pewne generalizacje tego rodzaju funkcji, teoria stojąca za tymi generatorami jest moim zdaniem naprawdę ciekawa, 
> - generatory mają klucze, ale są łatwo odwracalne i same w sobie nie są kryptograficznie bezpieczne, jakkolwiek można ich użyć jako budulców algorytmu szyfrującego (stworzyłem taki algorytm), 
> - wciąż są słabo poznane, poza tym, że dla kilku przetestowanych kluczy generowały dobre wyniki, nie ma teorii, która określałaby ich okres (dla prawdziwie losowej n-elementowej permutacji spodziewamy się okresu (n+1)/2, ale to założenie będzie prawdziwe, jeśli generator daje bardzo dobrej jakości liczby pseudolosowe), 
> - potrafią generować bloki dowolnej wielkości, przy użyciu odpowiednio dużych kluczy, 
> - są szybkie (okolice prędkości uzyskiwanych przez generatory PCG).

Jeszcze jedno, w sieci coś jest o generatorach na bazie ciągu collatza:
https://link.springer.com/article/10.1007/s41870-019-00307-9

wtorek, 31 sierpnia 2021 o 02:31:07 UTC+2 M.M. napisał(a):
> On Tuesday, August 31, 2021 at 12:57:36 AM UTC+2, osobli...@gmail.com wrote: 
> > poniedziałek, 30 sierpnia 2021 o 21:38:50 UTC+2 M.M. napisał(a): 
> > > On Sunday, August 29, 2021 at 4:29:12 PM UTC+2, osobli...@gmail.com wrote: 
> > > > Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona. 
> > > > 
> > > > Mój generator zdaje testy: 
> > > > 
> > > > RNG_test using PractRand version 0.95 
> > > > RNG = RNG_stdin, seed = unknown 
> > > > test set = core, folding = standard(unknown format) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> > > > no anomalies in 153 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 32 megabytes (2^25 bytes), time= 6.5 seconds 
> > > > no anomalies in 169 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 64 megabytes (2^26 bytes), time= 12.9 seconds 
> > > > no anomalies in 182 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 128 megabytes (2^27 bytes), time= 24.3 seconds 
> > > > no anomalies in 199 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 256 megabytes (2^28 bytes), time= 45.5 seconds 
> > > > no anomalies in 217 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 512 megabytes (2^29 bytes), time= 86.5 seconds 
> > > > no anomalies in 232 test result(s) 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 1 gigabyte (2^30 bytes), time= 167 seconds 
> > > > no anomalies in 251 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 2 gigabytes (2^31 bytes), time= 327 seconds 
> > > > no anomalies in 269 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 4 gigabytes (2^32 bytes), time= 645 seconds 
> > > > no anomalies in 283 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 8 gigabytes (2^33 bytes), time= 1283 seconds 
> > > > no anomalies in 300 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 16 gigabytes (2^34 bytes), time= 2557 seconds 
> > > > no anomalies in 315 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 32 gigabytes (2^35 bytes), time= 5096 seconds 
> > > > no anomalies in 328 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 64 gigabytes (2^36 bytes), time= 10170 seconds 
> > > > no anomalies in 344 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 128 gigabytes (2^37 bytes), time= 20316 seconds 
> > > > no anomalies in 359 test result(s) 
> > > > 
> > > > Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek. 
> > > Gratulacje. 
> > > 
> > > Kilka pytań: 
> > > 
> > > Czy możesz gdzieś zamieścić zrozumiały kod samego (wyizolowanego) generatora w 
> > > celu przeczytania kodu? 
> > > 
> > > Jakimi generatorami i generalnie jakim algorytmami wzorowałeś się podczas pisania tego generatora? 
> > > 
> > > Czy mogę Twój generator dorzucić do mojej biblioteki i zrobić testy takie jak innych generatorów? - ale to 
> > > kiedyś w przyszłości, pod warunkiem że znajdę czas i będę miał jakiś serwer do testów. 
> > > 
> > > Pozdrawiam 
> > Mam pewne plany co do tych generatorów i właściwie aktualnie szukam możliwości ich publikacji lub komercjalizacji, dlatego z publikacją wolałbym zaczekać. Te generatory są dosyć interesującym wynalazkiem z kilku powodów: 
> > - inspiracją były ciągi Collatza i pewne generalizacje tego rodzaju funkcji, teoria stojąca za tymi generatorami jest moim zdaniem naprawdę ciekawa, 
> > - generatory mają klucze, ale są łatwo odwracalne i same w sobie nie są kryptograficznie bezpieczne, jakkolwiek można ich użyć jako budulców algorytmu szyfrującego (stworzyłem taki algorytm), 
> > - wciąż są słabo poznane, poza tym, że dla kilku przetestowanych kluczy generowały dobre wyniki, nie ma teorii, która określałaby ich okres (dla prawdziwie losowej n-elementowej permutacji spodziewamy się okresu (n+1)/2, ale to założenie będzie prawdziwe, jeśli generator daje bardzo dobrej jakości liczby pseudolosowe), 
> > - potrafią generować bloki dowolnej wielkości, przy użyciu odpowiednio dużych kluczy, 
> > - są szybkie (okolice prędkości uzyskiwanych przez generatory PCG).
> Brzmi ciekawiej i bardziej poważnie niż początkowo sądziłem. Myślałem że to czysta 
> zabawa czymś znacznie prostszym od strony teoretycznej, dlatego poprosiłem o wcielenie 
> tego generatora do mojej biblioteki - przepraszam. 

Nie ma problemu, trochę głupio mi, że nie mogę powiedzieć o co chodzi, tym bardziej, że trochę czasu nad tematem tu spędziliśmy. Ale pewnie rozumiesz, że, jeśli to kiedyś ma zostać formalnie opublikowane, to źle by wyglądało, gdyby hulało w jakiejś roboczej wersji po Internecie. A, jeśli się nie mylę, to ma to wystarczający potencjał, by konkurować nowoczesnymi generatorami liczb pseudolosowych. To, czy doprowadzę publikację lub komercyjne badania (może patent) nad tym do końca, to osobna sprawa.

> Życzę zatem udanej publikacji i pozdrawiam. 
> 
> 
> Nawiasem pisząc, mi się spodobał generator whyhash. Dostałem do niego link 
> tutaj na grupie. Jest ekstremalnie prosty, a zatem i ekstremalnie szybki: 
> 
> https://github.com/mmarszik/MRndCPP/blob/master/rnd_wyhash64.h 

Wygląda ciekawie, nigdy wcześniej nie sprawdzałem jak działa, ale obił mi się o uszy. Moje zainteresowania kręcą się wokół generatorów LCG i PCG (autorstwa Melissy O'Neil), z pewnych powodów mają one sporo wspólnego ze wspomnianymi ciągami.

> Jeszcze jedno, w sieci coś jest o generatorach na bazie ciągu collatza: 
> https://link.springer.com/article/10.1007/s41870-019-00307-9

Kojarzę tę publikację. Zaczynałem od podobnych konstrukcji. Nie testowałem ich generatora, bo ostatnio, gdy ją czytałem nie zrozumiałem wszystkiego, ale teraz widzę, że ten ich generator musi być dosyć wolny. Metoda, której użyli jest dosyć typowa i to zdecydowanie dobry trop na wyłuskanie pseudolosowości z tych ciągów. Ogólnie ad vocem, powoli coś się dzieje wokół tematu i coraz więcej naukowców próbuje węszyć jakieś zastosowania ciągów Collatza w kontekście ich pseudolosowych właściwości. Podobne rzeczy próbowało patentować Apple:

https://patents.google.com/patent/US20130108038A1/en

Natomiast ciekawą funkcję one way zaproponowano tutaj:

https://arxiv.org/pdf/1801.05079.pdf

We wszystkich tych publikacjach chodzi głównie o te wektory kodujące "encoding vector". To jest dobre rozwiązanie, ale to za mało, głównie dlatego, że jest to wolne. Policzenie takiego wektora wymaga na przykład 128 iteracji w ciągu Collatza (na liczbach blisko 128-bitowych), z czego uzyskujemy zaledwie liczbę 128-bitową (i wciąż nieidealną, w rzeczywistości ma dużo wad, jeśli chodzi o losowość bitów). Bardzo kosztowny obliczeniowo sposób. Usprawniłem go. Ale nie ukrywam, że zwłaszcza publikacja "One Way Function Candidate based on the Collatz Problem" była dla mnie inspiracją, choć pracowałem nad tym już wcześniej i doskonale zdawałem sobie sprawę co tam się na tych bitach dzieje. Oczywiście pisząc "pracowałem" mam wciąż na myśli, że robiłem to amatorsko, nie jestem matematykiem, ani programistą.

> Nawiasem pisząc, mi się spodobał generator whyhash. Dostałem do niego link 
> tutaj na grupie. Jest ekstremalnie prosty, a zatem i ekstremalnie szybki: 
> 
> https://github.com/mmarszik/MRndCPP/blob/master/rnd_wyhash64.h 
> 
> U mnie przeszedł test na ponad 11.5 terabajta danych: 
> [ 
> rng=RNG_stdin, seed=0x4175954b 
> length= 11.544 terabytes (2^43.529 bytes), time= 345602 seconds no anomalies in 327 test result(s) 
> real 5760m3.249s 
> user 5636m4.175s 
> sys 121m47.242s 
> ] 
> 
> https://github.com/mmarszik/MRndCPP/blob/master/use_rnd_wyhash64_0.h 

Przyjrzałem się dzisiaj temu wyhash64 i działa bardzo podobnie do moich generatorów, a także generatorów PCG (Melissy O'Neil), tyle, że ja wprowadzam jeszcze rotacje poza xorowaniem niskich i wysokich bitów (podobnie jak w PCG XSL-RR-RR). Prędkości moich generatorów są porównywalne z wyhash64. Tyle, że tak jak pisałem według moich wstępnych ustaleń (nie wiem, czy wszystkie klucze są tak samo dobre) moje generatory (128-bitowe) można parametryzować za pomocą 2^256 różnych kluczy, czyli można uzyskać 2^256 różnych generatorów (a w każdym generatorze wciąż możemy oczywiście użyć różnych seedów). 

wyhash64 wydaje się być jednym z najszybszych generatorów obecnie na rynku, które zdają testy (nie licząc prostego lehmer64):

https://github.com/lemire/testingRNG

Jedną z szybkich, świeżych propozycji jest generator ROMU:

https://www.romu-random.org/romupaper.pdf

ale ze względu na rotacje, to chyba nie będzie szybsze niż wyhash.

Bardzo szybki powinien też być ulepszony przeze mnie PCG Melissy O'Neil o nazwie XSL-RR-RR (128-bitowy, choć można stworzyć też wersje 64-bitowe i 32-bitowe):

https://en.wikipedia.org/wiki/Permuted_congruential_generator

Normalnie oblewa on dosyć szybko testy PractRand (kod w Pythonie, sam mixer pewnie można napisać lepiej w C, może jako jakieś macro):

import struct
import sys

x = 83866140117348733064738400095399246193
#seed

def PCGmixer(x):
    count1 = x >> 122
    x1 = (x ^ (x >> 64)) & 18446744073709551615
    low64 = (x1 >> count1) | (x1 << (64 - count1)) & 18446744073709551615
    x2 = (x >> 64) & 18446744073709551615
    count2 = low64 & 63
    high64 = (x2 >> count2) | (x2 << (64 - count2)) & 18446744073709551615
    x = (high64 << 64) | low64
    return x

def LCG(x):
    x = (x * 47026247687942121848144207491837523525 + 83866140218348733064834828227924511723) & 340282366920938463463374607431768211455
    return x

while 1 == 1:

    x=LCG(x)
    w=PCGmixer(x)

    split = [(w >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))]
    binary = struct.pack('IIII', split[0], split[1], split[2], split[3])
    sys.stdout.buffer.write(binary)

Ale wystarczy dodać xorowanie kolejnych wyników:

import struct
import sys

x = 83866140117348733064738400095399246193

def PCGmixer(x):
    count1 = x >> 122
    x1 = (x ^ (x >> 64)) & 18446744073709551615
    low64 = (x1 >> count1) | (x1 << (64 - count1)) & 18446744073709551615
    x2 = (x >> 64) & 18446744073709551615
    count2 = low64 & 63
    high64 = (x2 >> count2) | (x2 << (64 - count2)) & 18446744073709551615
    x = (high64 << 64) | low64
    return x

def LCG(x):
    x = (x * 47026247687942121848144207491837523525 + 83866140218348733064834828227924511723) & 340282366920938463463374607431768211455
    return x

w=0

while 1 == 1:

    w_1 = w

    x=LCG(x)
    w=PCGmixer(x)

    w_2 = w_1 ^ w

    #split = [(w_2 >> x) & 0xFFFFFFFF for x in reversed(range(0, 128, 32))]
    #binary = struct.pack('IIII', split[0], split[1], split[2], split[3])
    #sys.stdout.buffer.write(binary)

Żeby zdawał on testy. Oczywiście sam PCGmixer wydłuża czas pracy istotnie (względem bazowego LCG), ale pewnie można go wykonywać szybciej.

wtorek, 31 sierpnia 2021 o 02:36:05 UTC+2 M.M. napisał(a):
> On Tuesday, August 31, 2021 at 12:57:36 AM UTC+2, osobli...@gmail.com wrote:
> > poniedziałek, 30 sierpnia 2021 o 21:38:50 UTC+2 M.M. napisał(a): 
> > > On Sunday, August 29, 2021 at 4:29:12 PM UTC+2, osobli...@gmail.com wrote: 
> > > > Mogę otwierać szampana, a nawet dwa. Zaktualizowałem wersję do 0.94 - nie pomogło, ale aktualizacja do 0.95 pomogła. Była to w takim razie prawdopodobnie wyłącznie wina testów, nie moja, nie konsoli, nie Pythona. 
> > > > 
> > > > Mój generator zdaje testy: 
> > > > 
> > > > RNG_test using PractRand version 0.95 
> > > > RNG = RNG_stdin, seed = unknown 
> > > > test set = core, folding = standard(unknown format) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 16 megabytes (2^24 bytes), time= 2.5 seconds 
> > > > no anomalies in 153 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 32 megabytes (2^25 bytes), time= 6.5 seconds 
> > > > no anomalies in 169 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 64 megabytes (2^26 bytes), time= 12.9 seconds 
> > > > no anomalies in 182 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 128 megabytes (2^27 bytes), time= 24.3 seconds 
> > > > no anomalies in 199 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 256 megabytes (2^28 bytes), time= 45.5 seconds 
> > > > no anomalies in 217 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 512 megabytes (2^29 bytes), time= 86.5 seconds 
> > > > no anomalies in 232 test result(s) 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 1 gigabyte (2^30 bytes), time= 167 seconds 
> > > > no anomalies in 251 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 2 gigabytes (2^31 bytes), time= 327 seconds 
> > > > no anomalies in 269 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 4 gigabytes (2^32 bytes), time= 645 seconds 
> > > > no anomalies in 283 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 8 gigabytes (2^33 bytes), time= 1283 seconds 
> > > > no anomalies in 300 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 16 gigabytes (2^34 bytes), time= 2557 seconds 
> > > > no anomalies in 315 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 32 gigabytes (2^35 bytes), time= 5096 seconds 
> > > > no anomalies in 328 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 64 gigabytes (2^36 bytes), time= 10170 seconds 
> > > > no anomalies in 344 test result(s) 
> > > > 
> > > > rng=RNG_stdin, seed=unknown 
> > > > length= 128 gigabytes (2^37 bytes), time= 20316 seconds 
> > > > no anomalies in 359 test result(s) 
> > > > 
> > > > Aczkolwiek trzeba ich pewnie zrobić przynajmniej 2^40 bajtów. Jestem pewien, że gdzieś powyżej 128 GB konsola mi się wyłączyła, pomimo, że zostawiłem ją na noc włączoną, razem z laptopem. Mam nadzieję, że sytuacja się nie powtórzy i był to przypadek. 
> > > Gratulacje. 
> > > 
> > > Kilka pytań: 
> > > 
> > > Czy możesz gdzieś zamieścić zrozumiały kod samego (wyizolowanego) generatora w 
> > > celu przeczytania kodu? 
> > > 
> > > Jakimi generatorami i generalnie jakim algorytmami wzorowałeś się podczas pisania tego generatora? 
> > > 
> > > Czy mogę Twój generator dorzucić do mojej biblioteki i zrobić testy takie jak innych generatorów? - ale to 
> > > kiedyś w przyszłości, pod warunkiem że znajdę czas i będę miał jakiś serwer do testów. 
> > > 
> > > Pozdrawiam 
> > Mam pewne plany co do tych generatorów i właściwie aktualnie szukam możliwości ich publikacji lub komercjalizacji, dlatego z publikacją wolałbym zaczekać. Te generatory są dosyć interesującym wynalazkiem z kilku powodów: 
> > - inspiracją były ciągi Collatza i pewne generalizacje tego rodzaju funkcji, teoria stojąca za tymi generatorami jest moim zdaniem naprawdę ciekawa, 
> > - generatory mają klucze, ale są łatwo odwracalne i same w sobie nie są kryptograficznie bezpieczne, jakkolwiek można ich użyć jako budulców algorytmu szyfrującego (stworzyłem taki algorytm), 
> > - wciąż są słabo poznane, poza tym, że dla kilku przetestowanych kluczy generowały dobre wyniki, nie ma teorii, która określałaby ich okres (dla prawdziwie losowej n-elementowej permutacji spodziewamy się okresu (n+1)/2, ale to założenie będzie prawdziwe, jeśli generator daje bardzo dobrej jakości liczby pseudolosowe), 
> > - potrafią generować bloki dowolnej wielkości, przy użyciu odpowiednio dużych kluczy, 
> > - są szybkie (okolice prędkości uzyskiwanych przez generatory PCG).
> Jeszcze jedno, w sieci coś jest o generatorach na bazie ciągu collatza: 
> https://link.springer.com/article/10.1007/s41870-019-00307-9

Cześć. Minęły 2 lata, a ja opatentowałem te generatory PRNG z autorem wspomnianej publikacji - profesorem Danem Tamirem. W międzyczasie wielokrotnie zmieniałem schemat i właściwie to opatentowaliśmy całą klasę generatorów, tak szeroką, że nie do końca zbadałem wszystkie możliwe warianty - taka strategia ma na celu głównie ochronę właściwego generatora przed ominięciem patentu. Ale sprawa jest wciąż delikatna, bo mamy tzw. provisional patent, ważny tylko na rok i zapewniający niepełną ochronę. Po roku podejmiemy decyzję co dalej (czy porzucamy wniosek, czy przekształcamy go w pełen patent).

Schemat może posłużyć do zastosowań kryptograficznych, stąd w ogóle zacząłem myśleć o patencie, w przeciwnym razie raczej nie patentowałbym prostego generatora PRNG. Z uwagi na mój brak doświadczenia w kryptografii, zdecydowałem się zacząć od próby komercjalizacji prostych generatorów PRNG (a następnie sfinansować w ten sposób badania nad zastosowaniami kryptograficznymi, jeżeli nie znajdą się chętni do współpracy). I nad tym obecnie zaczynamy pracować (celujemy m.in. w instytucje badawcze wykorzystujące symulacje Monte Carlo, branżę AI, gry, przetwarzanie obrazów, głównie za pomocą metody Monte Carlo path tracing). Jednocześnie będę szukał kontaktu z naukowcami, którzy chcieliby podjąć z nami współpracę w celu opracowania schematów, analizy i publikacji naukowej dotyczącej zastosowań kryptograficznych (głównie myślę o funkcji hashującej i szyfrze strumieniowym, które stworzyłem, ale nie mam odpowiedniej wiedzy, by ocenić i ich bezpieczeństwo, tzn. przeanalizować pod kątem wszelkich znanych współcześnie ataków kryptograficznych).

Gdybyś nadal chciał przetestować mój generator, to tu jest wersja 128-bitowa:

https://pastebin.com/mJiU8Dsk

Tu jest wersja 64-bitowa:

https://pastebin.com/qMrqmiue

Oraz najszybsza w przeliczeniu na cykle na bajt wersja 128/64-bitowa (zwraca 128-bitów, ale działa głównie na arytmetyce 64-bitowej):

https://pastebin.com/AHz88Ldj

Wszystkie wersje zdają testy PractRand powyżej gwarantowanego okresu minimalnego (co widać w pomniejszonych wersjach 16-bitowej oraz 32-bitowej). Oznacza to, że wersji 128 bitowej można używać bez ryzyka statystycznych anomalii aż do 2^128 wygenerowanych liczb, a wersji 64-bitowych aż do 2^64 wygenerowanych liczb. Nie trzeba się też martwić problemem urodzinowym i nie przekraczać użycia pierwiastka z okresu generatora, bowiem są to generatory chaotyczne i nie mają struktury pojedynczego cyklu. Inicjalizacja może być dowolna, pod warunkiem liczby c[0], która musi być nieparzysta. Generatorowi może zająć kilka iteracji zanim wypełni swój stan bitami równomiernie, jeżeli zainicjujemy go niewielką liczbą. Do tego celu można użyć inicjalizatora lub po prostu zainicjować generator losową liczbą. Ponadto można uzyskać 2^64 (w wersji 64-bitowej) lub 2^128 (w wersji 128-bitowej) niezależnych strumieni liczb, dla każdej unikalnej inicjalizacji unikalną liczbą nieparzystą. Przy inicjalizacji kolejno następującymi po sobie liczbami nieparzystymi niektóre bity niskiego rzędu mogą być skorelowane, choć PractRand nie umie tego wykryć. Aby uniknąć korelacji, należy pominąć odpowiednio 48 lub 32 pierwsze wyniki, do czego może posłużyć inicjalizator lub inicjować kolejne strumienie losowymi liczbami. Z uwagi na fakt, że każdy unikalnie zainicjowany generator tworzy unikalny strumień liczb - nie ma ryzyka tzw. overlapping - nachodzenia na siebie dwóch sekwencji (nie poruszamy się po jednym i tym samym cyklu, każda inicjalizacja generuje swoją ścieżkę do cyklu o gwarantowanej minimalnej długości i swój unikalny cykl).

W wersji 128/64-bitowej wkradł się błąd. Poprawione:

https://pastebin.com/pFq4ATy0

W wersji 128/64-bitowej wkradł się błąd. Poprawione:

https://pastebin.com/SFzE0wv1

W wersji 128/64-bitowej wkradł się błąd. Poprawione:

https://pastebin.com/NKcKveDT

Wyniki testów prędkości za pomocą repozytorium prof. Lemire, do którego dołączyłem całkiem sporo generatorów, w tym moje CG:

https://github.com/lemire/testingRNG

mersennetwister32                :  0.68 cycles per byte
pcg32                                       :  0.73 cycles per byte
widynski32                              :  0.81 cycles per byte
trivium32                                 :  1.99 cycles per byte
xorshift_k5                              :  0.68 cycles per byte
xorshift_k4                              :  0.72 cycles per byte
mitchellmoore                        :  0.83 cycles per byte
xorshift32                               :  0.80 cycles per byte
rand                                         :  1.29 cycles per byte

aesdragontamer                    :  0.23 cycles per byte
aesctr                                      :  0.21 cycles per byte
lehmer64                                :  0.36 cycles per byte
trivium64                               :  0.88 cycles per byte
xorshift1024star                   :  0.52 cycles per byte
xorshift1024plus                   :  0.40 cycles per byte
xorshift128plus                     :  0.34 cycles per byte
wyhash64                              :  0.29 cycles per byte
wyrand                                   :  0.27 cycles per byte
xoroshiro512plus                 :  0.40 cycles per byte
xoroshiro128plus                 :  0.37 cycles per byte
xoroshiro256plus                 :  0.37 cycles per byte
GMWC256                            :  0.53 cycles per byte
MWC256                               :  0.31 cycles per byte
SFC64                                   :  0.57 cycles per byte
splitmix64                            :  0.28 cycles per byte
pcg64                                   :  0.42 cycles per byte
PCG-DXSM                          :  0.42 cycles per byte
xoroshiro128plusplus        :  0.34 cycles per byte
xoroshiro256plusplus        :  0.38 cycles per byte

CG64                                     :  0.43 cycles per byte
CG128-64                             :  0.23 cycles per byte
CG128                                   :  0.30 cycles per byte