Что бы еще такого сделать?... Предлагайте! Обсудим все!!!
Вт июн 11, 2019 12:47:56
в моём проекте DIGISCRIPT для формирования случайных чисел я использую функцию rand(). все её ограничения по длине псевдослучайной последовательности мне известны и никак не мешают. для получения случайного байта в первой версии проекта я тупо отбрасывал старший байт возвращаемого rand() значения, а для формирования еще меньших чисел, использовал результат операции %, т.е. если хотел получить случайное число не более 25, то делал так: rand() % 25
во второй версии я учел недостатки вышеописанного подхода и теперь использую такой вариант получения случайного числа с ограничением:
- Код:
int range_rand(int range){
return (rand() * (uint32_t)range)/RAND_MAX;
}
наверное, можно еще как-то улучшить... но сейчас вопрос о другом.
вопрос о том, что для получения случайного цвета используется эта самая функция range_rand(0x100), которая определяет условный номер оттенка. и часто бывает так, что она возвращает, например, подряд 1 и 2 или 5 и 7, т.е. достаточно близкие оттенки, глазом воспринимаемые, как одинаковые.
так вот, в чем, собственно, вопрос: как улучшить выбор случайного номера оттенка из диапазона 0...255 так, чтобы не возникало подряд два близких оттенка?
пока применяю вариант проверки: пока получаю номер оттенка, отличающийся от предыдущего меньше, чем на заданную величину, повторяю вызов функции случайного числа. оно вроде работает, но не так, чтобы я был совсем доволен...
что посоветуете?
Вт июн 11, 2019 13:38:25
ARV, прибавляйте к текущему цвету, например, 4, а затем псевдослучайное число в интервале от 0 до 247 (255-4*2)
Вт июн 11, 2019 13:52:34
чевой-то не понял... допустим, текущий цвет 5. я прибавил 4, получил 9. запросил случайное число от 0 до 247 и получил 6.
как это мне помогло?
Вт июн 11, 2019 14:27:54
ARV, хорошо, пусть текущий цвет 5. 5+4=9. Теперь прибавляем случайное число от 0 до 248 (так правильней, но не суть). Если оно 0, то 5+4+0=9. Если 248, то 5+4+248=257=1.
То есть, прежний цвет 5 будет отличаться от нового, как минимум, на +-4. Вы же это хотели?
Вт июн 11, 2019 14:36:24
а, вон оно чо! я как-то слово "прибавляйте" отнес только к числу 4, а что еще и случайное надо прибавлять, это как-то ускользнуло.
теперь понятно.
Вт июн 11, 2019 14:39:59
ну, да, весьма логично, если переменная 8бит:
рнд (247) принимает значения от 0 до 247
плюс 4 - и будет от 4 до 251 (от 4 до -4 если тип сигнед чар)
если к нему добавить х то в ответе будет х' отличающееся от х не менее чем на 4 в любую сторону...
правда разом на 100% яркость не изменится, т.к. для этого алгоритма 255 сосед 0...
Вт июн 11, 2019 15:43:26
Ivanoff-iv, можно допилить алгоритм. Прибавлять к текущему цвету MIN(3,255-c)+1, а случайное числоа брать не до 256-2*4, 255-MIN(3,255-c)-MIN(4,c) - где с - текущий цвет.
То есть, для цветов от 0 до 3 допускать суммарное приращение вплоть до 255, а для цветов 252-255 начинать приращение с нуля.
ARV, благодарить у Вас не принято?
Вт июн 11, 2019 16:55:14
Ivanoff-iv писал(а):правда разом на 100% яркость не изменится, т.к. для этого алгоритма 255 сосед 0...
не понял, при чем тут яркость, но индекс 0...255 это условный "градус" цветового круга в модели HSV, т.е. и 0 и 255 - это оттенки яркокрасного цвета
ПростоНуб писал(а):благодарить у Вас не принято?
у нас не принято выпрашивать.
Вт июн 11, 2019 17:18:08
индекс 0...255 это условный "градус" цветового круга
тогда ладно...
ПростоНуб писал(а):благодарить у Вас не принято?
у нас не принято выпрашивать.
смотри
ПростоНуб, сейчас ещё и должен останешься...
Чт ноя 21, 2019 18:42:17
я возвращаюсь к теме о генерации случайноо цвета.
предложенный выше алгоритм особого эффекта не дает.
генератор псевдослучайной последовательности из avr-libc слишком часто выдает числа, находящиеся рядом, например 2015 и 2000. поскольку я "масштабирую" это число к диапазону 0-255, то естественно, что результат получается один и тот же...
то есть проблема в генераторе случайных чисел есть, и она мешает жить... истинная случайность, как для криптографии не нужна, нужна "красивая" случайность, то есть чтобы после красного почти всегда был не-красный, а после голубого был не-голубой.
хуже всего еще то, что при поиске случайных файлов, наблюдается тот же эффект: значительно чаще "выпадают" файлы с номером где-то в середине списка, чем на краю...
все это огорчает.
нет ли каких идей для исправления этой ситуации? грубо говоря, нужна функция rnd(int x), которая бы возвращала число от 0 до x (не включая), и при этом вероятность того, что два раза подряд она выдаст одинаковое число была ненулевой, но более-менее малой, а распределение тем не менее стремилось к равномерному?
возможно, есть какой-то принципиально альтернативынй способ управления случайным цветом и номером файла... но я не могу никак его найти...
Чт ноя 21, 2019 18:59:00
Ну ты как не электронщик прямо! Делай srand из канала АЦП, на котором антенна болтается.
А чтобы реально кошерный набор случайных цветов генерить, сначала проиндексируй их - сделай 256 базовых цветов, из них и выбирай.
По крайней мере, обязательно нужно уйти от модели RGB. Можно, например, HSV использовать…
// а, увидел, тут уже HSV используется.. Ну, а ГСЧ все-таки должен быть аппаратным. Можно копить энтропию из промежутков между внешними прерываниями, АЦП (как я уже говорил), еще чего-нибудь.. Абы источников случайных величин было как можно больше. Тогда получим примерно гауссиану. Ее при помощи математики легко в равномерное распределение преобразовать.
Чт ноя 21, 2019 19:25:37
антенна на канале АЦП будет давать четкую корелляцию с сетью. поскольку в моем устройстве идет привязка к интервалам по 10 мс, сомневаюсь, что эта идея даст хоть сколько-нибудь лучший результат, чем то, что есть сейчас...
не нужна истинная случайность, я уже говорил. нужна простая, "человеческая", красивая последовательность, которую просто сложно предсказать зрителю
Чт ноя 21, 2019 19:44:08
Ну так псевдослучайные числа - на то и псевдослучайные, что фигня полная…
Можно фликкер-шум использовать. Там, правда, 1/f, но все лучше, чем псевдослучайные числа.
Чт ноя 21, 2019 19:51:11
А если считать хеш-функцию от текущего цвета и принимать результат за новый цвет? Если цвет 24 битный, то можно crc32 использовать, и обнулять младший или старший байт. На выбор.
Чт ноя 21, 2019 19:56:36
допустим, для цвета это могло бы быть интерсным, а как на счет номера файла? тоже от текущего номера считать?
и какую хеш-функцию можете предложить?
Чт ноя 21, 2019 23:18:16
продолжать выбивать случайные числа, пока выпавшее значение не станет отличаться от текущего цвета/номера более некоторой дельты - самое то имхо.
из "большого" stdlib попытаться утащить реализацию генератора с равномерным распределением - какого-нибудь lrand48
Последний раз редактировалось
arkhnchul Пт ноя 22, 2019 07:03:40, всего редактировалось 1 раз.
Пт ноя 22, 2019 03:29:05
если кажется, что рандом неправильный - исправь! крути доску как одинокий шахматист: Учет=рнд(х), Унечет=(рнд(х)+х/2)%х
или на треть оборота - также, только добавляй поочереди 0, х/3, 2х/3...
и твои рядомстоящие результаты окажутся совсем не рядом
Пт ноя 22, 2019 11:06:39
arkhnchul писал(а):продолжать выбивать случайные числа, пока выпавшее значение не станет отличаться от текущего цвета/номера более некоторой дельты - самое то имхо
нет, это плохо: слишком недетерминированная длительность генерации числа в этом случае. мои эксперименты показывают, что подряд может быть больше десятка "близких" чисел.
Ivanoff-iv писал(а):крути доску как одинокий шахматист
уже интересней... попробую экспериментально проверить, как это скажется на наблюдаемый результат.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.