Особенности языка mql5, тонкости и приёмы работы - страница 136
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Т.е. Вы готовы поджечь 100-долларовую купюру, чтобы найти закатившуюся под кровать 10 центовую монетку?
Может быть монеткой, а может и нет
Вероятность десятки в два раза выше. А самое главное - заявление о дороговизне get_rand() высосаны из пальца, так зачем получать случайные числа через задний проход со сдвинутой вероятностью (ожидая при этом равномерное распределение) когда можно нормально? Вы не 100-долларовую купюру экономите, а спички.
Может быть монеткой, а может и нет
Вероятность десятки в два раза выше. А самое главное - заявление о дороговизне get_rand() высосаны из пальца, так зачем получать случайные числа через задний проход со сдвинутой вероятностью (ожидая при этом равномерное распределение) когда можно нормально? Вы не 100-долларовую купюру экономите, а спички.
Да, был неправ по поводу сильной медлительности Вашей функции. Неправильно понял алгоритм. Сорян.
Но все же мой алгоритм получается самый быстрый из всех предложенных не смотря на то, что он более универсален, а не ограничен числом 32767, как Ваш.
Код в доказательство.
В данном скрипте рандомно генерируется массив точек со случайным цветом и случайными координатами. Размер массива равен количеству пикселей на чарте графика. Это повторяется 5 раз
Цифры подобрал таким образом, чтобы продемонстрировать суть проблемы, когда применяем rand()%20000
как должно быть:
ЗЫ но для 99.9% случаев прокатит и такая функция: она будет работать еще быстрее.в этой функции будет генерироваться случайное число от 0 до 1073741824. это число даже больше чем количество тиков по любому инструменту за всю историю. "Нечестность" такой функции будет микроскопической для 99,9% задач.
Но все же мой алгоритм получается самый быстрый из всех предложенных не смотря на то, что он более универсален, а не ограничен числом 32767, как Ваш.
Код в доказательство.
Спасибо за труды, действительно занятные результаты. Выходит, что функция rand() настолько быстрая, что работает быстрее арифметических операций.
Спасибо за труды, действительно занятные результаты. Выходит, что функция rand() настолько быстрая, что работает быстрее арифметических операций.
нет, не быстрее. Около наносекунды, так же как и извлечение квадратного корня из числа double. Операции +-*/ выполняются за доли наносекунды.
Но как и квадратный корень, так и rand() выполняется в современных процессорах на уровне "железа", а не программно.
нет, не быстрее. Около наносекунды, так же как и извлечение квадратного корня из числа double. Операции +-*/ выполняются за доли наносекунды.
Но как и квадратный корень, так и rand() выполняется в современных процессорах на уровне "железа", а не программно.
Почему же нет, если да. Ваш вариант отличается от моего тем, что у вас всегда вызывается 5 rand(), а у меня: в среднем 1.64 раз при диапазоне 20000, и 1 раз при диапазоне 256. Итого на каждую итерацию у вас rand() вызывается 25 раз, а у меня 1.64*2+3 = 5.3 раза. Вообще конечно странная ситуация, надо выяснять в чём именно причина. У вас же там ещё и куча битовых операций выполняется вдобавок...
1. Ну мы ведь понимаем, что в ваших функциях проблема не решается, а лишь маскируется, не буду худеть, а затяну ремень потуже.
2. В наших с Алексеем вариантах это худший вариант работы, во многих других ситуациях скорость будет чуть ли не на уровне rand(), у вас же время постоянно.
3. Не задумывались - почему rand() генерит числа в столь узком диапазоне? Это псевдослучайный генератор, а значит периодический, следовательно, генеря кучу случайных чисел там где это не нужно с последующим их отбросом, ухудшается его качество (пойдут повторения раньше).
4. Некоторые добывают случайные данные более сложным путём. Я, например, дёргал с сети, кто-то может даже покупает. Вот зачем мне тратить полученные с трудом данные для того чтобы потом тупо отбросить (генеря ulong, писать правильный алгоритм - ведь не наш путь)?
Почему же нет, если да. Ваш вариант отличается от моего тем, что у вас всегда вызывается 5 rand(), а у меня: в среднем 1.64 раз при диапазоне 20000, и 1 раз при диапазоне 256. Итого на каждую итерацию у вас rand() вызывается 25 раз, а у меня 1.64*2+3 = 5.3 раза. Вообще конечно странная ситуация, надо выяснять в чём именно причина. Потому что у вас же там ещё и куча битовых операций выполняется вдобавок...
битовые самые дешевые операции. Почти бесплатные.
Но в целом согласен. Тоже не понимаю почему... Может чудеса оптимизации. Хотя что там можно оптимизировать...
битовые самые дешевые операции. Почти бесплатные.
Но в целом согласен. Тоже не понимаю почему... Может чудеса оптимизации. Хотя что там можно оптимизировать...
1. Ну мы ведь понимаем, что в ваших функциях проблема не решается, а лишь маскируется, не буду худеть, а затяну ремень потуже.
2. В наших с Алексеем вариантах это худший вариант работы, во многих других ситуациях скорость будет чуть ли не на уровне rand(), у вас же время постоянно.
3. Не задумывались - почему rand() генерит числа в столь узком диапазоне? Это псевдослучайный генератор, а значит периодический, следовательно, генеря кучу случайных чисел там где это не нужно с последующим их отбросом, ухудшается его качество (пойдут повторения раньше).
4. Некоторые добывают случайные данные более сложным путём. Я, например, дёргал с сети, кто-то может даже покупает. Вот зачем мне тратить полученные с трудом данные для того чтобы потом тупо отбросить (генеря ulong, писать правильный алгоритм - ведь не наш путь)?
ну это уже занудство.
Чтобы воспроизвести ситуацию, когда эта проблема будет заметна хоть на 0.1% нужно оперировать диапазонами выше следующих значений:
Вы хоть раз использовали такие диапазоны? Тогда зачем вставлять эти проверки и циклы?
Лучшее - враг хорошего.
Лично мои диапазоны генерации случайных чисел на практике ограничены 2000, максимум 4000. Для этого вполне сносно работает rand()
Вставьте в мой код такой вариант:
и Вы уже глазами не заметите "нечестность" функции rand() (как было с вариантом rand()%20000) и точки будут располагаться визуально равномерно, так что она вполне себе рабочая и самая быстрая.
ЗЫ Не даром же разработчики процессоров ограничили rand() значением 2^15=32768. Они же не глупые люди. Это вполне покрывает 99% практических задач.
А для любителей "запредельных" идей более чем достаточно варианта:
Лично мои диапазоны генерации случайных чисел на практике ограничены 2000, максимум 4000. Для этого вполне сносно работает rand()
Вставьте в мой код такой вариант:
и Вы уже глазами не заметите "нечестность" функции rand() (как было с вариантом rand()%20000) и точки будут располагаться визуально равномерно, так что она вполне себе рабочая и самая быстрая.
Пользуйтесь на здровье, я не против. Тем более когда справа от % стоит число кратное RAND_MAX+1 (256 или 1024).
А для любителей "запредельных" идей более чем достаточно варианта:
При чём тут разработчики процессоров? Генератор - программно реализован. Единственное требование RAND_MAX >= 32767 и период не менее 2^32. Так что в мкл очень скудный генератор на "минималках".
А самые дальновидные будут делать себе честный rand() (если нет кратности), это даже в справочниках рекомендуется.