Jak zrobić test za pomocą PractRand?

[osobli...@gmail.com]

Czy ktoś z Was robił testy generatorów liczb pseudolosowych za pomocą PractRand?

Przeczytałem instrukcje stąd:

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

I zrobiłem build process na konsoli Ubuntu na Windowsie. Chcę jednak zrobić test mojego własnego generatora. Rozumiem, że muszę napisać kod w C++. Skopiowałem kod:

#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);
}
}

ale nie udało mi się go skompilować. Wynik:

g++: error: mt19937-min.cpp: No such file or directory
g++: fatal error: no input files
compilation terminated.

Nie wiem właściwie nic o C++, znam podstawy programowania w Pythonie, więc może coś robię źle? Niemniej, kod mojego generatora w C++ jakoś sobie prędzej, czy później napiszę, choć liczyłem, że będzie można użyć pliku txt z wygenerowanymi już liczbami. Najważniejsze jest dla mnie jak to uruchomić.

[osobli...@gmail.com]

g++: error: mt19937-min.cpp: No such file or directory
g++: fatal error: no input files
compilation terminated.

To błąd z kompilacją, a nie z samym testem. Błąd tak powszechny i beznadziejny, że uznałem, iż prędzej zainstaluję VS i to skompiluję, niż naprawię ten błąd (internetowe poradniki są albo nie działają albo są niezrozumiałe). Pozostaje mieć nadzieję, że kiedyś ktoś w Linuxie zrobi z tym porządek. Zresztą, jeśli mam napisać i kompilować program w C++ i tak przyda mi się VS.

Same testy dają się odpalić, wczytałem plik z liczbami, ale coś jest nie tak:

rng=RNG_stdin, seed=0x1687c235
length= 256 megabytes (2^28 bytes), time= 2.8 seconds
Test Name Raw Processed Evaluation
BCFN(2+0,13-2,T) R=+15927312 p = 0 FAIL !!!!!!!!
BCFN(2+1,13-2,T) R=+11593600 p = 0 FAIL !!!!!!!!
BCFN(2+2,13-3,T) R=+8011486 p = 0 FAIL !!!!!!!!
BCFN(2+3,13-3,T) R=+3903870 p = 0 FAIL !!!!!!!!

Nie wiem nawet, czy liczby w pliku są w odpowiednim formacie (32-bitowe wypisane jedna pod drugą) i nie mogę się doszukać w jakim mają być formacie.

[osobli...@gmail.com]

Dane muszą być w formacie binarnym:

https://www.researchgate.net/publication/340214294_A_Practical_Approach_to_Testing_Random_Number_Generators_in_Computer_Algebra_Systems

"For testing data from a file, the fol-lowing command can be used:

cat file.data | RNG_test stdin64

The data in the file must be binary; text files are not supported."

Ale nie mogą być w pliku txt, tylko .data. Pytanie jak zapisać coś w formacie .data, w szczególności w Pythonie?

[M.M.]

On Thursday, August 19, 2021 at 6:15:26 PM UTC+2, osobli...@gmail.com wrote:
> Czy ktoś z Was robił testy generatorów liczb pseudolosowych za pomocą PractRand?

Jeśli chce Ci się czytać C++ to możesz zobaczyć jak ja to zrobiłem:

https://github.com/mmarszik/MRndCPP

https://github.com/mmarszik/MRndCPP/blob/master/tests/test.sh
{ time ./$prog | ./../../PractRand/RNG_test stdin -singlethreaded -tlmax 360000s > $test; } 2> $time

https://github.com/mmarszik/MRndCPP/blob/master/test01.cpp
fwrite( buf, 1, sizeof(buf), stdout );

Słyszałem że temat generowania liczb pseudo-losowych jest bardzo trudny :/

Pozdrawiam

[osobli...@gmail.com]

piątek, 20 sierpnia 2021 o 15:04:14 UTC+2 M.M. napisał(a):
> On Thursday, August 19, 2021 at 6:15:26 PM UTC+2, osobli...@gmail.com wrote:
> > Czy ktoś z Was robił testy generatorów liczb pseudolosowych za pomocą PractRand?
> Jeśli chce Ci się czytać C++ to możesz zobaczyć jak ja to zrobiłem:
>
> https://github.com/mmarszik/MRndCPP
>
> https://github.com/mmarszik/MRndCPP/blob/master/tests/test.sh
> { time ./$prog | ./../../PractRand/RNG_test stdin -singlethreaded -tlmax 360000s > $test; } 2> $time
>
> https://github.com/mmarszik/MRndCPP/blob/master/test01.cpp
> fwrite( buf, 1, sizeof(buf), stdout );

Nic z tego nie rozumiem, ani nawet nie wiem od czego zacząć. Co robi Twój kod? Bo podstawowe pytanie jakie mam to co ma zwracać program do PractRand? Domyślam się, że ma generować bit po bicie, czyli pojedyncze wywołanie powinno generować jeden psudolosowy bit.

> > Nie wiem właściwie nic o C++, znam podstawy programowania w Pythonie, więc może coś robię źle? Niemniej, kod mojego generatora w C++ jakoś sobie prędzej, czy później napiszę, choć liczyłem, że będzie można użyć pliku txt z wygenerowanymi już liczbami. Najważniejsze jest dla mnie jak to uruchomić.
> Słyszałem że temat generowania liczb pseudo-losowych jest bardzo trudny :/

Moje generatory zdają wszystkie testy Dieharder, szukam więc czegoś bardziej wymagającego. Także mam już generatory, które działają, zresztą generatorów, które istnieją i można modyfikować na wiele sposobów również jest pod dostatkiem. Co do zasady jest to trudne i trzeba wiedzieć co się robi, ale z tym problemem już się uporałem. Większe wyzwanie stanowi dla mnie C++ (ten język chyba już na poziomie projektowania stawiał sobie za bycie nieprzejrzystym i inkluzywnym) i dokumentacja PractRand.

[M.M.]

Odnośnie C++ właśnie wkleiłem kluczową linię kodu:

fwrite( buf, 1, sizeof(buf), stdout );

Lina ta wywala binarnie bufor na standardowe wyjście, wcześniej trzeba go zapełnić binarnymi danymi. W pliku do którego
dałem link jest pełny przykład.

Odnośnie Practrand ta linia jest kluczowa:

{ time ./$prog | ./../../PractRand/RNG_test stdin -singlethreaded -tlmax 360000s > $test; } 2> $time

Przekierowuje ona standardowe wyjście programu do programu PractRand, reszta to opcje, pomiar czasu, przekierowanie wyników.

W skrócie, jeśli PractRand jest w tym samym katalogu co program, uruchamia się to tak:
./Program | ./PractRand stdin [tu wpisz opcje PractRand]

Jeśli dane są w pliku binarnym to tak:
cat dane_binarne.bin | ./PractRand stdin [tu wpisz opcje PractRand]

Jeśli w są w tekstowym, to np. tak (nie wiem czy można prościej, by musiała być odpowiednia
opcja PractRand i odpowiedni format danych tekstowych - może jest):
cat dane_tekstowe.txt | ./zamien_na_binarne | ./PractRand stdin [tu wpisz opcje PractRand]
Ale program który poprawnie zamieni Twoje dane tekstowe na dane binarne musisz napisać sobie sam.

Pozdrawiam

[osobli...@gmail.com]

> Odnośnie C++ właśnie wkleiłem kluczową linię kodu:
> fwrite( buf, 1, sizeof(buf), stdout );
> Lina ta wywala binarnie bufor na standardowe wyjście, wcześniej trzeba go zapełnić binarnymi danymi. W pliku do którego
> dałem link jest pełny przykład.
>
> Odnośnie Practrand ta linia jest kluczowa:
> { time ./$prog | ./../../PractRand/RNG_test stdin -singlethreaded -tlmax 360000s > $test; } 2> $time
> Przekierowuje ona standardowe wyjście programu do programu PractRand, reszta to opcje, pomiar czasu, przekierowanie wyników.
>
> W skrócie, jeśli PractRand jest w tym samym katalogu co program, uruchamia się to tak:
> ./Program | ./PractRand stdin [tu wpisz opcje PractRand]

Wydaje mi się, że prędzej, niż ogarnę C++ zrobię odpowiedni plik. Przepisanie kodu z Pythona do C++ musiałbym raczej komuś zlecić. Także chyba z pisaniem programu w C++ dam sobie spokój (tym bardziej, że mój program wykonuje operacje na liczbach 128-bitowych, a C++ takich nie obsługuje, zaś zainstalowanie odpowiedniej biblioteki do obsługi tak dużych liczb, to już jest dla mnie zadanie na długie tygodnie, może miesiące, bez gwarancji sukcesu - gdy próbowałem zrobić to lata temu nie udało się). Pytanie, czy będę w stanie wygenerować odpowiedni plik w odpowiednim czasie (bo pomimo, że generatory, które testuję są jednymi z najszybszych na świecie, co do zasady są podobne do PCG generators, to Python nie dość, że bywa 50-100 razy wolniejszy niż C++, to jeszcze do tego sam zapis do pliku trwa długo i jak szybki nie byłby generator - nie da się tego procesu przyspieszyć). Ile PractRand potrzebuje danych?

Dieharder przykładowo potrzebował 32-bitowe liczby wypisane jedna pod drugą w ilości blisko 50 GB (których zapisanie do pliku i wygenerowanie trwało kilka godzin), żeby generator nie oblewał testów (gdy danych było za mało plik był zawijany i do testów był brane w kółko te same liczby, do powodowało oblewanie testów). A i tak zawijał niektóre próbki, tzw. " rewounds".

> Jeśli dane są w pliku binarnym to tak:
> cat dane_binarne.bin | ./PractRand stdin [tu wpisz opcje PractRand]

Jak utworzyć plik .bin? Mam 50GB danych binarnych, to jest zera i jedynki w formie .txt. Ale pliki .bin to chyba coś innego?

> Jeśli w są w tekstowym, to np. tak (nie wiem czy można prościej, by musiała być odpowiednia
> opcja PractRand i odpowiedni format danych tekstowych - może jest):
> cat dane_tekstowe.txt | ./zamien_na_binarne | ./PractRand stdin [tu wpisz opcje PractRand]
> Ale program który poprawnie zamieni Twoje dane tekstowe na dane binarne musisz napisać sobie sam.

Tutaj piszą:

https://www.researchgate.net/publication/340214294_A_Practical_Approach_to_Testing_Random_Number_Generators_in_Computer_Algebra_Systems

że:

"For testing data from a file, the fol-lowing command can be used:

cat file.data | RNG_test stdin64

The data in the file must be binary; text files are not supported."

Że pliki tekstowe nie są akceptowane, więc, czy na pewno można to tak zrobić i to zadziała poprawnie? Same testy mi się wykonały, ale mam dużo FAILI:

rng=RNG_stdin, seed=0x8117bdda
length= 256 megabytes (2^28 bytes), time= 2.9 seconds

Test Name Raw Processed Evaluation

BCFN(2+0,13-2,T) R=+27538479 p = 0 FAIL !!!!!!!!
BCFN(2+1,13-2,T) R=+13016562 p = 0 FAIL !!!!!!!!
BCFN(2+2,13-3,T) R=+8037376 p = 0 FAIL !!!!!!!!
BCFN(2+3,13-3,T) R=+3903883 p = 0 FAIL !!!!!!!!
BCFN(2+4,13-3,T) R=+1911999 p = 0 FAIL !!!!!!!!
BCFN(2+5,13-4,T) R=+1199616 p = 0 FAIL !!!!!!!!
BCFN(2+6,13-5,T) R=+746903 p = 0 FAIL !!!!!!!!
BCFN(2+7,13-5,T) R=+370686 p = 0 FAIL !!!!!!!!
BCFN(2+8,13-6,T) R=+228593 p = 0 FAIL !!!!!!!!
BCFN(2+9,13-6,T) R=+113862 p = 0 FAIL !!!!!!!!
BCFN(2+10,13-7,T) R=+69095 p = 0 FAIL !!!!!!!!
BCFN(2+11,13-8,T) R=+40957 p = 0 FAIL !!!!!!!!
BCFN(2+12,13-8,T) R=+20441 p = 1e-5188 FAIL !!!!!!!!
BCFN(2+13,13-9,T) R=+11734 p = 8e-2638 FAIL !!!!!!!!
BCFN(2+14,13-9,T) R= +5853 p = 3e-1316 FAIL !!!!!!!!
DC6-9x1Bytes-1 R=+13379089 p = 0 FAIL !!!!!!!!
Gap-16:A R=+5676902 p = 0 FAIL !!!!!!!!
Gap-16:B R=+25156958 p = 0 FAIL !!!!!!!!
FPF-14+6/16:(0,14-0) R=+9523586 p = 0 FAIL !!!!!!!!
FPF-14+6/16:(4,14-1) R=+11217844 p = 0 FAIL !!!!!!!!
FPF-14+6/16:all R=+16607352 p = 0 FAIL !!!!!!!!
FPF-14+6/16:cross R=+56967921 p = 0 FAIL !!!!!!!!
BRank(12):128(4) R= +4568 p~= 2e-2430 FAIL !!!!!!!!
BRank(12):256(4) R= +9390 p~= 6e-4995 FAIL !!!!!!!!
BRank(12):384(1) R= +7106 p~= 3e-2140 FAIL !!!!!!!!
BRank(12):512(2) R=+13459 p~= 1e-4052 FAIL !!!!!!!!
BRank(12):768(1) R=+14339 p~= 1e-4317 FAIL !!!!!!!!
BRank(12):1K(2) R=+27098 p~= 2e-8158 FAIL !!!!!!!!
BRank(12):1536(1) R=+28805 p~= 2e-8672 FAIL !!!!!!!!
BRank(12):2K(1) R=+38450 p~= 0 FAIL !!!!!!!!
[Low1/8]BCFN(2+0,13-4,T) R= +4290 p = 2e-1874 FAIL !!!!!!!!
[Low1/8]BCFN(2+1,13-4,T) R= +4280 p = 4e-1870 FAIL !!!!!!!!
[Low1/8]BCFN(2+2,13-5,T) R= +5376 p = 1e-2104 FAIL !!!!!!!!
[Low1/8]BCFN(2+3,13-5,T) R= +5322 p = 1e-2083 FAIL !!!!!!!!
[Low1/8]BCFN(2+4,13-5,T) R= +5216 p = 4e-2042 FAIL !!!!!!!!
[Low1/8]BCFN(2+5,13-6,T) R= +6417 p = 4e-2198 FAIL !!!!!!!!
[Low1/8]BCFN(2+6,13-6,T) R= +6363 p = 1e-2179 FAIL !!!!!!!!
[Low1/8]BCFN(2+7,13-7,T) R= +7512 p = 4e-2260 FAIL !!!!!!!!
[Low1/8]BCFN(2+8,13-8,T) R= +8494 p = 1e-2156 FAIL !!!!!!!!
[Low1/8]BCFN(2+9,13-8,T) R= +7611 p = 1e-1932 FAIL !!!!!!!!
[Low1/8]BCFN(2+10,13-9,T) R= +7064 p = 2e-1588 FAIL !!!!!!!!
[Low1/8]BCFN(2+11,13-9,T) R= +4936 p = 3e-1110 FAIL !!!!!!!!
[Low1/8]DC6-9x1Bytes-1 R=+391.8 p = 4.9e-263 FAIL !!!!!!
[Low1/8]FPF-14+6/16:(0,14-0) R= +56.6 p = 1.0e-51 FAIL !!!!
[Low1/8]FPF-14+6/16:(1,14-1) R= +39.1 p = 1.9e-34 FAIL !!!
[Low1/8]FPF-14+6/16:(2,14-2) R= +24.1 p = 7.6e-21 FAIL !
[Low1/8]FPF-14+6/16:(3,14-2) R= +11.6 p = 6.6e-10 very suspicious
[Low1/8]FPF-14+6/16:all R= +80.5 p = 4.7e-75 FAIL !!!!
[Low1/8]FPF-14+6/16:all2 R= +1234 p = 8.7e-437 FAIL !!!!!!!
[Low1/8]FPF-14+6/16:cross R=+347.9 p = 4.3e-274 FAIL !!!!!!
[Low4/32]BCFN(2+0,13-4,T) R=+5636982 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+1,13-4,T) R=+2664412 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+2,13-5,T) R=+1609820 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+3,13-5,T) R=+781907 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+4,13-5,T) R=+382945 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+5,13-6,T) R=+233930 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+6,13-6,T) R=+115740 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+7,13-7,T) R=+69900 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+8,13-8,T) R=+41294 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+9,13-8,T) R=+20560 p = 6e-5219 FAIL !!!!!!!!
[Low4/32]BCFN(2+10,13-9,T) R=+11783 p = 1e-2648 FAIL !!!!!!!!
[Low4/32]BCFN(2+11,13-9,T) R= +5870 p = 4e-1320 FAIL !!!!!!!!
[Low4/32]DC6-9x1Bytes-1 R=+2399367 p = 0 FAIL !!!!!!!!
[Low4/32]Gap-16:A R=+756848 p = 0 FAIL !!!!!!!!
[Low4/32]Gap-16:B R=+4597397 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(0,14-0) R=+1007012 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(4,14-3) R=+1156867 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(8,14-6) R=+1083851 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(12,14-9) R=+1027154 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:all R=+1913749 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:all2 R=+1775316442517 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:cross R=+10872050 p = 0 FAIL !!!!!!!!
[Low4/32]BRank(12):128(4) R= +3922 p~= 8e-2087 FAIL !!!!!!!!
[Low4/32]BRank(12):256(2) R= +5696 p~= 1e-1715 FAIL !!!!!!!!
[Low4/32]BRank(12):384(1) R= +6094 p~= 1e-1835 FAIL !!!!!!!!
[Low4/32]BRank(12):512(2) R=+11541 p~= 2e-3475 FAIL !!!!!!!!
[Low4/32]BRank(12):768(1) R=+12294 p~= 6e-3702 FAIL !!!!!!!!
[Low4/32]BRank(12):1K(1) R=+16427 p~= 3e-4946 FAIL !!!!!!!!
[Low1/32]BCFN(2+0,13-5,T) R= +1333 p = 5.0e-522 FAIL !!!!!!!
[Low1/32]BCFN(2+1,13-5,T) R= +1309 p = 1.3e-512 FAIL !!!!!!!
[Low1/32]BCFN(2+2,13-6,T) R= +1678 p = 4.5e-575 FAIL !!!!!!!
[Low1/32]BCFN(2+3,13-6,T) R= +1603 p = 1.6e-549 FAIL !!!!!!!
[Low1/32]BCFN(2+4,13-6,T) R= +1599 p = 6.2e-548 FAIL !!!!!!!
[Low1/32]BCFN(2+5,13-7,T) R= +1945 p = 1.3e-585 FAIL !!!!!!!
[Low1/32]BCFN(2+6,13-8,T) R= +2317 p = 6.9e-589 FAIL !!!!!!!
[Low1/32]BCFN(2+7,13-8,T) R= +2195 p = 5.7e-558 FAIL !!!!!!!
[Low1/32]BCFN(2+8,13-9,T) R= +2337 p = 2.7e-526 FAIL !!!!!!!
[Low1/32]BCFN(2+9,13-9,T) R= +2193 p = 6.4e-494 FAIL !!!!!!!
[Low1/32]DC6-9x1Bytes-1 R=+126.7 p = 8.2e-67 FAIL !!!!
[Low1/32]FPF-14+6/16:(0,14-2) R= +22.0 p = 4.9e-19 FAIL !
[Low1/32]FPF-14+6/16:(1,14-2) R= +12.1 p = 2.1e-10 VERY SUSPICIOUS
[Low1/32]FPF-14+6/16:(2,14-3) R= +9.0 p = 1.1e-7 suspicious
[Low1/32]FPF-14+6/16:(3,14-4) R= +6.8 p = 1.8e-5 unusual
[Low1/32]FPF-14+6/16:all R= +29.9 p = 1.0e-26 FAIL !!
[Low1/32]FPF-14+6/16:all2 R=+151.1 p = 3.4e-53 FAIL !!!!
[Low1/32]FPF-14+6/16:cross R= +95.9 p = 4.0e-78 FAIL !!!!
...and 36 test result(s) without anomalies

Co więcej w ten sposób PractRand przyjął też plik z wypisanymi liczbami 32-bitowymi jedna pod drugą w formacie dziesiętnym i też pokazał jakieś FAILE. Pytanie co program testuje, skoro plik był w nieodpowiednim formacie. Mam podejrzenia, że nie robi testów w sposób poprawny.

[osobli...@gmail.com]

Zapisałem plik za pomocą Pythona w formacie .data. Wygenerowałem strumień zer i jedynek do pliku. Plik ma 45 GB. I wciąż mam tę samą liczbę FAILI. Pytanie, czy danych nie jest za mało? Spróbuję wygenerować ich ponad 200 GB i zobaczę, czy to coś zmieni.

[M.M.]

On Friday, August 20, 2021 at 6:14:53 PM UTC+2, osobli...@gmail.com wrote:
> > Odnośnie C++ właśnie wkleiłem kluczową linię kodu:
> > fwrite( buf, 1, sizeof(buf), stdout );
> > Lina ta wywala binarnie bufor na standardowe wyjście, wcześniej trzeba go zapełnić binarnymi danymi. W pliku do którego
> > dałem link jest pełny przykład.
> >
> > Odnośnie Practrand ta linia jest kluczowa:
> > { time ./$prog | ./../../PractRand/RNG_test stdin -singlethreaded -tlmax 360000s > $test; } 2> $time
> > Przekierowuje ona standardowe wyjście programu do programu PractRand, reszta to opcje, pomiar czasu, przekierowanie wyników.
> >
> > W skrócie, jeśli PractRand jest w tym samym katalogu co program, uruchamia się to tak:
> > ./Program | ./PractRand stdin [tu wpisz opcje PractRand]


> Wydaje mi się, że prędzej, niż ogarnę C++ zrobię odpowiedni plik.

Można ,ale dobre testowanie wymaga dużo danych. Osobiście testowałem generatory minimum
godzinę, maksimum (o ile pamiętam) dwa tygodnie na jednym wątku. Przez ten czas, szczególnie
przez dwa tygodnie, generator jest w stanie wygenerować sporo liczb i program testowy sporo skonsumować.
Liczby z dwóch tygodni nie wiem czy zmieszczą się na dysku.

> Przepisanie kodu z Pythona do C++ musiałbym raczej komuś zlecić.

Co tam konkretnie jest do napisania? Może coś podobnego jest to gotowe pod linkami które podałem?

> Także chyba z pisaniem programu w C++ dam sobie spokój (tym bardziej, że mój program wykonuje operacje na liczbach
> 128-bitowych, a C++ takich nie obsługuje, zaś zainstalowanie odpowiedniej biblioteki do obsługi tak dużych liczb, to już jest
> dla mnie zadanie na długie tygodnie, może miesiące, bez gwarancji sukcesu - gdy próbowałem zrobić to lata temu nie udało się).

Niektóre kompilatory obsługują typ 128bitowy tak samo jak typ 64bitowy. Po zainstalowaniu dobrej biblioteki w C++ używa się
typu N-bitowego tak samo jak np. 64bitowego.

> Pytanie, czy będę w stanie wygenerować odpowiedni plik w odpowiednim czasie (bo pomimo, że generatory, które testuję są
> jednymi z najszybszych na świecie, co do zasady są podobne do PCG generators, to Python nie dość, że bywa 50-100 razy
> wolniejszy niż C++, to jeszcze do tego sam zapis do pliku trwa długo i jak szybki nie byłby generator - nie da się tego procesu
> przyspieszyć). Ile PractRand potrzebuje danych?

Zapis całego dużego dysku to np. jedna doba, ale zależy jaki szybki/duży dysk, może być godzina, może być tydzień. Trudno
bez testów powiedzieć czy wolniejszy będzie zapis czy powolne generowanie najszybszym generatorem na świecie. PractRand
tym lepiej testuje im więcej danych otrzyma. Jeśli jakiś generator, w jakimś programie intensywnie pracuje przez długie tygodnie na
wielu wątkach, to testowanie generatora przez kilka dni może mieć sens. Można też zapisać zarodki generatorów użyte w
programie, aby potem wykonać testy dokładnie tych samych ciągów losowych liczby jakie były użyte.

> Dieharder przykładowo potrzebował 32-bitowe liczby wypisane jedna pod drugą w ilości blisko 50 GB (których
> zapisanie do pliku i wygenerowanie trwało kilka godzin),

To możesz zapisać teraz 50GB na dysk z dev/zero przy użyciu dd i mieć przybliżony narzut na obliczenia generatora.

> żeby generator nie oblewał testów (gdy danych było za mało plik był zawijany i do testów był brane w kółko te same liczby, do
> powodowało oblewanie testów). A i tak zawijał niektóre próbki, tzw. " rewounds".

Temat jest trudniejszy, może generator na małych zapętlonych danych przechodzić test, na na długich oblewać.
Chyba najlepiej odtworzyć te same dane losowe co były użyte w programie, aby mieć pewność że program
pracował na losowych danych które przechodzą testy statystyczne.

> > Jeśli dane są w pliku binarnym to tak:
> > cat dane_binarne.bin | ./PractRand stdin [tu wpisz opcje PractRand]
> Jak utworzyć plik .bin? Mam 50GB danych binarnych, to jest zera i jedynki w formie .txt. Ale pliki .bin to chyba coś innego?
> > Jeśli w są w tekstowym, to np. tak (nie wiem czy można prościej, by musiała być odpowiednia
> > opcja PractRand i odpowiedni format danych tekstowych - może jest):
> > cat dane_tekstowe.txt | ./zamien_na_binarne | ./PractRand stdin [tu wpisz opcje PractRand]
> > Ale program który poprawnie zamieni Twoje dane tekstowe na dane binarne musisz napisać sobie sam.
> Tutaj piszą:
>
> https://www.researchgate.net/publication/340214294_A_Practical_Approach_to_Testing_Random_Number_Generators_in_Computer_Algebra_Systems
>
> że:
> "For testing data from a file, the fol-lowing command can be used:
>
> cat file.data | RNG_test stdin64
>
> The data in the file must be binary; text files are not supported."
> Że pliki tekstowe nie są akceptowane, więc, czy na pewno można to tak zrobić i to zadziała poprawnie? Same testy mi się wykonały, ale mam dużo FAILI:

Zadziała, ale jeśli tester nie wspomaga plików tekstowych, to trzeba samemu napisać program który zamieni dane tekstowe na binarne.
Potem dam przykładowy kod w C++, może dziś wieczorem, to kilka linijek.

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.

Pozdrawiam

[osobli...@gmail.com]

> Jeśli dane są w pliku binarnym to tak:
> cat dane_binarne.bin | ./PractRand stdin [tu wpisz opcje PractRand]

Jakie są te opcje PractRand? Ja uruchamiam to w ten sposób:

cat plik.data | ./RNG_test stdin

Niestety zwiększenie rozmiaru pliku do 230 GB nie pomogło, a więcej nie zmieści mi się na dysku. Wciąż dziwią mnie te oblane testy, podczas, gdy wszystkie testy Dieharder ten generator zdawał. Albo PractRand jest o tyle bardziej wymagający, albo nadal coś jest nie tak.

> > Wydaje mi się, że prędzej, niż ogarnę C++ zrobię odpowiedni plik.
> Można ,ale dobre testowanie wymaga dużo danych. Osobiście testowałem generatory minimum
> godzinę, maksimum (o ile pamiętam) dwa tygodnie na jednym wątku. Przez ten czas, szczególnie
> przez dwa tygodnie, generator jest w stanie wygenerować sporo liczb i program testowy sporo skonsumować.
> Liczby z dwóch tygodni nie wiem czy zmieszczą się na dysku.

Na pewno się nie zmieszczą. Już osiągnąłem limit. Z jakichś powodów zresztą bardzo szybko udało mi się to wygenerować i zapisać do pliku (godzina z hakiem), tak jakby liczby w formacie binarnym zapisywały się szybciej. 50 GB liczb 32-bitowych w formacie dziesiętnym zapisywało mi się kilka godzin.

Ile GB w takim przetestowałeś, skoro robiłeś testy nawet 2 tygodnie?

> > Przepisanie kodu z Pythona do C++ musiałbym raczej komuś zlecić.
> Co tam konkretnie jest do napisania? Może coś podobnego jest to gotowe pod linkami które podałem?

Przykładowy program:

https://pastebin.com/K164URZQ

Liczby 128-bitowe są tam ładowanie po prostu do listy allstream, ale oczywiście można to zaaranżować inaczej.

> > Pytanie, czy będę w stanie wygenerować odpowiedni plik w odpowiednim czasie (bo pomimo, że generatory, które testuję są
> > jednymi z najszybszych na świecie, co do zasady są podobne do PCG generators, to Python nie dość, że bywa 50-100 razy
> > wolniejszy niż C++, to jeszcze do tego sam zapis do pliku trwa długo i jak szybki nie byłby generator - nie da się tego procesu
> > przyspieszyć). Ile PractRand potrzebuje danych?
> Zapis całego dużego dysku to np. jedna doba, ale zależy jaki szybki/duży dysk, może być godzina, może być tydzień. Trudno
> bez testów powiedzieć czy wolniejszy będzie zapis czy powolne generowanie najszybszym generatorem na świecie. PractRand
> tym lepiej testuje im więcej danych otrzyma.

Ja zapisałem cały dysk w godzinę z hakiem.

> > żeby generator nie oblewał testów (gdy danych było za mało plik był zawijany i do testów był brane w kółko te same liczby, do
> > powodowało oblewanie testów). A i tak zawijał niektóre próbki, tzw. " rewounds".
> Temat jest trudniejszy, może generator na małych zapętlonych danych przechodzić test, na na długich oblewać.

W każdym razie wszystkie testy przy odpowiedniej ilości danych zdawał. Wystarczyło 50 GB danych, zapisanych w formacie dziesiętnym jako liczby 32-bitowe.

> Chyba najlepiej odtworzyć te same dane losowe co były użyte w programie, aby mieć pewność że program
> pracował na losowych danych które przechodzą testy statystyczne.

Używam tych samych danych. A mimo to w PractRand pełno testów jest niezdanych.

> Zadziała, ale jeśli tester nie wspomaga plików tekstowych, to trzeba samemu napisać program który zamieni dane tekstowe na binarne.
> Potem dam przykładowy kod w C++, może dziś wieczorem, to kilka linijek.

Wygenerowałem plik .data. Zapisałem tam liczby w formacie binarnym. Wszystko wskazuje na to, że to powinno działać. Może po prostu generator nie zdaje testów. Z drugiej jednak strony, jeśli Ty piszesz, że testowałeś generator nawet kilka dni, to jest nic w porównaniu z danymi, które ja dostarczyłem do testów, wygenerowanymi zaledwie w godzinę. Może po prostu jest ich za mało. Ale, czy 230 GB to za mało?

> 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.

[M.M.]

Ok.

Pobierz ten plik źródłowy i skompiluj konwerter.
https://github.com/mmarszik/01ToBin/blob/main/main.cpp

Potem uruchom tak:

TwójGeneratorZerIJedynek | ./01ToBin | ./PractRand stdin

Albo gorzej tak:

cat PlikZerIJedynek | ./01ToBin | ./PractRand stdin

Nie testowałem, jak nie zadziała, to będzie trzeba sprawdzić czy konwerter nie ma jakiś błędów

Pozdrawiam

[osobli...@gmail.com]

Jeśli zrobiłem wszystko dobrze, to mam debug error - "abort() has been called". Próbowałem opcji z plikiem .data.

[M.M.]

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

[osobli...@gmail.com]

W tej chwili poza tym komunikatem mam "-bash: ./PractRand: No such file or directory". Znaku końca linii do pliku nie wstawiałem, więc chyba nie powinno go tam być.

[osobli...@gmail.com]

Udało mi się to uruchomić komendą

cat plik.data | ./konwerter.exe | ./RNG_test stdin


rng=RNG_stdin, seed=0xe933a977
length= 32 megabytes (2^25 bytes), time= 3.1 seconds

Test Name Raw Processed Evaluation

BCFN(2+0,13-4,T) R= +3177 p = 8e-1388 FAIL !!!!!!!!
BCFN(2+1,13-4,T) R= +3148 p = 3e-1375 FAIL !!!!!!!!
...
[Low1/32]FPF-14+6/16:(0,14-4) R= +14.9 p = 4.0e-12 VERY SUSPICIOUS
[Low1/32]FPF-14+6/16:(1,14-5) R= +8.1 p = 1.3e-6 mildly suspicious
[Low1/32]FPF-14+6/16:all R= +19.0 p = 8.5e-16 FAIL !
[Low1/32]FPF-14+6/16:all2 R= +54.4 p = 1.8e-18 FAIL !
[Low1/32]FPF-14+6/16:cross R= +33.2 p = 6.6e-26 FAIL !!
...and 55 test result(s) without anomalies

Faili nadal jest dużo, komunikat systemowy "abort() has been called" nadal się pojawia, ale wykazuje więcej testów bez anomialii.

[M.M.]

Może PractRand kończy działanie po wykryciu tylu faili i konwerter ma błąd zapisu, no bo nie ma procesu do którego by mógł pisać - więc robi abort.

Można zrobić test z prostszym generatorem, np.:

//Dla 128 bitów
return ( next = (prev * a + b) ) >> 96;

//Dla 64 bitów
return ( next = (prev * a + b) ) >> 32;

Jeśli a i b są dobrze dobrane, to PractRand musi pracować bardzo długo zanim wykryje anomalie.

Pozdrawiam

[osobli...@gmail.com]

Nie potrafię zmodyfikować mojego programu, żeby generował bit po bicie, więc na razie nie sprawdzę, czy to ostatecznie działa. Pewnie będę potrzebował na to kilku dni lub tygodni, bo ledwo umiem programować.

[M.M.]

On Saturday, August 21, 2021 at 1:55:24 AM UTC+2, osobli...@gmail.com wrote:
> Nie potrafię zmodyfikować mojego programu, żeby generował bit po bicie, więc na razie nie sprawdzę, czy to ostatecznie działa. Pewnie będę potrzebował na to kilku dni lub tygodni, bo ledwo umiem programować.

To jest proste, tamten kod generatora zastąp tymi kilkoma operacjami arytmetycznymi co podałem.
Ale może wieczorem zrobię i wrzucę taki minimalny generator, i test tym konwerterem.

Pozdrawiam

[M.M.]

On Saturday, August 21, 2021 at 1:55:24 AM UTC+2, osobli...@gmail.com wrote:

> Nie potrafię zmodyfikować mojego programu, żeby generował bit po bicie, więc na razie nie sprawdzę, czy to ostatecznie działa. Pewnie będę potrzebował na to kilku dni lub tygodni, bo ledwo umiem programować.

U mnie przez ponad 1000 sekund nie było problemu:

./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= 64 megabytes (2^26 bytes), time= 2.4 seconds
no anomalies in 179 test result(s)

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

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

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

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

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

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

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

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

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

^C

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


Pozdrawiam

[osobli...@gmail.com]

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

nie pokazało niczego.

[M.M.]

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

[osobli...@gmail.com]

Co ma zwracać mój program? Bo generator:

> //Dla 128 bitów
> return ( next = (prev * a + b) ) >> 96;
>
> //Dla 64 bitów
> return ( next = (prev * a + b) ) >> 32;
>

Nie zwraca bitu po bicie. Nie będzie zwracał nawet liczb w postaci binarnej, tylko dziesiętnej.

[M.M.]

Trzeba zamienić na bity, potem na ascii i potem można przetestować konwerter - co robi ten program:
https://github.com/mmarszik/SimpPRNG/blob/main/main.cpp

Pozdrawiam

[osobli...@gmail.com]

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?

[osobli...@gmail.com]

Mam w tej chwili funkcję w Pythonie, która zwraca kolejno liczby 128-bitowe:

192066077656580258942348540382114420378
32279351617202730688729077252496792396
297915430637496012930348761181422042536
159283604400744055638172460588895391056
220821713004509824228660973423179477929
265401964602247200657488762091495142036
121949887341620150952131667637044765657

Mogę ją wywołać zadeklarowaną liczbę razy. Mogę to też przekształcić na bity:

10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010
11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100
11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000
1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000
10100110001000001011011100000110100111000110111101010000010011001010010010100110000011000110010000110011101001100011001110101001
11000111101010101000111100100000101100100110111111001110101100100001111101011001100001010000000111000110111000101011001010010100
1011011101111101011000110101000010100011000111000010010011110101001110111100011001001101111010001010000000101111110001111011001

I pewnie dam radę to pociąć na pojedyncze bity. Tak, żeby wypisywać:

1
0
0
1
0
0
0

Z każdym powtórzeniem. Mam nadzieję, że ten konwerter nie musi sam wywoływać programu n razy, tylko wystarczy, że program wywołany raz wygeneruje strumień bitów.

[M.M.]

Poniższe polecenie shell raz uruchamia konwerter, a konwerter działa do póki może czytać i pisać ze standardowego wejścia/wyjścia.

./Generator | ./Konwerter | ./Tester

Konwerter czyta zera i jedynki w formacie ASCII, nie toleruje żadnych innych znaków (spacji, enterów, etc).

Pozdrawiam

[M.M.]

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). Obojętnie skąd pochodzą te zera i jedynki - konwerter zadziała i
w dodatku powinien zadziałać poprawnie, bo przeszedł jeden test. Program może być napisany w
czymkolwiek, w Pythonie, w Javie, w C++, albo możesz odczytać do konwertera dane z pliku przy
pomocy polecenia bash/shell:

cat plik_tekstowy_zer_i_jedynek.txt | ./konwerter | ./tester

Tylko plik musi być duży żeby to miało sens, np. cały duży dysk 1-100TB.

Lepiej dać prosto z programu, bez zapisywania do pliku:

./Twój_program | ./konwerter | ./tester

[osobli...@gmail.com]

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

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

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.

[osobli...@gmail.com]

PS Gdy program wypisuje:

10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010
11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100
11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000
1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000

tak naprawdę nie ma nigdzie żadnego znaku nowej linii, czy wiersza.

[M.M.]

To powinno zadziałać.

[M.M.]

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

[osobli...@gmail.com]

Żeby uruchomić program trzeba wpisać:

python3 Collatzgenerator01.py | ./Konwerter.exe | ./RNG_test stdin

I znów dostałem komunikat:

"abort() has been called" (press retry to debug the aplication)

Po tym zignorowaniu lub ponowieniu wyskakuje:

RNG_test using PractRand version 0.93

RNG = RNG_stdin, seed = 0x9cd2b3e4

test set = normal, folding = standard(unknown format)

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

[osobli...@gmail.com]

PS Program w konsoli działa normalnie, wypisuje liczby binarnie:

10010000011111101001010010111110000111100110001101110000110101100001110110000100111010001001101001010101000001110001011010011010
11000010010001100011011101000100101100100110001010001101110111011010001010101110100010101010010011011111000111001101101001100
11100000001000000110110011000100101011000000101011111010111000111011010101011010100111000001100110011010111000110011110110101000
1110111110101001110100000000101101010111100010110011010010000110000001100100101000100101010111101010010011101010100110101010000

[osobli...@gmail.com]

PS2 print(binary) to część mojego programu, która wypisuje liczby w postaci binarnej.

[osobli...@gmail.com]

Swoją drogą program zadziałał po komendzie:

python3 Mojgenerator.py | ./RNG_test stdin

Ale znowu wystąpiły FAILE i ten sam błąd:

RNG_test using PractRand version 0.93

RNG = RNG_stdin, seed = 0xb223f1b6

test set = normal, folding = standard(unknown format)

rng=RNG_stdin, seed=0xb223f1b6
length= 128 megabytes (2^27 bytes), time= 3.3 seconds

Test Name Raw Processed Evaluation

BCFN(2+0,13-3,T) R=+17706724 p = 0 FAIL !!!!!!!!
BCFN(2+1,13-3,T) R=+8369402 p = 0 FAIL !!!!!!!!
BCFN(2+2,13-3,T) R=+4018669 p = 0 FAIL !!!!!!!!
BCFN(2+3,13-3,T) R=+1951923 p = 0 FAIL !!!!!!!!
BCFN(2+4,13-4,T) R=+1217378 p = 0 FAIL !!!!!!!!
BCFN(2+5,13-5,T) R=+754738 p = 0 FAIL !!!!!!!!
BCFN(2+6,13-5,T) R=+373439 p = 0 FAIL !!!!!!!!
BCFN(2+7,13-6,T) R=+229795 p = 0 FAIL !!!!!!!!
BCFN(2+8,13-6,T) R=+114286 p = 0 FAIL !!!!!!!!
BCFN(2+9,13-7,T) R=+69277 p = 0 FAIL !!!!!!!!
BCFN(2+10,13-8,T) R=+41033 p = 0 FAIL !!!!!!!!
BCFN(2+11,13-8,T) R=+20468 p = 1e-5195 FAIL !!!!!!!!
BCFN(2+12,13-9,T) R=+11745 p = 3e-2640 FAIL !!!!!!!!
BCFN(2+13,13-9,T) R= +5857 p = 4e-1317 FAIL !!!!!!!!
DC6-9x1Bytes-1 R=+7289719 p = 0 FAIL !!!!!!!!
Gap-16:A R=+3003944 p = 0 FAIL !!!!!!!!
Gap-16:B R=+15169911 p = 0 FAIL !!!!!!!!
FPF-14+6/16:(0,14-0) R=+4703480 p = 0 FAIL !!!!!!!!
FPF-14+6/16:(1,14-0) R=+79390 p = 0 FAIL !!!!!!!!
FPF-14+6/16:(4,14-2) R=+7118595 p = 0 FAIL !!!!!!!!
FPF-14+6/16:all R=+6490693 p = 0 FAIL !!!!!!!!
FPF-14+6/16:all2 R=+39503479195893 p = 0 FAIL !!!!!!!!
FPF-14+6/16:cross R=+28219067 p = 0 FAIL !!!!!!!!
BRank(12):128(4) R= +4256 p~= 2e-2264 FAIL !!!!!!!!
BRank(12):256(4) R= +8744 p~= 1e-4651 FAIL !!!!!!!!
BRank(12):384(1) R= +6353 p~= 2e-1913 FAIL !!!!!!!!
BRank(12):512(2) R=+12622 p~= 1e-3800 FAIL !!!!!!!!
BRank(12):768(1) R=+12316 p~= 2e-3708 FAIL !!!!!!!!
BRank(12):1K(2) R=+24891 p~= 5e-7494 FAIL !!!!!!!!
BRank(12):1536(1) R=+24672 p~= 4e-7428 FAIL !!!!!!!!
[Low1/8]BCFN(2+0,13-5,T) R= +9.8 p = 4.9e-4 unusual
[Low1/8]DC6-9x1Bytes-1 R= +50.0 p = 1.1e-28 FAIL !!!
[Low1/8]FPF-14+6/16:(0,14-1) R= +37.0 p = 1.4e-32 FAIL !!!
[Low1/8]FPF-14+6/16:(1,14-2) R= +25.8 p = 2.5e-22 FAIL !!
[Low1/8]FPF-14+6/16:(2,14-2) R= +15.9 p = 1.0e-13 FAIL
[Low1/8]FPF-14+6/16:(3,14-3) R= +7.9 p = 1.2e-6 mildly suspicious
[Low1/8]FPF-14+6/16:all R= +48.8 p = 2.7e-45 FAIL !!!
[Low1/8]FPF-14+6/16:all2 R=+504.6 p = 1.0e-174 FAIL !!!!!!
[Low1/8]FPF-14+6/16:cross R= +71.2 p = 2.2e-56 FAIL !!!!
[Low4/32]BCFN(2+0,13-5,T) R=+3546530 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+1,13-5,T) R=+1676322 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+2,13-5,T) R=+804897 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+3,13-5,T) R=+390941 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+4,13-6,T) R=+237394 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+5,13-6,T) R=+116954 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+6,13-7,T) R=+70419 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+7,13-8,T) R=+41511 p = 0 FAIL !!!!!!!!
[Low4/32]BCFN(2+8,13-8,T) R=+20637 p = 2e-5238 FAIL !!!!!!!!
[Low4/32]BCFN(2+9,13-9,T) R=+11814 p = 1e-2655 FAIL !!!!!!!!
[Low4/32]BCFN(2+10,13-9,T) R= +5881 p = 1e-1322 FAIL !!!!!!!!
[Low4/32]DC6-9x1Bytes-1 R=+1284826 p = 0 FAIL !!!!!!!!
[Low4/32]Gap-16:A R=+412185 p = 0 FAIL !!!!!!!!
[Low4/32]Gap-16:B R=+2520495 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(0,14-1) R=+631088 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(1,14-2) R=+12449 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(4,14-4) R=+705389 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(5,14-5) R=+14266 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(8,14-7) R=+743698 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(9,14-8) R=+14419 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(12,14-10) R=+535960 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:(13,14-11) R= +8504 p = 3e-3707 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:all R=+999316 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:all2 R=+451461539040 p = 0 FAIL !!!!!!!!
[Low4/32]FPF-14+6/16:cross R=+5271881 p = 0 FAIL !!!!!!!!
[Low4/32]BRank(12):128(4) R= +3718 p~= 5e-1978 FAIL !!!!!!!!
[Low4/32]BRank(12):256(2) R= +5148 p~= 1e-1550 FAIL !!!!!!!!
[Low4/32]BRank(12):384(1) R= +5018 p~= 1e-1511 FAIL !!!!!!!!
[Low4/32]BRank(12):512(2) R= +8862 p~= 8e-2669 FAIL !!!!!!!!
[Low4/32]BRank(12):768(1) R= +8376 p~= 1e-2522 FAIL !!!!!!!!
...and 60 test result(s) without anomalies

Traceback (most recent call last):

File "Collatzgenerator01.py", line 50, in <module>

print(binary)
BrokenPipeError: [Errno 32] Broken pipe

Pytanie, czy program przetestował poprawnie, to co miał przetestować? Mam wątpliwości.

[M.M.]

Jeśli Twój program wyświetla binarne dane, to zwyczajnie nie przechodzi testów, bo ma
za słabą losowość. Jeśli wyświetla dane tekstowe, czyli binarne znaki ASCII '0' i '1',
czyli binarnie 00110000 i 00110001, to nawet jak ma dobrą losowość, nie przejdzie
testu, ponieważ tylko jeden bit się zmienia losowo, reszta jest ciągle taka sama.
Może zapisz do pliku to co wyświetla Twój program i zobacz w edytorze hexadecymalnym
jakie tam są naprawdę dane - binarne czy tekstowe, czy nie ma znaków nowej linii, itd.

Pozdrawiam

[osobli...@gmail.com]

Zrobiłem hexdump pierwszych bitów:

python3 Mojgenerator01.py | hexdump -n4000 | head

0000000 3031 3131 3131 3130 3131 3031 3131 3130
0000010 3131 3030 3030 3131 3030 3131 3131 3030
0000020 3030 3130 3031 3131 3030 3030 3131 3130
0000030 3030 3130 3030 3030 3131 3131 3131 3131
0000040 3031 3130 3131 3031 3031 3131 3030 3030
0000050 3031 3030 3030 3031 3130 3130 3030 3131
0000060 3131 3131 3131 3031 3130 3031 3131 3131
0000070 3030 3130 3130 3030 3030 0a31 3131 3130
0000080 3131 3031 3030 3131 3131 3130 3031 3131
0000090 3030 3131 3030 3030 3030 3031 3030 3131

Traceback (most recent call last):
File "Collatzgenerator01.py", line 50, in <module>
print(binary)
BrokenPipeError: [Errno 32] Broken pipe

I nie wygląda to dobrze. Po pierwsze nie mogę zrobić hexdumpu 4000 bajtów. Czy ta komenda ma jakieś ograniczenie, czy program mi się wykrzacza? Po drugie, tak na oko, to nie są losowe bity. Nie wiem o co chodzi. Czyżbym się walnął w kodzie albo napisał aż tak beznadziejny generator?

[M.M.]

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

[osobli...@gmail.com]

> Jeśli Twój program wyświetla binarne dane, to zwyczajnie nie przechodzi testów, bo ma
> za słabą losowość. Jeśli wyświetla dane tekstowe, czyli binarne znaki ASCII '0' i '1',
> czyli binarnie 00110000 i 00110001, to nawet jak ma dobrą losowość, nie przejdzie
> testu, ponieważ tylko jeden bit się zmienia losowo, reszta jest ciągle taka sama.
> Może zapisz do pliku to co wyświetla Twój program i zobacz w edytorze hexadecymalnym
> jakie tam są naprawdę dane - binarne czy tekstowe, czy nie ma znaków nowej linii, itd.

Generuję liczbę w Pythonie:

liczba = 83866140218348733068398498750863724151

I konwertuję ją na liczbę binarną za pomocą:

binary = bin(liczba)[2:]

Otrzymuję:

111111000110000000011111110100101000111111111111010000101011110100001111100111010001001100101011111011010110110100111001110111

Ucinam pierwsze dwa znaki, bo inaczej miałbym dopisek:

0b111111000110000000011111110100101000111111111111010000101011110100001111100111010001001100101011111011010110110100111001110111

Może jednak wyświetla znaki tekstowe? Może każda "1" i każde "0" jest czytanie jako ASCII.

[M.M.]

Wygląda bardzo dobrze, ale nie jak dane binarne, ale jak dane tekstowe, czyli potrzebujesz konwertera. U mnie wygląda podobnie:

./SimpPRNG 1 300 | xxd
00000000: 3131 3030 3031 3031 3131 3030 3031 3131 1100010111000111
00000010: 3131 3030 3030 3031 3131 3130 3130 3131 1100000111101011
00000020: 3131 3030 3130 3031 3031 3130 3130 3030 1100100101101000
00000030: 3131 3130 3030 3131 3131 3030 3131 3131 1110001111001111
00000040: 3030 3030 3030 3030 3131 3131 3130 3031 0000000011111001
00000050: 3030 3031 3031 3130 3131 3131 3131 3130 0001011011111110
00000060: 3030 3030 3131 3131 3131 3130 3130 3031 0000111111101001
00000070: 3030 3131 3030 3030 3031 3130 3131 3030 0011000001101100
00000080: 3131 3030 3130 3131 3130 3130 3030 3130 1100101110100010
00000090: 3031 3030 3131 3031 3131 3031 3131 3131 0100110111011111
000000a0: 3030 3130 3130 3131 3130 3131 3031 3131 0010101110110111
000000b0: 3031 3030 3131 3031 3130 3031 3130 3030 0100110110011000
000000c0: 3130 3031 3131 3130 3030 3130 3130 3131 1001111000101011
000000d0: 3030 3030 3031 3030 3030 3031 3131 3031 0000010000011101
000000e0: 3031 3130 3130 3031 3131 3131 3130 3131 0110100111111011
000000f0: 3131 3131 3030 3030 3031 3031 3130 3031 1111000001011001
00000100: 3031 3131 3131 3130 3030 3130 3130 3130 0111111000101010
00000110: 3031 3031 3030 3030 3030 3031 3031 3131 0101000000010111
00000120: 3131 3130 3030 3031 3130 3031 111000011001

Tylko u CIebie jest znak '0a31' na którym zapewne wywala się konwerter.
Zobacz skąd jest to 0a, wywal i uruchom przez konwerter.

Pozdrawiam

[M.M.]

Po tym co wyświetlił hexeditor na pewno to są znaki ascii.

[M.M.]

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

[osobli...@gmail.com]

Pierwsze 100 liczb. Nie widzę tam żadnych podejrzanych znaków:

101111011110110111000011001111000001101100001101000100001111111110011110101100001000001001010011111111100110111100010100001
11011110001111011011001100000010001110101100111101000001101000110001010101010001101110011101100101101110101000010001011001110000
10111100011001100111011010111101100111100101101101111010110111011011111100110110001011101100100011110011101001011111011111111
1110100101111111010011110000010111110000010101101111101110100011000011011000101001111100010100011001111111011111000100110111011
1100101010011011111101100101100100011011110000101010111110000000110101010111111000101001011111010010010011000100110110010101
10000001111001110101000000010000111010010011000101101011100000101111010010011011111101010101101011100101110001001011011011110110
101000100111010010101000110100100110010001001101001010111110000000110001111101010010111100010110000011100010100000110001100011
1110110100111110111101011111100011011011011010011111000100000100111000100101111100100000101001001011001100000110100100010100
100001010100000000011001111110010101001000001010010000010110001000110111010110000110011111010011000001101010010111110101110101
1000010100010011001100000010110100001000011111010001011001100000001011100011000000101110110001111100010000100100001101101101000
11110000101001110110110000010100100111110010000111010011010000010110010011010110010011010000011110011100010001100111001110010001
10111111001111111110010001110111001101101100101001111110011111010001011001101000111010101000110011111001101100001010001000111110
1100110110101101011111110000000110010010001110011111110101000100100101001011111000111011101110101110011000101100111010010111110
11010011000110101000000010111101110101000011111000001001110000101100010101110111111111101110100111110000100010100100110000000110
10111100110010100110111111011011010011011011100011101101010100101111000100111010001001000001010111110010001101011010101101001110
10001010110101001000010110100011100111111111001011010101111001000110010111010000101100100010110001110101101100100110111010110111
1111110000110011111010110111110010100011000000000110101111101101111101000011011110001100011000011000011000011011010001010101
11000011110111000000110011000000100111011111010001110010010000000101001110011111110000101011001010111100011101110101011000011010
110100100101001011001001110100010111101101110010110010010101110000000101001111010001000100100101101110010000001000011100101000
1110001010010100000010100101110010011110100010111111000110011110010011011001111010000001101001011110101001000010000100110011000
11110011010111000010101100100111011000111000000111100000000111001100101011100001000101100101110101101010111000110001101110110001
11011010110011101101001011010101000111011111001010011001111001010000001011110011110011111001000111111111010110111010100001001100
1100110100000001000011101010111110010101011101101001010100110001011111100000001110101011110101010001010101000011001100010110010
10010000011111000000000000111000000110110101010101000110011101110001111101010111110010111011101000001000111110001110100101101101
1000011011010110100001111111101100110000111111101000100001000110010001101011101011010111100111111000000001011000011000101100000
1110101100011010100111111011010101111110100111011010110001110011100010111110101111001111110001011010101110101110010101110010111
1111011110101010000100101111100101000000101110000010110101001011111010111001010111100110110000001100000000000100001111001100000
111010001101111000000111110101100111010011010110101110111000011010010000010000011011001110010111000001111000110000010010011100
11001100011010100001010011111100011100100001011100100101111010001010101000011101011000110101001100110110111100111101111010
11110100100101100011100101011011010010100000000111110000010110110010000000100000011011000001010100010100010010001100000101101
10010110111000000001000011011110100100101000011010110000100010110000100111001100110001110110010010101000100001011001110110101000
1001100110111000110111101001010100011000011110110000010101001010000001110011111000001101011000110010110101100101110110101010100
1101011011011000010100110010011100111111100101000000010011110011100001011100000111111001001100010011100100000100110100010001001
11000011110110001000011100001000001010100011011111101101000011100110011111111100110010011111111011011000010000010001010011100101
11000000010011001100111011111001000100011110110111001111110001100001000011100011111100010110100001001010111110101111000111100111
10010001111110111101111100011101001001111101101000010110000000000100011100010111000011011101100010101001110000111101101111010100
1010110101100000010101111110101110010111000001000001000100101101001001001110000111110011010011100100111001111111101010110000
11000010010011111110101010000110110011001110001001110101010011101001011111110101100000100100010101110011101001111011100111111000
1100011001001010010101101111011001001100110111011101100001010001110011001010110101010100010001100110001110111101100110010100110
1100101101000010011010000011001110000101111100001110010110000011111110010001100010010000000000000011111000111101111001111101111
10110100110001100100010111111011011000000110101111011011110100111000001010011011111111100000010011010110001110110000110001111101
11000110100110001010001100011111000100011010111110101010000111110101100000100011110011111101010111100001000111110001010000011000
10001011101111011010000110110010101101101101100011001100100011111011001101101011100110110011100101011001110100110000111100111101
10000010100110000011110110011100101111100010110001111000100011110011100010000010100000111111100001101011011100011000010110011
101101001001010111100001100000011010101001011110010010110101111001110001110011011010100010010111111000100100000101010110001101
110001110010100001011010110111101100000011111010010110000100101110110100110111111111101001001100011110111000111111111101100111
1101110010111100000101101000111100110101111101100100001011001000101000110111000010010110111001010110011011111011000001010001111
1100111101111001001110111110100011111110111111010011111101000011001011100101110110110011101111001100101101010110111100110000
11111110110001000001011111010011001010101000000011110011100001101111000110101010011111110101111010011000111100101000001100100000
1100000100101010011011110100010100011101100001110010110100110000111010110011000000010000110011011101110111011110000001101000100
10100111111001001010000100001000111010101101000101001001010100001011111100001100101111001001100000010011001100010101100100001101
11100101100110011101000101001011101010010000010100000111100011001011110101000110110100011100100001001011100000000000101001100010
1101010000101101110101001011010111100100001010110001000111101010101111101100101001001110101000011101100010111011100011111010001
11111111111001010000011011100101100001100110111110100101100000111100111111000010011101001000101101000100101100001110100011011000
111101000100000101100111100101001100000001110111000110111110111010011101000110101001101001011100011010111100001110110110110010
1100010000001111111011001101111010100100011111000111010001010100000111001010100111001010011010001000000010010101100111100111010
10011010000001100010110011000110011000011001000110110010010110101001111011010011011111011000001101011101110111001111001110001011
11010000100100000110100110001001110011110100101100101010010101110100100110100000101110010101110111111111100111101001000010110
1111000011010110000111110010010010010101010000011001111001111000110001000101100100110111000100110110011111000101010110010010101
10001111111110100001011010110110010110000010101111111010001111101010011100110101000010111000111101111101100010101011111011101111
1101111000010111111100010011001001010010100001111011110100110100011010110100011010001001110001100101101101000101000111110010100
10011010110010100111111011001010101101000111110011011011011111111001101010000001110101111100011011101011111010101100010110100110
1110011111101110111010001100101111100001101010011101000000101010011000001000101010011011110111000000100000010010110001000000001
11000100111110010000100011111001110100110000001110111000110001101001100111001111110011001110011001010111111000111110000001000111
11001010001001101000011111100111001011001110000000110111110011011101101111111010000100000111010111111001011111110101000100010011
10110110110010110100110011010011000111111101001010101001111010110110111100010000111000100000010010001100001011000010000011
10001011111011011100111000000111101101000111101000111110111101100000110101110110010100000001010011000110010010111011110010001
10011011101001010111001010000010110111001111001111001001101000001100111011111111110110010001111000111010000001100100001010111001
11000101101110100010110010111001011101000001111111000111101101001111101110010100110010000110100010011101110011010011110101001110
11110100001100111110011001110100101010111011100111110000010110011010111010000010100000111010010101101000101000001010000010101110
11111100101010110101100011000101101011101000110101011001010111001001111000111010101011110001110010110111001001101100011110000100
10101111110101110001001110000101101011100000100100110100111000100111001101011001110010100001010000111011100010000111011001
100111111011101111111000000110100111000101100110001111010110001001000101010100010011011001000111000011101001010000011010010000
111100001100101001001011110100111100000111001110110010110100001001100110010110110001000111111000100000111110110001010000111010
10000110111000010111001010100110000101001110110110001110010100001111110110111011100110010101011000001010110110111010010001111111
100011111111011011100111110111110001001010011111011001001000001111000101111100011100101110011010110110010001101100101010111
101010011011010010010111101011101011001001001000111100010001100101111000010101001110000110001101011000110000110100101111000
10111111100000100111100100100111010010110110101010000000110000001000000010110010011111000110010001011010110011100111110100011011
11100111101010101011111001101011001000111001101010100100111110011111100000011100111110011011010010111110101011110000001100100001
10100101110110111111011011011111111011001101011100111011101011001011110101010100001110010100001010101101110010111100110111010
100011000011101011000011100110110010101001011101000111100100000011001011101101110101100001111001111101101010001100111001011
11110011110100001101101110111110111110100001111010111001110101000011110100000111011101001011110100010111001000000011001010010000
10111010101011000011001101110001001110010101110001010011011010101011001111100011010110110001110110011111101100110001100011010
11001101111001100000000000110111000101110010011001101001101100100100001011011101110101110111100011011101011100000110100001100001
1110000101000101011001010100110000010111111011111111101101001101011110011011000000011111110110110100111001010001111100100101110
1011110010001011001001101001011000111110000111000000110100010011110110010100010010010101110101000011010001100000101010000100001
11110111101010110110000110100110010101111010000100001111101010001111101010111011100111101010001110000100000011110111101000111001
101010001111100101100001100100100110100000100110010101000101100000100111001001111111000001110001110001101110110000110100101101
1011000010100010100001111101101111110000001011111110000011111101010100010000111000100110100011111100000001011111001111101111000
10000111101111111010110101110110100000110111011001011011000100111011111011101110111010110101000110100100101010001000110110010101
1000000101011010010000000111011100100110000100010000110111111101010110011000100100100111010010000010010000110110010010010010111
1000010011101000110101001010000100011101101100110001001100011000101010110011001000101111000111110111111100110010110010110010110
1011101111111100110100000111000101010100100010100011010101001100001110010101100111000101001000000110010111011100001111011100011
10101001100000011010011001000001001101111100010010100111011111000010001100100001111010000011000100011100101011000100111111100111
11011110111111101100110000111101011010100101001111111101110001111101100101111100010001111111011011001101110110100100110000111011
100110010000010001001110101010010100110100011011110010100001010111100000100101100101101110111011110011110111110111110011111
100110111010001100111100101011000010001010000111000101000001111010000101111010101010010001110001101111100111010100001000100010
11001100110101100011111010111110000100001100101110111000110110111011111100010011000100101010011101001101000100001001111111000011
1001100101011110011010010001010011011010111100001111001100000000011011000101010101001001011010011110010100000111111110100010011
10011001100001111010011101000111011001010100010110000010011011100001000101101111011000101000100010111111111010111110010010000110

[M.M.]

A ja widzę że wszystkie liczby zaczynają się od jedynki, nie są równej długości, a znaku nowej linii po prostu nie zobaczysz, wydać po prostu nową linię, zobacz jak to wygląda u mnie:


./SimpPRNG 1 3000
110001011100011111000001111010111100100101101000111000111100111100000000111110010001011011111110000011111110100100110000011011001100101110100010010011011101111100101011101101110100110110011000100111100010101100000100000111010110100111111011111100000101100101111110001010100101000000010111111000011001001110011110101101011111000010010110011010000111010000011010101000110001000001100011110111000111001111100010110111010011001011001101100000100110110001101101111110010100001011010111011101101011111110000110110101110101101110000010000111001001110001000110110001111001100010001001101100110001010001001111001110100101001000001101010100010111110010010111001001100000100000110110110011010111000010101101001111010110100010001011000000010100111111010111001100111000111011001111001110101110100000100100100110010011111011111011000011001010101101100110001010001011100001001010010010000001110101010100110100101110101111000100011100000000011000000010111000001011010011011101100010001010111000001001001100110100010111100101101111100000011110110000100111010111000010110111100111001011110000010001001011100001010100111110001110100010100000011111110111111001111110100010011111001111000110100011000011011001111000110001000010100111000000001000001110100101111001010111101000001100111011001110110111111010001100110100010001100101010000100100011010010000000110010101110000111101011110010111001001101010101111011100110110011010101010001101101010101010000011000101000110110011100110101001101000111110100111010011000111010000111101110101111011111110101011010001000111101100110100001100111100100101000111011101110010110001101011100110101110010111100110000000011100001110101111100110100001010111110100101001110110111111101111000011100100100010011100001100001111011110111011000001111100011101001101110011110010001011111001100100111101101011111100010001110000100101011000010000000101111101100000011010101010000101111011000111000010001111011001010000011011000011000110111100111110111001111111000001100010111101010001000000111000011110110011111010110100011010101111000000001011000101111101000001011110110111111111000010010100111111010101110110101111010111101100010011001000001001101001111000111011111101001011000110110000011001000110111110000011111100101110011001010011100110001110100110010101110000101000011101011101111101111110110000010100011001001110111000111011011100011100100011111110101000010000010110001000001000100001101001000010000001000001110001000010000101010111111011111110010010111011101010111000100000010011010111001101011001100010010100010100000110011000101100101101100011011101100010010100101101101111000110111001000100111110111100100010100100101100100010100000010100110000100111101110010000101011010001101011010110111001001110001011000011000100000010000100110101101101111100110100100111100010000101011111011000111010110110110110110101001000111011000110100010110110101010101111010111111001111000110010000011010010101010001000100001101111111111111101000100010101100101100011110001011100011011010001101010010001100000

Pozdrawiam

[osobli...@gmail.com]

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)

[osobli...@gmail.com]

Ok, czyli u mnie najwyraźniej jest nowa linia, pomimo, że nie została wstawiona. Jeżeli te same dane zapisuję wprost do pliku, to wyglądają tak jak Twoje. Ale w terminalu są wypisywane jedna pod drugą, pomimo, że ja żadnej nowej linii nie wstawiam.

[osobli...@gmail.com]

O ile rozwiązanie na dopisane z powrotem uciętych zer można znaleźć, to jak rozwiązać problem nowej linii - nie wiem. Każda iteracja pętli generuje liczbę, którą po prostu wypisuję:

print(binary)

Nie wiem jak można to zrobić inaczej. Zrobić z tego stringa i sklejać to w jednego wielkiego stringa? Raczej nie starczy pamięci na takiego stringa. Wydaje mi się, że nie powinienem w ogóle tego wypisywać za pomocą print, tylko stworzyć funkcję, która będzie zwracać liczbę. Wtedy nie będzie konwersji na ASCII, ani nie będzie znaków nowej linii, bo liczby nie będą wypisywane w terminalu, ani nigdzie. Na razie nie wiem jak taką funkcję napisać. Jutro spróbuję to zrobić.

[osobli...@gmail.com]

Jednak tego raczej nie przeskoczę. Print zawsze będzie wypisywał liczbę linijka po linijce i będzie się tam prawdopodobnie pojawiać znak nowej linii, pomimo, że ja go nie wstawiam. Nie będzie się pojawiać tylko podczas zapisu do pliku funkcją write. A wywołanie funkcji bez printa ani write nic nie zrobi i nie poda nigdzie żadnych liczb. Chyba, że można jakoś podać dane do konwertera bez używania printa.

Ewentualnie może coś jeszcze innego odpowiada za znak nowej linii. Bo przecież dane podawane do konwertera nie są nigdzie wypisywane, tak jak w terminalu, więc skąd tam i po co znak nowej linii? Terminal wstawia znak nowej linii po każdym wywołaniu pewnie po to, żeby to było czytelne. Ale, czy terminal może wstawiać znak nowej linii do konwertera, po każdorazowej iteracji mojego programu? Może by to zrobić jakoś inaczej, niż przez terminal. A może łatwiej będzie napisać od podstaw program w C++.

W 200 GB pliku w formacie .data pierwsze znaki wypisuje mi jako:

1011110111101101110000110011110000011011000011010001000011111111100111101011000010000010010100111111111001101111000101000011101111000111101101100110000001000111010110011110100000110100011000101010101000110111001110110010110111010100001000101100111000010111100011001100111011010111101100111100101101101111010110111011011111100110110001011101100100011110011101001011111011111111111010010111111101001111000001011111000001010110111110111010001100001101100010100111110001010001100111111101111100010011011101111001010100110111111011001011001000110111100001010101111100000001101010101111110001010010111110100100100110001001101100101011000000111100111010100000001000011101001001100010110101110000010111101001001101111110101010110101110010111000100101101101111011010100010011101001010100011010010011001000100110100101011111000000011000111110101001011110001011000001110001010000011000110001111101101001111101111010111111000110110110110100111110001000001001110001001011111001000001010010010110011000001101001000

Bez żadnych nowych linii. Po uruchomieniu cat mojplik.data | ./Konwerter.exe | ./RNG_test stdin

Nadal dostaję "debug error", "abort() has been called" oraz pełno faili:

[Low1/32]BCFN(2+3,13-8,T) R=+583.2 p = 6.0e-149 FAIL !!!!!
[Low1/32]BCFN(2+4,13-8,T) R=+546.4 p = 1.3e-139 FAIL !!!!!
[Low1/32]BCFN(2+5,13-9,T) R=+621.0 p = 1.2e-140 FAIL !!!!!
[Low1/32]BCFN(2+6,13-9,T) R=+647.6 p = 1.2e-146 FAIL !!!!!
[Low1/32]DC6-9x1Bytes-1 R= +54.5 p = 3.5e-31 FAIL !!!
[Low1/32]FPF-14+6/16:(0,14-4) R= +14.9 p = 4.0e-12 VERY SUSPICIOUS
[Low1/32]FPF-14+6/16:(1,14-5) R= +8.1 p = 1.3e-6 mildly suspicious
[Low1/32]FPF-14+6/16:all R= +19.0 p = 8.5e-16 FAIL !
[Low1/32]FPF-14+6/16:all2 R= +54.4 p = 1.8e-18 FAIL !
[Low1/32]FPF-14+6/16:cross R= +33.2 p = 6.6e-26 FAIL !!
...and 55 test result(s) without anomalies

Swoją drogą to co zwraca funkcja bin() i jest zapisywane do pliku to string, więc pewnie jest w formacie ASCII.

[M.M.]

On Sunday, August 22, 2021 at 5:08:38 AM UTC+2, osobli...@gmail.com wrote:
> Jednak tego raczej nie przeskoczę. Print zawsze będzie wypisywał liczbę linijka po linijce i będzie się tam prawdopodobnie pojawiać znak nowej linii, pomimo, że ja go nie wstawiam. Nie będzie się pojawiać tylko podczas zapisu do pliku funkcją write. A wywołanie funkcji bez printa ani write nic nie zrobi i nie poda nigdzie żadnych liczb. Chyba, że można jakoś podać dane do konwertera bez używania printa.
>
> Ewentualnie może coś jeszcze innego odpowiada za znak nowej linii. Bo przecież dane podawane do konwertera nie są nigdzie wypisywane, tak jak w terminalu, więc skąd tam i po co znak nowej linii? Terminal wstawia znak nowej linii po każdym wywołaniu pewnie po to, żeby to było czytelne. Ale, czy terminal może wstawiać znak nowej linii do konwertera, po każdorazowej iteracji mojego programu? Może by to zrobić jakoś inaczej, niż przez terminal. A może łatwiej będzie napisać od podstaw program w C++.
>
> W 200 GB pliku w formacie .data pierwsze znaki wypisuje mi jako:
>
> 1011110111101101110000110011110000011011000011010001000011111111100111101011000010000010010100111111111001101111000101000011101111000111101101100110000001000111010110011110100000110100011000101010101000110111001110110010110111010100001000101100111000010111100011001100111011010111101100111100101101101111010110111011011111100110110001011101100100011110011101001011111011111111111010010111111101001111000001011111000001010110111110111010001100001101100010100111110001010001100111111101111100010011011101111001010100110111111011001011001000110111100001010101111100000001101010101111110001010010111110100100100110001001101100101011000000111100111010100000001000011101001001100010110101110000010111101001001101111110101010110101110010111000100101101101111011010100010011101001010100011010010011001000100110100101011111000000011000111110101001011110001011000001110001010000011000110001111101101001111101111010111111000110110110110100111110001000001001110001001011111001000001010010010110011000001101001000
>
> Bez żadnych nowych linii. Po uruchomieniu cat mojplik.data | ./Konwerter.exe | ./RNG_test stdin
>
> Nadal dostaję "debug error", "abort() has been called" oraz pełno faili:

Może tam znajdziesz odpowiedź:
https://www.techiedelight.com/how-to-convert-an-integer-to-a-binary-string-in-python/
https://stackoverflow.com/questions/493386/how-to-print-without-a-newline-or-space

[osobli...@gmail.com]

niedziela, 22 sierpnia 2021 o 10:39:55 UTC+2 M.M. napisał(a):
> On Sunday, August 22, 2021 at 5:08:38 AM UTC+2, osobli...@gmail.com wrote:
> > Jednak tego raczej nie przeskoczę. Print zawsze będzie wypisywał liczbę linijka po linijce i będzie się tam prawdopodobnie pojawiać znak nowej linii, pomimo, że ja go nie wstawiam. Nie będzie się pojawiać tylko podczas zapisu do pliku funkcją write. A wywołanie funkcji bez printa ani write nic nie zrobi i nie poda nigdzie żadnych liczb. Chyba, że można jakoś podać dane do konwertera bez używania printa.
> >
> > Ewentualnie może coś jeszcze innego odpowiada za znak nowej linii. Bo przecież dane podawane do konwertera nie są nigdzie wypisywane, tak jak w terminalu, więc skąd tam i po co znak nowej linii? Terminal wstawia znak nowej linii po każdym wywołaniu pewnie po to, żeby to było czytelne. Ale, czy terminal może wstawiać znak nowej linii do konwertera, po każdorazowej iteracji mojego programu? Może by to zrobić jakoś inaczej, niż przez terminal. A może łatwiej będzie napisać od podstaw program w C++.
> >
> > W 200 GB pliku w formacie .data pierwsze znaki wypisuje mi jako:
> >
> > 1011110111101101110000110011110000011011000011010001000011111111100111101011000010000010010100111111111001101111000101000011101111000111101101100110000001000111010110011110100000110100011000101010101000110111001110110010110111010100001000101100111000010111100011001100111011010111101100111100101101101111010110111011011111100110110001011101100100011110011101001011111011111111111010010111111101001111000001011111000001010110111110111010001100001101100010100111110001010001100111111101111100010011011101111001010100110111111011001011001000110111100001010101111100000001101010101111110001010010111110100100100110001001101100101011000000111100111010100000001000011101001001100010110101110000010111101001001101111110101010110101110010111000100101101101111011010100010011101001010100011010010011001000100110100101011111000000011000111110101001011110001011000001110001010000011000110001111101101001111101111010111111000110110110110100111110001000001001110001001011111001000001010010010110011000001101001000
> >
> > Bez żadnych nowych linii. Po uruchomieniu cat mojplik.data | ./Konwerter.exe | ./RNG_test stdin
> >
> > Nadal dostaję "debug error", "abort() has been called" oraz pełno faili:
> Może tam znajdziesz odpowiedź:
> https://www.techiedelight.com/how-to-convert-an-integer-to-a-binary-string-in-python/
> https://stackoverflow.com/questions/493386/how-to-print-without-a-newline-or-space

Udało mi się uzupełnić zera w zapisie binarnym i usunąć nowe linie podczas wywoływania print. Bez konwertera mam nadal dużo faili (bez błędu), z konwerterem nawet kilka faili więcej i nadal wywala błąd abort().

Wciąż prawdopodobnie jest problem w tym, że funkcje konwersji na format binarny "converting an integer to a binary string". I mam tam stringi, czyli zera i jedynki z formacie ASCII.

[osobli...@gmail.com]

Mam jeszcze taki pomysł, żeby przekonwertować moje liczby pseudolosowe na znaki ASCII, a nie jak dotychczas tylko na szczególne znaki ASCII w postaci samych zer i jedynek. Wtedy będę miał strumień losowych znaków ASCII. Następnie te znaki można przekonwertować na bity, jeżeli znajdzie się taki sposób.

[M.M.]

On Sunday, August 22, 2021 at 3:08:25 PM UTC+2, osobli...@gmail.com wrote:
> Mam jeszcze taki pomysł, żeby przekonwertować moje liczby pseudolosowe na znaki ASCII, a nie jak dotychczas tylko na szczególne znaki ASCII w postaci samych zer i jedynek. Wtedy będę miał strumień losowych znaków ASCII. Następnie te znaki można przekonwertować na bity, jeżeli znajdzie się taki sposób.

A jakby tak jeszcze skompresować zipem?

[osobli...@gmail.com]

W jakim celu ta kompresja?

Po wygenerowaniu danych do pliku data i wrzuceniu w konwerter terminal wyrzuca krzaki:

n U I?U 9;?AXe@"^Kev6*mڗqdp<1 o{ mg }5 H&' X %p_Tfl Y~ pVjkOKr }zo1Fle F c?ybq8\N V d:4[ւz~ 9ueVtlڔ:ą@T>N6@r(fo郳g41)n$ѤJIM 6hc %xӺj ]k<g(<3 +3. =<Y mf~; PP|Ƶ W%-vu' ` oKn2#Qegor"a + Ma%v |/ցtr z> l pҞ% l?+uLA{U K˜N%dV eT^ ~ ۗXwUjF xr{`qk�� :l }g]<A\8 $4D "6@ X{g ijf$un)u cuفry SnsNhg㸚2\ĥ pBy W h*@Ἶ��NxoLlQԟzFD4Ĭ.g`4n[C!4 *<>: _.v?$]9P; ўfPa? WGQ@js n NL4>5q2G[D 材Z{NE!>c` + > XGv [۽*1&
;9N) x j9ɓL` =h]eƉ{�� $P.ͶZi Y| FکUU+Nvwn# ^R@؆Y0 e*u4 l9zMj GICמ,
]i<Jq(ܖ4 ʺhJXzt f-h:[^T:,Cڬ4@8~nXI: R&sSceN C `<+=~ w <S#w}SǟM^ O4˪EMƞiq- "ElA<eX
ӔbeK94a}Բ6A*

Czyli wygląda na to, że działa poprawnie. Te same pliki, gdy są mniejsze niż około 1 GB skutkują nierozpoczęciem się testów i komunikatem:

RNG_test using PractRand version 0.93

RNG = RNG_stdin, seed = 0xae0bb968

test set = normal, folding = standard(unknown format)

Segmentation fault (core dumped)

Dla większych niż 1 GB otrzymuję wciąż dużo faili i standardowy komunikat "abort()":

RNG_test using PractRand version 0.93

RNG = RNG_stdin, seed = 0x9c049a18

test set = normal, folding = standard(unknown format)

rng=RNG_stdin, seed=0x9c049a18
length= 32 megabytes (2^25 bytes), time= 3.1 seconds

Test Name Raw Processed Evaluation

BCFN(2+0,13-4,T) R= +85.2 p = 3.7e-37 FAIL !!!
BCFN(2+1,13-4,T) R= +77.8 p = 6.2e-34 FAIL !!!
BCFN(2+2,13-5,T) R= +79.5 p = 2.6e-31 FAIL !!!
BCFN(2+3,13-5,T) R= +83.6 p = 6.3e-33 FAIL !!!
BCFN(2+4,13-5,T) R= +80.2 p = 1.4e-31 FAIL !!!
BCFN(2+5,13-6,T) R= +99.5 p = 1.6e-34 FAIL !!!
BCFN(2+6,13-6,T) R=+102.2 p = 1.9e-35 FAIL !!!
BCFN(2+7,13-7,T) R=+121.8 p = 2.9e-37 FAIL !!!

Spróbuję jeszcze raz wygenerować plik 200 GB. Dlaczego wielkość pliku robi różnicę?

[M.M.]

On Sunday, August 22, 2021 at 8:59:10 PM UTC+2, osobli...@gmail.com wrote:
> niedziela, 22 sierpnia 2021 o 18:41:50 UTC+2 M.M. napisał(a):
> > On Sunday, August 22, 2021 at 3:08:25 PM UTC+2, osobli...@gmail.com wrote:
> > > Mam jeszcze taki pomysł, żeby przekonwertować moje liczby pseudolosowe na znaki ASCII, a nie jak dotychczas tylko na szczególne znaki ASCII w postaci samych zer i jedynek. Wtedy będę miał strumień losowych znaków ASCII. Następnie te znaki można przekonwertować na bity, jeżeli znajdzie się taki sposób.
> > A jakby tak jeszcze skompresować zipem?
> W jakim celu ta kompresja?

Potem wystarczy zdekompresować i można testować - żartowałem odnośnie tylu zmian
formatu. Myślałem że po prostu masz coś gotowego co daje zera i jedynki w formacie
ASCII - napisałem więc dla Ciebie konwerter do formatu binarnego który jest zgodny z
formatem PractRand. Wielokrotne zmiany z formatu do formatu nie mają sensu, jeśli
możesz to wypisuj od razu binarnie dla PractRand.

> Po wygenerowaniu danych do pliku data i wrzuceniu w konwerter terminal wyrzuca krzaki:
>
> n U I?U 9;?AXe@"^Kev6*mڗqdp<1 o{ mg }5 H&' X %p_Tfl Y~ pVjkOK r }zo1Fle F c?ybq8\N V d:4[ւz~ 9ueVtlڔ:ą@T>N6@r(fo郳g41)n$ѤJIM 6hc %xӺj ]k<g(<3 +3. =<Y mf~; PP|Ƶ W%-vu' ` oKn2#Qegor"a + Ma%v |/ցtr z> l pҞ% l?+uLA{U K˜N%dV eT^ ~ ۗXwUjF xr{`qk�� :l }g]<A\8 $4D "6@ X{g ijf$un)u cuفry SnsNhg㸚2\ĥ pBy W h*@Ἶ��NxoLl QԟzFD4Ĭ.g`4n[C!4 *<>: _.v?$]9P ; ўfPa? WGQ@js n NL4>5q2G[D 材Z{NE!>c` + > XGv [۽*1&
> ;9N) x j9ɓL` =h]eƉ{�� $P.ͶZi Y| FکUU+Nvwn# ^R@؆Y0 e*u4 l9zMj GICמ,
> ]i<Jq(ܖ4 ʺhJXzt f-h:[^T:,Cڬ4@8~nXI: R&sSceN C `<+=~ w <S#w}SǟM^ O4˪EMƞiq- "ElA<eX
> ӔbeK94a}Բ6A*

>
> Czyli wygląda na to, że działa poprawnie.

Nie wiem, ale u mnie prosty generator wraz z tym konwerterem przechodzi kilkugodzinne testy.

> Te same pliki, gdy są mniejsze niż około 1 GB skutkują nierozpoczęciem się testów i komunikatem:
> RNG_test using PractRand version 0.93
> RNG = RNG_stdin, seed = 0xae0bb968
> test set = normal, folding = standard(unknown format)
> Segmentation fault (core dumped)

Nie wiem dlaczego, czy używasz komendy:
cat plik.bin | PractRand stdin
?

> Dla większych niż 1 GB otrzymuję wciąż dużo faili i standardowy komunikat "abort()":

Powinno działać dla dowolnie dużych danych przy pomocy komendy:
Generator | Konwerter | Tester

Ale jak Tester przestanie czytać po failach, to konwerter nie może pisać i robi abort.
Może spróbuj wersji która nie robi abort gdy nie może pisać:
https://github.com/mmarszik/01ToBin/blob/main/main.cpp

Nie wiem gdzie jakiej komendy używasz.

> RNG_test using PractRand version 0.93
> RNG = RNG_stdin, seed = 0x9c049a18
> test set = normal, folding = standard(unknown format)
> rng=RNG_stdin, seed=0x9c049a18
> length= 32 megabytes (2^25 bytes), time= 3.1 seconds

Zwórć uwagę, że 2^25 to dużo mniej niż 1GB, a już był jakiś abort, nie
wiem jaki program daje abort, bo używasz trzech programów. Jeśli
konwerter daje abort, to spróbuj powyższej wersji.

> Test Name Raw Processed Evaluation
> BCFN(2+0,13-4,T) R= +85.2 p = 3.7e-37 FAIL !!!
> BCFN(2+1,13-4,T) R= +77.8 p = 6.2e-34 FAIL !!!
> BCFN(2+2,13-5,T) R= +79.5 p = 2.6e-31 FAIL !!!
> BCFN(2+3,13-5,T) R= +83.6 p = 6.3e-33 FAIL !!!
> BCFN(2+4,13-5,T) R= +80.2 p = 1.4e-31 FAIL !!!
> BCFN(2+5,13-6,T) R= +99.5 p = 1.6e-34 FAIL !!!
> BCFN(2+6,13-6,T) R=+102.2 p = 1.9e-35 FAIL !!!
> BCFN(2+7,13-7,T) R=+121.8 p = 2.9e-37 FAIL !!!
>
> Spróbuję jeszcze raz wygenerować plik 200 GB. Dlaczego wielkość pliku robi różnicę?

Nie wiem, ale powinno działać bez pośrednictwa pliku dyskowego. U mnie działa kilka
godzin i nie ma faili ani abortów. Może jakaś wersja PractRand nie kompiluje się poprawnie
jakimś kompilatorem, albo nie działa pod jakimś systemem? Osobiście uruchamiałem
PractRand na kilku linuxach i na kilku konfiguracjach sprzętowych - gołym okiem żadnych
problemów nie zaobserwowałem, podobno jest bardzo dobry.

Jeśli generator liczb losowych jest dobry, a PractRand zgłasza faile, to może być spowodowane
ucinaniem zer wiodących - jeśli nie usunąłeś nadal tego problemu. Tam w linkach pokazywali jak w
pythonie zachowuje się zera wiodące. Jeśli konwerter działa, to znaczy nie ma już znaków LF 0xa.

Pozdrawiam

[osobli...@gmail.com]

> > Te same pliki, gdy są mniejsze niż około 1 GB skutkują nierozpoczęciem się testów i komunikatem:
> > RNG_test using PractRand version 0.93
> > RNG = RNG_stdin, seed = 0xae0bb968
> > test set = normal, folding = standard(unknown format)
> > Segmentation fault (core dumped)
> Nie wiem dlaczego, czy używasz komendy:
> cat plik.bin | PractRand stdin
> ?

Tak:

cat plik.data | konwerter.exe | RNG_test stdin

> > Dla większych niż 1 GB otrzymuję wciąż dużo faili i standardowy komunikat "abort()":
> Powinno działać dla dowolnie dużych danych przy pomocy komendy:
> Generator | Konwerter | Tester
>
> Ale jak Tester przestanie czytać po failach, to konwerter nie może pisać i robi abort.

Możliwe, że tak jest. Tylko skąd te faile? Ostatni raz testuję mój program i mój plik. Jeżeli nie zda testów, napiszę inny prosty, sprawdzony generator.

> Może spróbuj wersji która nie robi abort gdy nie może pisać:
> https://github.com/mmarszik/01ToBin/blob/main/main.cpp

Ok.

> > Spróbuję jeszcze raz wygenerować plik 200 GB. Dlaczego wielkość pliku robi różnicę?
> Nie wiem, ale powinno działać bez pośrednictwa pliku dyskowego. U mnie działa kilka
> godzin i nie ma faili ani abortów. Może jakaś wersja PractRand nie kompiluje się poprawnie
> jakimś kompilatorem, albo nie działa pod jakimś systemem?

Jeżeli nawet plik znowu nie zda testów, spróbuję napisać inny, sprawdzony generator. Jeżeli on też nie zda, to coś jest nie tak z tym PractRand.

> Jeśli generator liczb losowych jest dobry, a PractRand zgłasza faile, to może być spowodowane
> ucinaniem zer wiodących - jeśli nie usunąłeś nadal tego problemu.

To już rozwiązane, znaki nowych linii także.

[M.M.]

On Sunday, August 22, 2021 at 10:17:49 PM UTC+2, osobli...@gmail.com wrote:
> > > Te same pliki, gdy są mniejsze niż około 1 GB skutkują nierozpoczęciem się testów i komunikatem:
> > > RNG_test using PractRand version 0.93
> > > RNG = RNG_stdin, seed = 0xae0bb968
> > > test set = normal, folding = standard(unknown format)
> > > Segmentation fault (core dumped)
> > Nie wiem dlaczego, czy używasz komendy:
> > cat plik.bin | PractRand stdin
> > ?
> Tak:
>
> cat plik.data | konwerter.exe | RNG_test stdin
> > > Dla większych niż 1 GB otrzymuję wciąż dużo faili i standardowy komunikat "abort()":
> > Powinno działać dla dowolnie dużych danych przy pomocy komendy:
> > Generator | Konwerter | Tester
> >
> > Ale jak Tester przestanie czytać po failach, to konwerter nie może pisać i robi abort.
> Możliwe, że tak jest. Tylko skąd te faile? Ostatni raz testuję mój program i mój plik. Jeżeli nie zda testów, napiszę inny prosty, sprawdzony generator.

Tak, jeśli użyjesz generatora który przechodzi testy PractRand, a teraz będą faile, to błąd będzie
gdzieś w komunikacji lub konwersji.

[osobli...@gmail.com]

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ę.

[osobli...@gmail.com]

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?

[M.M.]

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

[M.M.]

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

[osobli...@gmail.com]

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?

[osobli...@gmail.com]

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.

[M.M.]

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

[osobli...@gmail.com]

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?

[M.M.]

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.

[osobli...@gmail.com]

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.

[M.M.]

On Monday, August 23, 2021 at 3:21:47 PM UTC+2, osobli...@gmail.com wrote:

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

Pozdrawiam

[osobli...@gmail.com]

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.

[M.M.]

On Monday, August 23, 2021 at 9:11:14 PM UTC+2, osobli...@gmail.com wrote:

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

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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".

[osobli...@gmail.com]

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.

[M.M.]

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

[osobli...@gmail.com]

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ń.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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?

[M.M.]

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

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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?

[M.M.]

U mnie struct.pack zadziałało od razu, nic nie konfigurowałem:

sys.stdout.write( struct.pack('I', buf) )

Pozdrawiam

[M.M.]

Może spróbuj wersję 0.94.
Pozdrawiam

[osobli...@gmail.com]

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ą.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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.

[M.M.]

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

[osobli...@gmail.com]

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).

[M.M.]

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

[M.M.]

On Tuesday, August 31, 2021 at 12:57:36 AM UTC+2, osobli...@gmail.com wrote:

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

[osobli...@gmail.com]

> 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ą.

[osobli...@gmail.com]

> 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.

[osobli...@gmail.com]

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.

[osobli...@gmail.com]

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).

[osobli...@gmail.com]

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

https://pastebin.com/NKcKveDT

[osobli...@gmail.com]

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