> Как-то грустно и медленно.
Не более чем в два раза медленнее, чем в исходном генераторе. Выкидывать можно только один бит, а все остальные использовать повторно.
> В хардовом ИБ рекомендуют всё делать как минимум нестандартно. @Deerenaros чтобы делать что-то нестандартно, нужно очень хорошо понимать, что делаешь. Автор вопроса явно говорит, что это не тот случай.
> Что не делай, если a - b не делит или не делится c - d - переход будет неравномерным.
Если распределение на исходном отрезке равномерно, то для получения равномерного распределения на новом отрезке достаточно получать новые случайные числа и выкидывать те из них, которые не попадают в новый отрезок.
> задача стояла получить случайное число, читай - случайную величину, про её распределение ничего не было сказано
Ну так надо было посоветовать return 4;, чо уж.
> Вообще, если диапозоны не совпадают, то при любом сжатии (деление, вычитания, остатки, логарифмы - не важно) распределение так же портится.
Опять мимо. И, кстати, давно ли вычитание стало сжатием?
> А отстаток брать не учили? @Deerenaros а вот хрен-то там, это неправильное решение. Попробуйте проверить распределение сгенерированнх так случайных целых чисел на отрезке 0..3000000000, когда Number это unsigned int.
@Diel вы скомпилировали helloworld под x86_64, а не под arm. Вам нужен кросс-компилятор для арм, если вы хотите собирать бинарники для телефона на обычном компьютере.
@Diel конечно можете, однако это упражнение даст вам не ответ на вопрос "сложно ли подобрать строку, дающую коллизию", а ответ на вопрос "нет ли коллизий среди рассмотренных вами строк".
> согласитесь всё-таки, подбирать мое дело не просто @Diel если вы готовы назначить денежный приз за нахождение коллизии, скажем $1000, я бы поучаствовал. (:
@Diel Чтобы избежать известных глупых ошибок имеет смысл изучать существующие алгоритмы/их реализации, задаваясь вопросом, почему то или иное место сделано так, как сделано. И это применимо не только к криптографии (:
@mannaro вероятность хотя бы одного выигрыша в серии конечно растёт с длиной серии, но вероятность выигрыша в каждой отдельной игре неизменна. Вероятность хотя бы одного выигрыша в серии дополняет до 1 вероятность не выиграть ни разу, которая равна (1/2)^n.
@savostin не в компиляторе дело. вы ж указатели сравнивали используя map<const char *, int>, а не строчки. Но можно было остановиться и на варианте с const char*, если гарантировать, что указатели всегда будут указывать на исходные строки, заменив map<const char *, int> на map<const char *, int, CompareString>, и определив
@Lerg
> не знакомы, как и с програмированием комплексных чисел в C++...вы бы упомянули, что для работы в C++ с комплексными числами нужно использовать отдельный класс
у меня не было цели показать какую-то конкретную реализацию на С++, да и автор вопроса спрашивал не об этом.
@Deerenaros конечно, будут флуктуации, но в среднем -- не более чем вдвое.