Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет, Владимир. Чуток не так.
В этом случае надо ArraySetAsSeries(массив, false); применять к массиву из трёхсот элементов среди которых считается iMAOnArray(). Но для этого лучше использовать CopyOpen() а не цикл заполнения массива.
Как я понимаю, в этом варианте лучше будет
Нет, Владимир. Чуток не так.
В этом случае надо ArraySetAsSeries(массив, false); применять к массиву из трёхсот элементов среди которых считается iMAOnArray(). Но для этого лучше использовать CopyOpen() а не цикл заполнения массива.
Как я понимаю, в этом варианте лучше будет
Собственно сабж. Если мне не нужно считать весь массив, а нужны только последние N элементов.
Не совсем понимаю логику расчёта этих функций при ограничении. Есть массив таймсерия (один из буферов индикатора), если оставить количество элементов равное 0 вопросов нет, всё считается и получается, но при уменьшении количества элементов участвующих в расчётах по тем же смещениям я получаю только первичные. Проще говоря есть массив 5000 элементов (баров на графике), для экономии времени мне нужно посчитать только последние 300, но при указании во втором параметре значения 300 я получаю первичные 5000-4700 элементов, но по смещению 300-0, и далее значения при вызове не меняются. Какой смысл использования этого параметра?
Хрен его знает. Забейте просто. Если надо ускорить расчеты, в своем цикле сократите количество обсчитываемых элементов.
Одно из двух: или невозможно или нужна некая тайная комбинация таймсерий, не таймсерий, направлений расчета.
Хрен его знает. Забейте просто. Если надо ускорить расчеты, в своем цикле сократите количество обсчитываемых элементов.
Одно из двух: или невозможно или нужна некая тайная комбинация таймсерий, не таймсерий, направления расчета.
Да, как уже написал чуть ранее, вариант только один - это использования собственных аналогов указанных функций, в которых как раз можно считать хоть единственный элемент.
Парадокс ситуации в том, что если сделать аналогичный шаблон, набросив на любой индикатор (линию цены) среднюю или ленты боллинджера, таких тормозов первичного расчёта всех баров истории, как при использовании этих функций в коде, при перезапуске терминала или переключении ТФ не наблюдается, вот и непонятно, что же там так долго рассчитывается в этих функциях.
Хрен его знает. Забейте просто. Если надо ускорить расчеты, в своем цикле сократите количество обсчитываемых элементов.
Одно из двух: или невозможно или нужна некая тайная комбинация таймсерий, не таймсерий, направлений расчета.
Еще применял такую конструкцию
Кстати "MovingAverages.mqh" в раза два быстрее посчитал чем, на на "iMAOnArray", даже по старой версии.
https://www.mql5.com/ru/forum/79988
Да, как уже написал чуть ранее, вариант только один - это использования собственных аналогов указанных функций, в которых как раз можно считать хоть единственный элемент.
Парадокс ситуации в том, что если сделать аналогичный шаблон, набросив на любой индикатор (линию цены) среднюю и ленты боллинджера, таких тормозов первичного расчёта всех баров истории, как при использовании этих функций в коде, при перезапуске терминала или переключении ТФ не наблюдается, вот и непонятно, что же там так долго рассчитывается в этих функциях.
Торможение даже от использование iMAOnArray? Не должно такого быть. Как ты было время, было торможение от StdOnArray (или от BandsOnArray, непомню), разработчики долго не признавали наличие бага. Потом вдруг исправили и работало быстро. Кто знает, может вернулся баг. Если и от iMAOnArray() заметное торможение, то это баг. Кажется были про это разговоры пару месяцев назад... воз и ныне там, видимо.
Торможение даже от использование iMAOnArray? Не должно такого быть. Как ты было время, было торможение от StdOnArray, разработчики долго не признавали наличие бага. Потом вдруг исправили и работало быстро. Кто знает, может вернулся баг. Если и от iMAOnArray() заметное торможение, то это баг. Кажется были про это разговоры пару месяцев назад... воз и ныне там, видимо.
Сложно судить "сильно тормозит" или допустимо, ведь всё зависит от длины графика (кол-ва баров), загвоздка в том, что для оптимизации нужно считать всего чуток, а ограничить длину расчёта по факту не получается.
Сделайте расчет на MovingAverages.mqh и все очень быстро посчитается.
Так покажите "рабочий" вариант кода, исходный код оригинала тут есть, который вы всё пытаетесь урезать до 12 отображаемых элементов, вместо запрошенных мною трёхсот, и должны в итоге получиться 3 индикаторных буфера с указанными данными, чтобы в подвале отображались минимум 300 элементов, и далее при приходе нового бара соответственно шла отрисовка 301 и далее значения, но не забывайте, что при этом в случае использования 0 в качестве ограничения расчёта, даёт пересчёт значений только нового бара, и тип средней (сглаживания) для второго буфера не обязательно будет SMA, а может быть любым из 4 доступных.
Держи.