On Tuesday, October 11, 2016 at 10:00:31 PM UTC+2, bartekltg wrote:
> On 09.10.2016 23:12, M.M. wrote:
> > On Sunday, October 9, 2016 at 3:55:03 PM UTC+2, bartekltg wrote:
> >> On 09.10.2016 15:26, M.M. wrote:
> >>> Wywaliłem diehardera. Napisałem na kolanie kilka swoich
> >>> testów, pewnie moje są gorsze,
> >>
> >> Jak wspominałęm, cppCon w "telewizji" leci.
> >> Oglądam do kotlera powolutku co IMHO ciekawsze odcinki.
> >> M.in ten:
> >> https://www.youtube.com/watch?v=6DPkyvkMkk8
> >> W sumie niewiele się dowiedziałem, to wstęp do użycia
> >> <random> (choć jak ktoś nie zna za dobrze, pewnie warto
> >> obejrzeć). Wytępuje tam jednak jedna powracająca dygresja.
> >>
> >> Nie jesteś spacjalistą, nie rób własnego PRNG. Popsujesz.
> >> Jesteś zajebistym programistą? A jesteś przy okazji
> >> matematykiem/statystykiem? Albo chociaż przeczytałęś
> >> z pełnym zrozumieniem tę górę prac na ten temat Nie?
> >> Prawdopodobnie coś zwalisz.
> >
> > Nie można użyć gotowca, dieharder ma zwalone testy a
> > dla tych poprawnych wyświetla że generator ich nie
> > zalicza. Im dłuższy test, tym większe prawdopodobieństwo
> > że dieharder wyświetli failed. Nie twierdzę że przez
> > dwie godziny napisałem coś super rewelacyjnego, ale
> > chyba nie mam wyboru.
>
>
> Co to znaczy "nie mam wyboru"?
Dieharder ma problemy. Ciężko jest określić jakie. Kilka
testów nie działa. Jakie nie działają, inaczej wynika z
dokumentacji, inaczej z pomocy podręcznej. Gdy zwiększam
n-tuples, nie wiem co dokładnie robię, ale podejrzanie
dużo testów nie wychodzi na dobrych generatorach. Nie wiem
czy problemem jest stabilność numeryczna, czy błąd testów,
czy faktycznie generator ma problem. Wolę mieć tester o
mniejszym obszarze stosowalności w którym wiadomo co się
dzieje.


> Uważasz, że zmajstrujesz test który nie będzie się wykrzaczał
> dla rzeczywistych liczb losowych?
> Bardzo możliwe.
> Ja też umiem napsiać taki test. Licze zera i jedynki, mają
> być z grubsza po połowie ;-)
No ale aż tak prostego to ja nie mam ;-) Na bazie tamtego
kodu można zrobić kilkadziesiąt-kilkaset testów z sześciu
grup. Wada jest taka, że obsługuje małą ilość punktów
swobody - ale o tym potem.


> Nie o to chodzi, by test się nie wykrzaczał.
> Ważniejsze jest, jak _silny_ jest ten test w obszarze
> jego stosowalności (zanim sie wykrzaczy i dla losowych).
Nie wiem czy rozumiem. Dla losowych składniki sumy:
(x[i] - E[i])^2 / E[i]
Będą najczęściej dążyły do małych wartości, a małych
wartości, o ile rozumiem, rozkład i jego całki łatwo
i stabilnie się liczy. Może chodzi o to, że dla prawie
losowych generatorów typu generator liniowy się wywalą.
Moim zdaniem też nie powinien. Nie podoba mi się to że taki
program uruchomiony z domyślnymi wartościami ma
prawo się wywalić. Powinien wyświetlić
prawdopodobieństwo równe zero i tyle. Dopiero dla
zaawansowanych, którzy statystykę mają w paluszku,
powinien mieć np. niebezpieczne opcje dzięki którym
program działa 10 razy szybciej.


> Twoim zadaniem byłoby więc nie napisanie testu, który
> się nie wykrzacza, ale ma małą 'moc sprawdzającą',
> ale testu, który się nie wykrzacza i równie dobrze
> jak dieharder wykrywa złe generatory.
Największą wadą mojego testera jest brak sprytnej implementacji
całki z rozkładu chi. To pociąga za sobą brak możliwości
policzenia testów z dużą ilością punktów swobody. W sieci
nie znalazłem gotowca, samemu nie chce mi się ulepszać,
bo nie mam motywacji. Bronek ostatnio-często pisał o
testach generatorów, a że kiedyś odrobinę się tematem
ciekawiłem, nawet mam generator swojego autorstwa, to dałem
się sprowokować do napisania prostego testu - sorki, ale innej
motywacji do implementacji rozkładu nie mam. Jak podacie
dobrego liba, to podmienię i udostępnię kod. Wracając,
poza tą wadą mój tester powinien też bardzo dobrze
wykrywać złe generatory, liniowe od razu wykrywa.


> To nie jest proste i to nie jest nawet robota na dwa tygodnie;>
Hmmmm. Jak ktoś dobrze programuje i może uzyskać odpowiedź
od kolegi dobrego z matematyki i statystyki, to powinien zrobić w
20 dni. Wiadomo, im więcej typów testów i im testy bardziej
sparametryzowane, tym więcej pracy. Dużo zależy od tego, czy ktoś
się tym wcześniej interesował.

Najpierw sprytna implementacja testu-chi. Jak nie znajdzie w sieci, to
powinien zrobić w 5-7 dni. Potem trzeba opracować testy, jak ktoś się
tym nie interesował wcześniej, to i miesiąc będzie opracowywał.
Do testów trzeba znać rozkłady - więc musi być konsultacja z kimś
od statystyki. Potem implementacja testów, jakiegoś interfejsu...
pesymistycznie 2 miesiące, optymistycznie trzy tygodnie roboty.


> Zresztą, procedura postępowania jest w dieharder wyjaśniona.
Niby jest, ale ja jakoś nadal nie jestem pewny co jest
problemem gdy w podaję duże n-tuples. Nie wiem czy generator
jest zepsuty, czy jest błąd w dieharderze, czy test jest
zepsuty, czy liczy gamma (a więc prawie silia) z 0.5*n-tuples i
numerycznie pada.



> Jest tryb testowania 'do zepsucia'. Jeśli testowany generator
> psuje się dla tego samego rzędu #p_samples co najlepsze
> generatory, to uznajemy, że test wyczerpał swoje możliwości
> i test należy zaliczyć pozytywnie.
Nie rozumiem tego. Najlepszy generator powinien zawsze
przejść test. Z ciekawości włączyłem swój test generatora
fionacciego dla około 40 bilionów liczb. Test to paradoks
dnia urodzin. Metakod testu:

kubełki[30] = {zera};
for( pięć bilionow razy ) {
dni[30] = {zera};
cnt = 0;
while(true) {
r = rand() % 30;
if( dni[r] ) break;
v ++ ;
dni[r] = 1;
}
kubełki[ v-1 ] ++ ;
}
return sprawdz_rozklad( kubelki );

Spodziewam się, że generator przejdzie test i nie
mam obaw co do stabilności numerycznej - no chyba
że wypełni się tylko jeden kubełek - to tylko
bignum nie straci stabilności.




> > Gdy wady wyjdą, to pomyśli się nad poprawkami. Gdy
> > wady wyszły w dieharderze to nie ma sensu abym nawet
> > myślał nad poprawkami.
>
> - To wady w sensie 'test nie ejst dowolnie mocny',
> a nie 'test jest popsuty'.
Nie rozumiem czemu test nie jest dowolnie mocny. Nie rozumiem z
tych samych powodów co powyżej: składniki
(x[i] - E[i])^2 / E[i]
w przeciętnym generatorze lepszym od liniowego nie rozjeżdżają
się do +-inf.

> >> Zauważ*) że i w dieharder znajdują się tsty określane
> >> jako niepoprawne! A ktoś je tam kiedyś wsadził myśląc,
> >> że są dobre. Spac z dziedziny!
> > No wiem, tak to już bywa w tworzeniu oprogramowaniu.
> > Pewne jest, że ja tego kodu nie poprawię. A jak są
> > nie działa, to używać też nie mogę.
>
> Przeciez działa.
> Dokłądnei tak jak opisano w dokumenbtacji;>
Gdy daję m=1 i odpalam 1000 razy test dla mersena, to
wszystkie 1000 testów przechodzi. Gdy daję m=1000 i
jeden test, to nie przechodzi. Dlaczego?


>
> >> <złośliwość> Jakbyś dokłądnie p[rzeczytał dokumentację,
> >> wiedziałbyś też jak działa dieharder <\złośliwosć>
> >> ;-)
> >>
> >> *) mozna to zauważyć czytając pdfy od dieharder;>
> > Nie sądzę abym zrozumiał w kilka chwil na tyle, aby
> > go poprawić. Swój kod mogę w kilka godzin napisać.
>
> I co z tego?
> Prawdopodobnie będzie to słabsz yest niż dieharder
> na domyślnych ustawianiach czy od biedy -m 100.
Czemu -m 100 to jest od biedy? A jak chcę przetestować
na bilionach liczb? Czy będzie słabszy... no bez
lepszej implementacji chi-kwadrat nie przetestuje się
tym programem na dużej ilości kubełków. Poza tym
myslę że jest dobry.


> >>> Pierwszy wniosek: Do tej pory nigdy nie zaobserwowałem aby MT
> >>> oblał stabilny test.
> >>
> >> A MT idealny nie jest... ;>
> > Idealny nie jest, ale żeby FAILED?
>
> Pamiętaj, zę ejst tam kilka generatorów MT.
> Kilka, bop je modyfikowano. Z jakiś powodów;>
Hmmmm może faktycznie trafiłem na jakiś MT do bani...
Ale czemu tysiąc testów na m=1 przeszedł?



> >>> Odpaliłem kilka testów dla ranluxa,
> >>> na oko bylo widać że ranlux zalicza testy lepiej.
> >>
> >> Co to znaczy lepiej?
> > Tylko to co napisałem - na oko. Częściej było prawdopodobieństwo
> > z przedziału 10-40% niż w MT.
>
> To równie dobrze możę znaczyć "gorzej";>
Na oko to na oko.



> >> Nie opisałeś kryterium 'dobroci' wyniku.
> > Porównanie z oczekiwanym rozkładem i całka po rozkładzie
> > chi-kwadrat.
>
> Całka?
Dystrybuanta.


> >> To, że daje wynik bliższy całce nie musi oznaczać,
> >> że jest lepszy ;>
> > I tak i nie. Generalnie porównanie rozkładu jest
> > lepsze. Ale przy pewnych założeniach porównanie do
> > wartości oczekiwanej całki też jest niczego sobie.
>
> Tak, przy testowaniu genertora do obliczenia tej konkretnej całki ;-)
No nie tylko :) Jeśli policzy się wiele różnorodnych całek już
test jest silniejszy. Jeśli całki policzy się przy pomocy każdej
liczby, potem co drugiej, co trzeciej, itd, to znowu wzmacniamy test.
Jeśli całki policzy się xorem z N kolejnych liczb to znowu wzmacniamy
test. Z każdą taką sztuczką wzmacniamy test, a pozbywamy się
numerycznej niestabilności. W końcu każdy generator programy dla
jakiejś maski źle policzy którąś z całek, ciekawe jakby mersen
policzył calkę gdyby brać co około 623 liczbę.


Pozdrawiam