W dniu 2012-10-16 22:30, PK pisze:
> On 2012-10-16, bartekltg <b...@g...com> wrote:
>> http://www.cplusplus.com/reference/std/random/
>>
>> Bardzo się z tego cieszę;)
>
> No ja też, ale bez przesady. Przez te 10 lat zdążyłem napisać
> lub znaleźć biblioteki robiące to samo, ale fajnie, że się wreszcie
> ogarnęli. Nie skróci mi to czasu kodowania, ale skróci tłumaczenie innym
> / pisanie dokumentacji.

Jest też sansza, że taki generator zostanie dopieszczony
i będzie ciut szybszy.


>> A co do szybkości rand - nieraz do 'pierdółek'
>> przydałby się szybszy:)
>
> Jak Ci zależy na szybkości, to zrób to, co ludzie robią od dziesiątek
> (no... setek) lat. Przygotuj sobie randomy wcześniej :).

W tym wątku to by się właśnie nie sprawdziło.
Robiłem testy iluś tam sortowań dla różnych
parametrów i długości tablicy.

Oczywiście, 40e6 intów zostało wygenerowane na dzień dobry,
a potem tylko kopiowane do drugiej tablicy i ta testowana.
Jednak zajmowało to swoje sekundy. Jak widać, porządne
własności nie są tu potrzebne zypełnie.

Pewnie jakby mi bardzo zależało, wygenerowałbym
ciągi długości, powiedzmy 3491 i 3499 i brał
z nich cykliczną sumę (modulo zakres).



> Kiedyś trzeba było je kupić i przesyłać (początkowo w kopercie ;P).

A ci od kopert wytwarzali je kostkami do gry;)

> Teraz wystarczy puścić na kilka godzin jakiś bardzo dobry generator
> (albo zły, ale odpowiadający Twoim potrzebom) i masz spokój.
> Do testów i jakichś prostych zastosowań ideał, bo zazwyczaj i tak używa
> się stałego seed'a, a wszystko przyspiesza kilkukrotnie.

> Jeśli Twoje programy robią jakieś skomplikowane obliczenia między
> losowaniami, to można puścić oddzielny proces z RNG (i np. bufor
> na RAMdisk'u). Wtedy to randomy czekają na program, a nie odwrotnie :).

Jak leci jakieś MC i obliczana funkcja jest ciężka obliczeniowo,
koszt radoma jest proporcjonalnie mały. Ale pomysł wart zapamiętania.

> Poza tym sprzętowe generatory są już na tyle tanie i małe, że pewnie
> niedługo po prostu trafią do kompów jako kolejny "ficzer" na płycie
> głównej albo doklejone do CPU/GPU.


O ile będą odpowiednio wydajne. W sensie ciągłej
produkcji, a nie zbuforowania megabajta losowych danych.

pzdr
bartekltg