Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вся проблема во втором цикле. Он одновременно обрабатывает левую и правую ветки от потенциального экстремума, а потому перебирает лишь (N - 1)/2 баров, но этого не достаточно. Иземерения показывают, что время затраченное на поиск экстремума в арифметической прогрессии зависит от периода N, а это очень, очень плохо:
Как минимум, одного break-а не хватает:
А лучше действительно разделить верх и низ, и останавливаться сразу после неудачной проверки.
Если ничего не помогает - попробуй OCL.
Не даст большого выигрыша.
Как минимум, одного break-а не хватает:
А лучше действительно разделить верх и низ, и останавливаться сразу после неудачной проверки.
Все же OCL (или распараллеливание в общем смысле) не является алгоритмической оптимизацией, скорее технической.
Сомневаюсь, что в вашем случае есть необходимость параллелить быстрейший O(N)-вариант решения задачи.
Еще как даст.
А без ля-ля? Покажите.
Короче удачи. Обсуждать оптимизацию алгоритма со сложностью линейно зависимой от значения параметра это видимо реально нечем заняться.
А без ля-ля? Покажите.
Короче удачи. Обсуждать оптимизацию алгоритма со сложностью линейно зависимой от значения параметра это видимо реально нечем заняться.
О.К. Допишу алгоритм, и выложу результаты распараллеливания в студию.
Все же OCL (или распараллеливание в общем смысле) не является алгоритмической оптимизацией, скорее технической.
Сомневаюсь, что в вашем случае есть необходимость параллелить быстрейший O(N)-вариант решения задачи.
Как сказать. Любое распараллеливание это всегда серьезное усложнение алгоритмов. Тем более, если не параллелить алгоритм с линейной зависимостью от количества данных, тогда что тогда имеет смысл парралелить?
Короче, перепишу алгоритм, и посмотрим что это даст.
Опять-таки разделение верха и низа выливается в два прохода for. Что в двое увеличивает время перебора. Само по себе разделение без использования многопоточности выигрыш в производительности не дает, особенно на малых n.
Откуда такая уверенность?
Моя проверка показывает обратное:
01:29:25 SpeedTest EURUSD,M15 inputs: Interations=10000; pperiod=10;
01:29:25 SpeedTest EURUSD,M15: Количество баров = 3780
01:30:46 SpeedTest EURUSD,M15: Оригинальная функция: 81.558 сек, экстремумов: 131 / 121
01:31:10 SpeedTest EURUSD,M15: С моей правкой (break): 23.291 сек, экстремумов: 131 / 121
01:31:27 SpeedTest EURUSD,M15: С разделением на циклы: 17.565 сек, экстремумов: 131 / 121
Скрипт mq4 в аттаче.
Для полноты картины еще один тест:
01:38:56 SpeedTest EURUSD,M1 inputs: Interations=1000; pperiod=100;
01:38:56 SpeedTest EURUSD,M1: Количество баров = 33896
01:50:19 SpeedTest EURUSD,M1: Оригинальная функция: 683.565 сек, экстремумов: 121 / 127
01:50:54 SpeedTest EURUSD,M1: С моей правкой (break): 34.383 сек, экстремумов: 121 / 127
01:51:16 SpeedTest EURUSD,M1: С разделением на циклы: 22.714 сек, экстремумов: 121 / 127