В случае имитации бросков монеты maximum==2, кубика - 6. Значение t2 - порядка 10^6. Практическая проверка при 10 000 выбрасываний показала хорошую равномерность распределения. Но, конечно, стоило бы избавиться и от операции %, придумав способ получения значений, ограниченных maximum. Если есть идея, то я бы ее реализовал.

А вообще в упор не вижу как операция деления с остатком может приводит к неравномерности этого остатка. Вот примеры:

деление на 7 чисел ряда 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15... и т.д. дает сохранение равномерности, но уже в ограниченом диапазоне: 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1... точно так же сохраняется равномерность с любыми другими операндами не зависимо от их соразмерности. Так что, думаю, операция вполне даже корректная.

Операция перемножения значений остатков промежуточных чисел (в цикле) приводила к неравномерности около 3%. Применение же штатного компьютерного генератора случайных чисел дает неравномерность около 5%.

Дело в том, что операция получения остатка используется еще в промежуточных результатах для того, чтобы выделить из числа == тикам процессора только наиболее меняющуюся часть (менее нескольких миллисекунд) . И в этом случае число порядка 2*10^9 делится нацело на ограничитель 10^6. Эти числа сейчас в цикле, случайно задаваемом в диапазоне от 300 до 600 млсекунд, просто суммируются, а не перемножаются.

"Довольно наворочено. На мой взгляд вполне достаточно... "

В принципе достаточно и фиксированного интервала. Но для имитации хорошего перемешивания кубиков (адекватной имитации :) для того, чтобы быть более уверенным в качестве случайностей, сделан и плавающий интервал. Принцип можно изложить следующим образом.

Если мы будем использовать точный интервал и вызывать его всегда строго периодично (считая, что комп. даст нам такое проделать :), то получим биения частоты этого интервала и частоты проца. Термин биения - вполне корректный, когда дело касается соразмерения частот, несмотря на попытку раньше это оспорить :) Это тот самый эффект, что возникает у строчного телика когда мы фотаем его экран на видео с другой частотой, еще говорят о стробоскопическом эффекте.

Частота биения == разности и сумме частот (боковые полосы биений - явление используемое в радиоприеме). Т.к. разность очень большая, то мы получим практически генератор псевдослучайных чисел (если не попадем в кратные частоты, образующие стоячие волны биений, что при такой разнице непросто). Но мы вызываем интервал не строго периодично и сам интервал не строго один и тот же (даже если бы захотели этого). Поэтому биения принимают хаотический характер и мы получаем очень хорошее приближение к случайным числам. Это - хорошее приближение к случайной последовательности, если ломать биения в каждом их периоде, то и получим уже практически случайную последовательность. Все еще более улучшается тем обстоятельством, что при тактовой частоте в гигагерцы, обеспечить ее стабильность в младших разрядах от множества дестабилизирующих факторов невозможно. Даже термостабилизированный кварцевый генератор имеет флуктуацию где-то в 8-м разряде от помех, теплового шума, дробового шума и т.п.

так что, думаю, что результат получился очень неплохой для использования проверок парапсихических способностей отклонить вероятность :) Что касается неравномерности операции деления с остатком, то, увидев приведенные аргументы я полностью спокоен :) пример некорректен. С чего бы это мы ограничили диапазон таким образом? Откуда берутся в реале такие границы? На входе операции - равномерно случайные числа.

"Понты. .. Скучно... Надеялся, что выводы сможешь сделать сам."

т.е. ты – в контексте самоуверенной снисходительности? Посмотрим, насколько оправдано :)

Смотри, SergT, ты спрашивал: "Один вопрос. Найденная ошибка была здесь "t2%(maximum)" ?"

практика показала, что нет, не в этом, а потом ты попытался теоретизировать и я вижу насколько ты не прав, буквально по всем пунктам, сейчас покажу почему.

1. Ты даже прикинул процент ошибки в случае INT: "Диапазон ограничивается хоть и не именно таким образом, но все равно ограничивается, т.к. все компьютерные числа представляют собой счетные множества. В реале к примеру unsigned int16 0...65535. Делим на 3. получаем вероятности в виде простых дробей: 21846/65536; 21845/655366; 21845/65536. отклонение от 1/3 порядка 0,003%.". т.е. даже в случае использования такого короткого числа ошибка получается практически не уловимой. На деле же используются несоразмерно большие числа. Так что ты мог и не задавать свой вопрос, а просто сам прикинуть :)

2. Но, как я уже говорил, твой хоть "гипертрофированный" пример, хоть какой – не корректен и вот почему. Возьмем последовательность 0 1 2 3 4 2  и вот результат деления на 3: 0 1 2 0 1 2. Получается, что исходная последовательность далеко не так идеальна, как получившаяся, т.е. как бы неидеальность зависит вовсе не от операции, а от того, как ограничить интервал. 

3. Но и этот вывод был бы неверен. Потому, что сравнивать числовые последовательности и статистические выборки нельзя просто прикидывая проценты, а необходимо для данной длины выборки прикидывать дисперсию и тогда для таких коротких выборок ожидаемые границы идеальности окажутся шире, чем приводимые результаты в процентах. Ведь иначе бы мы выборку 0 1 1 1 1 1 1 1 1 1 1 могли бы оценить как неидеальную, хотя она – лишь вполне реальная последовательность равномерного распределения, которая часто встречается в больших выборках. И для столь короткого примера она вполне укладывается в границы дисперсии.

Вот почему не только твой гипертрофированный пример, но и вообще рассуждения некорректны...

И, как я уже говорил, теперь я совершенно спокоен насчет правильности использования операции деления с остатком, что и является главным для алгоритма :)

Далее.

Если посмотреть две числовые последовательности, а не статистические выборки (первая - переполняющийся в цикле счетчик, вторая - более короткий инревал выборки), то мы сможем увидеть то самое биение, которое ты в упор замечать не желаешь :) и от которого необходимо избавляться при использовании значений счетчика, разбивая эти биения неодинаковостью выборки:

0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567..
0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567..

я выделил только один такой период, но их – два: две боковые частоты, получающиеся в результате модуляции – перемножения (операция деления соответствует операции умножения по сути). При перемножении двух частот всегда образуются две боковые частоты, равные сумма и разности этих частот. На практике, в радиотехнике используют передачу на одной боковой для значительного выигрыша в мощности. Твоя реплика: "Про биения вопрос скорее терминологический, когда говорят о радиоприеме обычно использут термин модуляция, её разницу с биениями можно показать. Скучно." - проявление дилетантства в этой области. Ну, а мой 15-летний опыт разработчика сложной электронной аппаратуры дает возможность просекать такие вещи налету.

"Понты. За флуктуации кварца волноваться не приходится поскольку здесь речь идет о чисто цифровых системах."

Ты хочешь сказать, что нестабильность опорной частоты не будут давать нестабильности числа тиков в выделенном интервале времени? :) Опять какое-то дилетанство.

"Предположение, что под обычной Windows можно делать нечто строго периодично(хотя бы в тиках, если не во времени), неверное."

где это я делал такое предположение? :) невнимательно воспринимаешь написанное...

"И если между простой реализацией и навороченой не будет разницы, зачем делать сложнее? Причем именно из-за сложности есть вероятность, что что-то будет работать не так как задумывалось. Подтвердилось на практике ))"

откуда взялось утверждение, что между простой реализацией и навороченой не будет разницы?

Притом, как ты скрупулезно отстаивал 0,003% :) Разница есть, и разница практическая. Сделал так потому, что на старых, медленных копмах это было достаточно существенно. Причем НИКАКИХ ухудшений идеальности распределения это в принципе дать не могло.

"Все что сказано мною в этой теме могу обосновать и пояснить"

да, пожалуйста, если тебе есть что сказать обоснованно, то самое время это сделать :) В любом случае - спасибо за обсуждение потому как оно укрепило мою уверенность :) А так как уверенность в правильности ошибочных решений растет со сложностью задачи, то важно не то, кто как ошибался, а общеконечный результат.

>Прошу прощения за иронию.

с иронией на этом сайте никаких проблем нет :) можно и желательно красиво прикалываться, особенно если это кроме чисто эстетического момента дает возможность более гротескно выделить проблемс. Не желательна лишь недоброжелательность во всех формах потому, что она переводит человека в контекст активного неприятия, препятствующего пониманию.

>ты когданибудь в реальности наблюдал такие биения счетчика тактов на ПК с Windows, пусть даже на слабых машинах?

когда еще тактовая измерялась мегагерцами, сделал программку для измерения производительности разных компонентов работы компа (тогда это было актуально). Так вот, несмотря на довольно большие периоды измерения (секунды) при повторных измерениях в последних разрядах часто возникали "любимые цифры" а не хотя бы плавно случайные флуктуации, что воспринималось как досадный глюк программы. Возможно, это было проявлением таких биений. Но я никогда не занимался плотным исследованием таких вещей просто потому, что это – очень трудное и муторное занятие, зависящее от текущей реализации компа. Поэтому, когда возникали подозрения в возможности каких-то таких приколов, старался не исследовать возможность и насколько они могут мешать на разных компах, а превентивно препятствовать этому кодом. Именно поэтому я и сделал случайный интервал в случайном генераторе, а не занимался раскопками. Так что можно назвать меня перестраховщиком, что ты и сделал недавно :) но там, где это представляется оправданным, я лучше вот так перестрахуюсь, чем потрачу до фига времени на исследования, но без гарантии, что в каких-то случаях оно окажется недостаточным. Так, вполне возможно, что если сделать ДОСовский вариант случайного генератора и запустить его до винды, то даже на быстрых машинах может проявится не идеальность распределения. А может быть и нет :) хотя бы потому, что используемый счетчик производительности имеет свой тактовый генератор, что делает как бы "периферийным" устройством по отношению к регистрам процессора, которые и в самом деле, имея общую синхронизацию, не чувствительны к качающейся частоте.