MT4 iMAOnArray и iBandsOnArray влияние количества элементов на расчёты - страница 4

 
Sergey Efimenko:
А эта библиотека считает правильно, если задать расчёт не всего массива, а только его последней части (текущих значений)? Кроме того это только половина задачи, а как быть iBandsOnArray?

Там есть параметр "begin" попробуйте его ограничить.

Было время, когда функция iMAOnArray сильно тормозила. Вообщем у меня был код который примерно оптимизировался часа три на  iMAOnArray, потом эта функция стала тормозить и оптимизация длилась часов 30.

Не знаю, может это сейчас исправили. Но, когда сделал индикатор  MovingAverages.mqh, тот же код посчитался за часа полтора, то есть время сократилось в два раза.

На счет  iBandsOnArray нечего сказать, на mql4 такого включаемого файла, с той же задачей не видел.

 
С iBandsOnArray на запуске индикатор тормозит. Переделал на iStdDevOnArray, моментально запускается. 
 
Alexey Viktorov:

Держи.

Да уж... Мальчик, сходи погуляй.
 
Dmitry Fedoseev:
С iBandsOnArray на запуске индикатор тормозит. Переделал на iStdDevOnArray, моментально запускается. 
Вот только в тестере тормозит и с iBandsOnArray и с iStdDevOnArray.
 
Dmitry Fedoseev:
Вот только в тестере тормозит и с iBandsOnArray и с iStdDevOnArray.
Когда-то я думал что ты хороший программист. А на самом деле ты только пальцы можешь растопыривать да ссориться. Тебе не дают что-ли, потому ты злой такой?
 
Alexey Viktorov:

Держи.

А теперь сравните результат вашего кода и оригинала в режиме сглаживания прямых LWMA или SMMA и получите разные значения, т.к. в своих расчётах эти два вида сглаживания используют свои же предыдущие значения, а используя каждый раз только N элементов периода, вы, соответственно, теряете эти данные, кроме того мне в итоге нужны разные периоды расчёта для iBands и iMA, стало быть копировать нужно будет дважды. Причем исходный массив для расчёта используется один и тот же. Логика ваших рассуждений мне понятна, но она ошибочна, ибо уменьшая длину массива, но при этом каждый раз делая копию и рассчитывая заново все его элементы вы в итоге увеличиваете суммарное время расчёта индикатора при оптимизации или работе он-лайн с несколькими версиями индикатора для разных ТФ. В моём же случае тормозит только первичный расчёт при инициализации, далее считается только 1 новый элемент. Проблема в самой реализации данных функций у MQL. Самописные варианты работают лучше и быстрее. Делайте выводы.
 
Dmitry Fedoseev:
Да уж... Мальчик, сходи погуляй.
Это не мальчик, а очень взрослый человек. Хотя привычка обращения ко всем на "ты" не делает ему уважения, имхо :)
 
Sergey Efimenko:
Это не мальчик, а очень взрослый человек. Хотя привычка обращения ко всем на "ты" не делает ему уважения, имхо :)
Очень взрослый это как? Пенсионер в маразме?
 
Sergey Efimenko:
А теперь сравните результат вашего кода и оригинала в режиме сглаживания прямых LWMA или SMMA и получите разные значения, т.к. в своих расчётах эти два вида сглаживания используют свои же предыдущие значения, а используя каждый раз только N элементов периода, вы, соответственно, теряете эти данные, кроме того мне в итоге нужны разные периоды расчёта для iBands и iMA, стало быть копировать нужно будет дважды. Причем исходноый массив для расчёта используется один и тот же. Логика ваших рассуждений мне понятна, но она ошибочна, ибо уменьшая длину массива, но при этом каждый раз делая копию и рассчитывая заново все его элементы вы в итоге увеличиваете суммарное время расчёта индикатора при оптимизации или работе он-лайн с несколькими версиями индикатора для разных ТФ. В моём же случае тормозит только первичный расчёт при инициализации, далее считается только 1 новый элемент. Проблема в самой реализации данных функций у MQL. Самописные варианты работают лучше и быстрее. Делайте выводы.
Хоть и MODE_SMA совпадает, все равно не стоит такое использовать.
 
Alexey Viktorov:
Когда-то я думал что ты хороший программист. А на самом деле ты только пальцы можешь растопыривать да ссориться. Тебе не дают что-ли, потому ты злой такой?
Ну ну, мечтай.
Причина обращения: