В вашем случае ресурс динамический, меняется не один ресурс на другой, а состояние одного и того же ресурса. Это не конкретное фиксированное множество строк, а множество, удовлетворяющее ваш запрос на текущий момент времени. Представьте URL, по которому сервер возвращает текущее время. То, что при каждом запросе будет приходить новое время, не значит, что вы будете получать разные ресурсы. Вы всё так же будете получать запрашиваемый ресурс — текущее время. В вашем случае (в случае http) идентификатором ресурса будет URL вместе с вашими требованиями. Допустим `http://example.com/users?city=moscow`. Требование к постоянству идентификатора говорит о том, что вы не можете просто взять и поменять например имя параметра city на place, не оставив по прежнему адресу информации о новом размещении ресурса, и не можете поменять смысл параметра (например, вместо пользователей из Москвы начать показывать пользователей, у которых Москва — любимый город).
380 от 390 отличается не более чем на 3%, что вполне соответствует точности ваших измерений. Разные фазы, так как объекты под разными углами относительно камеры. А разное направление — следствие перспективы.
Возможно, вы что-то не поняли или я вас не понял, но в статье как раз объясняется то, почему проще получить сразу две величины. И эти две величины будут одномерными и независимыми друг от друга. Вторую можно вообще выбросить, если это не ухудшит производительность, результат не изменится. То есть искать только Z0. А чтобы получить одну нормальную величину из одной равномерной, то придется исользовать нестандартную функцию, обратную функции erf, как писали выше уже. Покажите ваш тест.
А какой-нибудь uint64 позволит более 500 лет считать события с частотой 1 млрд в секунду обычным методом. Это так, для справки. А насчет add(n) интересная тема. Если в качестве последовательности выбрана арифметическая прогрессия, то думаю можно легко управлять вероятностью увеличения в зависимости от n, еще не думал как именно. С прогрессирующими последовательностями всё будет гораздо сложнее.
Но этот ряд тейлора не будет вычисляться на аппаратном уровне, в отличие от таких функций как корень или логарифм.
А как получить любое распределение, в статье описано.
Это если один интервал растянуть (умножить на константу), то дисперсия пропорционально увеличится. А тут сложение нескольких случайных величин, сложный процесс, который изменяет плотность вероятностей. В статистике даже отдельное название получил — композиция законов распределений. Думаю вряд ли можно где-то встретить точную функцию плотности, которая получается при сложении 12 случайных величин. Я лично дисперсию проверил экспериментально.
К ЦПТ этот способ имеет непосредственное отношение. Для величин в интервале от 0 до 1 получается, что 12 действительно магическое число, потому что именно при 12-ти слагаемых дисперсия получается равной единице. Если сложить больше, само распределение получится точнее, но придётся находить способы для нормализации такого распределения и конечно же увеличивается сложность расчета.
Наверно стоило упомянуть его в статье. Дисперсия у них одинаковая, но форма функции плотности немного отличается. И в отличие от суммы 12 равномерно распределенных случайных величин этот метод абсолютно точный. А лучше или хуже, и насколько критична точность, зависит от конкретной задачи и вычислительных средств. Грубо говоря, если случайное число генерируется подбрасыванием монетки, то очевидно преимущество метода полярных координат. Для каких-то задач, возможно, будет преимуществом то, что при суммировании 12 равномерных величин итоговый результат будет в ограниченном промежутке и, например, не вылезет за границы массива. По скорости вычисления в JavaScript, например, эти методы примерно одинаковы, скорость больше колеблется от способа реализации алгоритма, чем от выбора метода.
Я имею в виду физическое значение счетчика, которое в пределах байта. Если надо сделать ~10000 итераций чего либо, имея только 8 бит, достаточно после каждой итерации увеличивать счетчик с вероятностью 0.01 и проверять, когда наш байт достигнет 100. А чтобы узнать текущее (примерное) значение реального количества итераций, просто умножить наш байт на 100. Без всяких последовательностей.
Не понял, с какой целью выбирается определенная последовательность? Почему нельзя просто увеличивать счетчик, например, с вероятностью 0,01? Тогда число 100 в счетчике появится примерно через 10000 итераций.
Тогда зачем файлу расширение php?
Глянул пример реализации. По запросу «terminator» 951 результат, по «terminator 1991» — 18642. Гениально.
пример
А как получить любое распределение, в статье описано.