- 1
- 2
- 3
- 4
- 5
int getRandomNumber(){
int Number[1];
return Number[6];
}
//Я только учусь, поэтому не судите строго.-
C++ / Говнокод #15582
+15
И кому теперь нужно srand(GetTickCount());
Запостил:
Ignat776,
26 Марта 2014
Follow us!
В с++ то? Никому. Юзай вменяемые boost::random (везде) и std::random (в с++11), а не дикое сочетание тормозного, неудобного и устаревшего говна srand() с виндоблядской апишкой GetTickCount().
Во-первых - да. У него очень маленький seed и достаточно хреновое распределение. Впрочем как и у любого другого линейного конгруэнтного генератора.
Во-вторых он лагает как говно, если его юзать из нескольких тредов (производительность проседает где-то в 100(!) раз по сравнению с одним тредом). Ибо состояние глобальное.
В-третьих он тупо неудобен, т.к. нужное распределение из его выхлопа надо получать самому.
То нужно юзать криптостойкий ГПСЧ, который прилагается ко всем приличным криптобиблиотекам. Этому требованию не удовлетворяет ни один генератор из boost::random/std::random (ну кроме random_device, но у него свои заморочки), что уж говорить о rand().
С 32 битным сидом rand()'а достаточно перебрать всего 4 миллиарда вариантов, и ты получишь все пароли и все ключи, которые могла сгенерить система ;) А если его еще и сдуру проинициализировали временем... Да еще и делали это на каждом запросе... Брр... Не дай бог приснится такое, носками не отмашешься.
А что там за заморочки?
...,протрояненный анб
задолго до "откровений" Сноудена я читал, что все устройства и алгоритмы были ОБЯЗАНЫ содержать бэкдор или ослабленный алгоритм для доступа силовых структур "на случай чего", иначе бы они не прошли одобрямс (сертификация, патент, разрешение - или как это грамотно называется)
в свое время был скандал с PGP, мол, этот алгоритм слишком секюрный, и его существенно ослабили перед доведением до общественности.
просто тогда никто не придавал этому никакого значения
а я и сейчас не придаю, на фоне общей истерии, потому как уже поздно что-либо скрывать, все уже утекло и в фсб и в фбр, и гуглам всяким
Эт еще хуйня. Про intel management engine читал? Большой брат уже в твоем чипсете ;)
> хоста для виртуальных машин
Вполне достаточно SMM, который и bios и uefi вроде как всегда юзают (якобы для управления энергосбережением и прочей ерундой, но мы то знаем...).
А я о чем выше?
Биосы то можно исследовать. А вот ME, насколько показали поиски в гугле, является конфиденициальной инфой, и его так никто и не смог разломать и даже разобрать его прошивку (впрочем это хорошо, не хватало еще вирусов на этом сопроцессоре).
/dev/urandom по дефолту. Но можно поменять.
Wat?
rand в студии использует tls
Очень весело будет, если кто-то проинициализирует seed в main'е, и наивно будет думать, что и в других тредах тоже все будет норм. А на деле они тупо начнут с единички...
Кстати, об этом написано в документации? Можно пруф?
Не знаю что там в пруфах, но у меня в прерываниях rand не работал. Падало при попытке чтения tls. Если не ошибусь то как раз при чтении FS:[0].
Блин, а в виндовых драйверах разве можно юзать rand()?
Не, не виндовый. Есть некие наркомы, что заюзали для своей оси кресты со студией. Не будем о грустном.
P.S. Насчет скорости - тестил на gcc под линухом. Там сид не в TLS, поэтому лагает как говно.
Зато название говорящее.
По имени функции должно быть ясно что внутри, а именно - срандь.
это ты выяснил когда мой говнокод проверял?
1) Посикс-онли.
2) Тож самое линейно-конгруэнтное говно, что и rand(). Просто бит побольше.
3) Надпись в мане гласит: These functions are declared obsolete by SVID 3, which states that rand(3) should be used instead.
SVID 3 == "Version 3, based on System V Release 4, published 1989"
в посиксе о обсолишн ничего не написано:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.html
в манах ванила SVR4 (ака солярка) тоже ничего такого не говорится:
http://www.freebsd.org/cgi/man.cgi?query=drand48&apropos=0&sektion= 0&manpath=SunOS+5.10&arch=default&format =html
Now you have 2.000001 problems.
А что если написать как ниже для получения нормального распределения [0..99]? Видите проблемы кроме говнокода?
Равномерного. Нормальное совсем не так выглядит.
> Видите проблемы
Вижу. Распределение не равномерное ;)
Пруф для сомневающихся: http://ideone.com/GnSkao
P.S. Да еще и плавучка юзается, походу этот код будет работать медленнее uniform_distribution.
http://ideone.com/wz0bcx
Если что код на 6:49
PS: Насчет перевода uniform - описка.
Кто-то доигрался с экономией скобок ;)
http://ideone.com/NikpHq
Так что распределение по ссылке - равномерное (считать лень).
> Так что распределение по ссылке - равномерное
Ну тогда надо писать критерий и доверительный интервал :)
Дык тест chi-square это и позволяет делать
> Преобразование, используемое в коде по ссылке портит вероятности - часть чисел на выхлопе вероятнее, чем остальные.
Не совсем. Часть чисел выпали чаще чем остальные, но это также может объясняться и недостаточностью выборки. Если вам выпало 10 раз подряд 6-6 это же не делает вас супервезучим игроком в Нарды, ведь так ;)
Было 32768 равновероятных исходов. 32700 из них равномерно размазали по сотне выходов. Но остались 68 лишних. И они ВСЕГДА будут падать в одни и те же выходы (т.к. алгоритм такой). Это именно систематическая ошибка, а не случайная.
Возможно. И даже реализовано в бустовском распределении ;)
Один из способов (который там и юзается) - тупо отбрасывать числа >= floor(|X| / |Y|) * |Y| и брать следующее случайное число. Тогда распределение на выходе будет равномерным.
Если у генератора равномерное распределение - не уйдет.
Против математики не попрёшь :)
У 32 чисел вероятность 0.00997, а у остальных 0.01001
Из-за этого, например, 0 выпадает чаще чем 2. Это, конечно, копейки. Но вот для всяких научных расчетов, лотерей и тому подобного - это совершенно неприемлимо.