Временная тема

[Владимир Ситников]

Плохой работающий (практический) генератор лучше хорошего но неработающего (теоретического)...

Давайте начнём с вашего возражения?

0) Для каких-то задач "генератор без повторений" может и потребоваться. Но слепо использовать его для всех задач -- нехорошо.

Если говорить чем "в целом" плох генератор, который выдаёт циклами без повторений, то
1) Плохо то, что он предсказуем. Например, если генерируем числа от 0 до 4, и 0, 1, 2, 3 уже выпали, то с вероятностью 100% выпадет число 4.
2) Плохо то, что нет эффективной реализации для произвольного диапазона. Нет от слова "совсем". Хорошую реализацию можно сделать через массив. Т.е. заполнить его числами от 0 до N, перемешать, и выдавать по одному. На ST это тривиально, а в ОЛ уже проблематично. Но, стоит понимать, что большие массивы держать в памяти и перемешивать всё равно время займёт.
3) Для частных случаев (некоторых N) можно сделать алгоритм не требующий массива, но он при этом будет выдавать лишь часть из возможных перестановок.

А ничего что я уже написал сей макрос?
Который генерирует число от 0 до n без повторений, где n произвольное, меньше 1024.
А называется макрос rnd1024.

PS если есть желание, сам генератор можно легко поменять на ваш, а обработчик массива оставить мой.

Я же не говорю, что "вообще написать невозможно".
1) Я развёрнуто говорю, почему именно в ОЛ невозможно сделать эффективную реализацию.
2) У меня есть сомнения, что даже xorshift128 хватит, чтобы сгенерировать все возможные перестановки 0..63. Ну, в xorshift128 состояние 128 бит, а ln(64!)/ln(2) это почти 300. Возможно, во второй части я ошибаюсь, но сходу не могу сообразить хватит ли энтропии xorshift'а или нет.

3) Можно попробовать прогнать "алгоритм rnd1024" через тесты, проверяющие "случайность" перестановки. Наверняка есть такие. Вот тут вопрос насколько предсказуемые значения генерирует rnd1024.

Плохой работающий (практический) генератор лучше хорошего но неработающего (теоретического)...

Вы в каком контексте говорите про "теоретический"? В контексте ОЛ или контексте КДС/ST?
Уверен, что ни у кого не должно быть сомнений в том, что на ST легко реализовать "random shuffle".
Вот про "реализацию random shuffle на ОЛ" -- согласен, там непросто. Но я с самого начала и говорил, что "невозможно сделать эффективную реализацию".

[rovki]

Все это делается на лету и хранится текущая и предыдущая переменная в виде стека и анализируются .Получается алгоритм выдачи СЧ с переменным периодом .Так делается сам генератор .Но проблема в скорости считывания ,мы же не в таблицу пишем ,а например выводим на экран 1раз.сек . И вот тогда самый лучщий генератор ,без "склеек" может на индикаторе выдать опять склейки ,только потому что процесс выработки СЧ и отображения СЧ не синхронизированы .
Это как вы будите называть раз в сек СЧ от 0 до 10 ,а я буду выходить из комнаты и появлятся раз в минуту и может быть буду слышать только 2,2,2,2,3,5,5.5,5,1....а генератор все хорошо выдавал ...

[Владимир Ситников]

Все это делается на лету и хранится текущая и предыдущая переменная в виде стека и анализируются

В том-то и дело, что нужен не стек, а нужно хранить все числа, которые "уже возвращались" на этой итерации.
Тут двумя переменными ну никак не обойтись.

Это как вы будите называть раз в сек СЧ от 0 до 10 ,а я буду выходить из комнаты и появлятся раз в минуту и может быть буду слышать только 2,2,2,2,3,5,5.5,5,1....а генератор все хорошо выдавал ...

rovki, этот ваш пример про комнату кристально понятен. Но непонятно к чему он.
Вы в другом ракурсе этот же пример рассказывали (про тактования), но и там было неясно к чему он.
Тактование -- проблема/фича сугубо ОЛ. В КДС/ST такой проблемы нет. Там когда надо, тогда и вызываем блок "получения следующего значения".

[rovki]

Использование СЧ это и самое главное мне нужно что бы при вызове формировались одно СЧ в передатчика генераторе без повторений склейка

[Владимир Ситников]

Использование СЧ это и самое главное мне нужно что бы при вызове формировались одно СЧ в передатчика генераторе без повторений склейка

Если задача "сделать лото", то да, нужен ГСЧ "без повторений".

Если задача "сгенерировать pin код", то нужен ГСЧ "с повторениями".
Если задача "сгенерировать входной сигнал для тестов PID'а или ещё чего-нибудь", то нужен ГСЧ "с повторениями".

[AI!]

Вы слишком теоретик... На практике всё значительно проще.
Дом смоделированный с математической точностью никогда на практике не будет идеальным
Зачем в ПР идеальный ГСЧ? Зачем в ПР идеальное лото?

Более того - на практике мой не идеальный ГСЧ становится идеальным, если сюда добавить что СЧ генерируется каждый такт, а пользователю СЧ нужно раз в час, причём по запросу, т.е. для ПР - в случайный момент времени.

С такими реальными исходными данными ГСЧ может просто перебирать числа от 0 до n по порядку каждый такт, и всё равно такое число будет случайным(!) для пользователя.

И т.д.

[Владимир Ситников]

Вы слишком теоретик... На практике всё значительно проще.
Дом смоделированный с математической точностью никогда на практике не будет идеальным
Зачем в ПР идеальный ГСЧ? Зачем в ПР идеальное лото?

Давайте всё-таки обсуждать вопросы ПР в ветке про ПР?

Я, конечно, понимаю, что иногда удобно сдвинуть акцент в сторону "на ПР идеального ГСЧ не нужно", но
1) Исходная ветка была про ПЛК. В КСД+ST часть алгоритмов сделать в десятки раз проще, чем в ОЛ. Буквально пара строк кода, и уже готов "идеальный вариант случайной тасовки".
При этом, заметьте, вообще не возникает вопроса "а можно ли сделать какой-нибудь шарлатанский метод, но попроще"?
На ST просто объявляешь массив и делаешь. 5-10 строк кода максимум. И вообще не стоит вопрос "слишком теоретик"

2) Надеюсь, вам-то не нужно доказывать, что xorshift128 более случайный алгоритм, чем ваш LCG?
Это не в контексте "rnd1024 не нужен", а в контексте "если уж зачем-то понадобился ГСЧ, то грех не использовать нормальные ГСЧ, например, xorshift128".

3) И, заметьте, я провожу границу не по ПР/ПЛК, а по ST / ОЛ. Почти наверняка в текущем ПР (с точки зрения железа) можно сделать "нормальную честную тасовку". Но сама среда ОЛ не предоставляет средств для работы с массивами, поэтому и вы и начинаете "да никому не нужно это ГСЧ на ПР", "а зачем на ПР идеальное лото" и т.п.
Если бы можно было по-нормальному сделать, то и вопросов бы вообще не возникало. Просто взять сделать макрос тасовки чисел (ну, как в wikipedia написано).

4) Надеюсь, вы не будете против, но я напомню, что текущая тема -- простой ГСЧ. Без всяких дополнительных требований вроде "ГСЧ без повторений".
"ГСЧ без повторений", не вопрос, можно обсуждать, но это за гранью текущей темы. Это не значит, что "ГСЧ без повторений" вообще никому не нужен. Но называть "ГСЧ без повторений как самым правильным и самым нужным генератором" тоже неправильно. Для каких-то задач он может потребоваться. Но базовый блок -- это простой ГСЧ, который может (и должен!) выдавать повторения (хоть по 5-10 раз подряд)

Более того - на практике мой не идеальный ГСЧ становится идеальным, если сюда добавить что СЧ генерируется каждый такт, а пользователю СЧ нужно раз в час, причём по запросу, т.е. для ПР - в случайный момент времени.

Становится идеальным? Реально? Откуда уверенность?
Да, я много раз соглашался с тем, что тактование добавляет энтропию. Но "идеальным" от тактования генератор уж точно не становится.

С такими реальными исходными данными ГСЧ может просто перебирать числа от 0 до n по порядку каждый такт, и всё равно такое число будет случайным(!) для пользователя.
И т.д.

Казалось бы, но нет. У вас предположение, что "запрос на число" приходит в совершенно случайный момент времени.
Если же эта случайность не совершенная, то всё пропало.

Да, можно сделать CTUD и считать, что "значения уж точно будут случайными". Но, это будет шарлатанство чистой воды, а не ГСЧ.

[rovki]

Обьясняю популярно - Массив не важно как организован имеет свойство переполнятся ,как в задаче про бассейн .Если труба что наполняет более толстая ,а та что на сливе тоньше ,то через некоторое время массив переполнится .Если вы будите останавливать генерацию СЧ (не вызывать) после вычисления одного СЧ ,то начав новую генерацию вы получите тоже число .если не будите останавливать генерацию СЧ ,а будите считывать в произвольное время или периодически ,то можете получить последовательность с большим числом "склеек" .Если вам нужно сформировать конечное количество СЧ ,то можно каждое число записать в массив ,а потом хоть год анализировать и считывать ,но такая задача не стоит .
Задачи формирует пользователь ,а не разработчик .Мне нужен такой макрос ,а вы мне предлагаете "простой",да пусть он хоть трижды будет правильным и красивым ,но мне нужен другой ,причем я это сформулировал заранее ,а не на ходу ,что бы вас завести в тупик .Хочу СПОРТЛОТО.

[Владимир Ситников]

Задачи формирует пользователь ,а не разработчик .Мне нужен такой макрос ,а вы мне предлагаете "простой",да пусть он хоть трижды будет правильным и красивым ,но мне нужен другой ,причем я это сформулировал заранее ,а не на ходу ,что бы вас завести в тупик .Хочу СПОРТЛОТО.

Заводите свою тему. Ещё раз повторю: эта тема про _простой_ ГСЧ. Если вам нужен "другой" -- создавайте отдельную тему, и не засоряйте тему про ГСЧ.

Обьясняю популярно - Массив не важно как организован имеет свойство переполнятся ,как в задаче про бассейн .Если труба что наполняет более толстая ,а та что на сливе тоньше ,то через некоторое время массив переполнится .Если вы будите останавливать генерацию СЧ (не вызывать) после вычисления одного СЧ ,то начав новую генерацию вы получите тоже число .если не будите останавливать генерацию СЧ ,а будите считывать в произвольное время или периодически ,то можете получить последовательность с большим числом "склеек" .Если вам нужно сформировать конечное количество СЧ ,то можно каждое число записать в массив ,а потом хоть год анализировать и считывать ,но такая задача не стоит .

Вы о чём пишете вообще?
Мой ответ -- rnd1024. Там используется массив. И этот массив не переполняется.
Поэтому все ваши объяснения "массив переполнится" -- мимо.

Я, конечно, могу показать пример на Java/ST с массивом и правильной генерацией, где будет очевидно, что ничего не переполняется. Но вот перенести этот код на ОЛ будет тяжело -- в ОЛ нет нормальных массивов.

[rovki]

RND1024 для фиксированного количества CЧ ,я же говорю о не прерывной генерации .И если не будет повторений в 1024 числах ,то в следующей генерации все повторится .Если вы этот массив 1024 не успеете обработать и запустится новый процесс генерации ,то этот массив затрется новыми значениями и на стыках могут появится "склейки" из одинаковых чисел .Ну все заканчиваю ,дел по горло ,а с вами каши не сваришь ,только щи из воды...
Да эту тему то же не вы создали и благодаря вам она оказалась на помойке (курилке) ,как и большенство не востребованных ваших тем ждут своей очереди .