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

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

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

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.

To nie jest proste i to nie jest nawet robota na dwa tygodnie;>

Zresztą, procedura postępowania jest w dieharder wyjaśniona.

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.




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




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

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



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

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

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

Całka?



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


pzdr
bartekltg