Тут нужно нагенерить случайных чисел, а код на 77-м фортране, поэтому функцию из 90-го не вплетешь. Я посмотрела в сети - кто только как не предлагает, и каждый код - по странице (причем не всегда компеляемый).

Есть ли у кого опыт в этом деле, чтобы просто и понятно??

Л.

Лично я доверяю процедуре из книги Форсайта "Машинные методы математических вычислений". Вот код процедуры на F66 (77?).


Я её, конечно, переписал под F95:


Примерчик по использованию последней:

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

Мда... Бум изучать. Я вообще-то хотела если не как в матлабе, то хоть типа itime, но у меня проект крутит функции циклически-регулярно, и такая генерилка дает аккуратную синусоиду, что не комильфо с точки зрения случайных чисел.

Простоты хочется, простоты...

В чем нужна простота? В интерфейсе, в объеме кода, генерим одно число или массив. С синусоидой не совсем понял... При очередном входе можно задавать разное начальное число, например, через Cpu_Time, тогда выборка не будет повторяться, если это про это.
Добавлено @ 20:15
Али целые числа нужны...

> В чем нужна простота? В интерфейсе, в объеме кода, генерим одно число или массив.

В объеме кода, точно. Я вот сейчас размышляю - а не сгенерить ли ряд в матлабе и сунуть его кушать фортрану... Там будет красивый гауссов белый шум, без обмана...

> С синусоидой не совсем понял... При очередном входе можно задавать разное начальное число, например, через Cpu_Time, тогда выборка не будет повторяться, если это про это.

Я брала секунды момента обращения к процедуре и рескейлила в интервал [0,1). Ожидала типа равномерно распределенный шум, но код работает очень методично

Л.

Странно, я URand проверял... Быть может, не так сильно на неповторяемость.
Не понял делему: либо брать из MATLAB, либо небольшой код на Fortran. Почему так? И что еще больше будет занимать...
Тем не менее, убежден, что хороший генератор будет комбинированным, а поэтому немаленьким по коду. А код нужен из-за производительности или эстетического удовольствия?
Буду исследовать...

Думаю, с урандом все в порядке Это я балда ленивая

Ну, слава Форсайту, в смысле Фортрану. Если она все-таки не подходит или её нужно будет для массивов переделать -- тему продолжить мона.
Не знаю для каких целей и платформ тебе, но URand писалась робасто. Совет по упрощению её кода при некоторых условиях:

• Система представления чисел, на которой будет запускаться (компилиться) прога одинаковая. Например, проект будет компилиться и под винды, и под линуху и где бы то ни было ещё, но представление чисел будет то же: integer и в Африке -- integer, а real будет имееть такие же границы, скажем. В этом случае весь первый if-блок выполняем заранее для машины/платформы, сосчитав эти статические параметры датчика.
• Генерить нужно будет только real(4) или только real(8). В этом случае все константы и параметры типов задаем явно, а не через константы (R_, I_). Одно условие: integer должен занимать столько же байт, сколько генерируемый real, чтобы уместить в себе все её значащие цифры.

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

Просто я взял да посчитал все константы.
Можно убрать константы типа R_ и I_, если код ориентируется на одну разновидность (типа менять потом его не придется вдруг).
Можно поисследовать вопрос и убрать ненужные из трех if-ов. Здесь я уже не помню всех этих премудростей. Собственно, компактный датчик: убрать вначале константы разновидностей типа, сосчитать параметры датчика заранее, убрать if-ы. Но можем потерять робастость, переносимость, надежность, но полуим точно прирост в скорости, не потеряем точно.