Каков механизм расчета iCustom(....)?
механизм вызова индикаторов из mql-программ следующий:
1. анализируются входные параметры
2. производится проверка на наличие данного индикатора с данными параметрами в списке произведённых вызовов.
3. если такого индикатора с такими параметрами (идентификатор индексного массива и смещение не сравниваются, то есть как бы не считаются значимыми параметрами) нету, то он создаётся и рассчитывается
4. если такой индикатор уже есть (например, его вызывали на прошлом тике), то проверяется признак пересчёта на текущий момент и, если надо, пересчитывается (индикатор не пересчитывается, если его на данном тике уже вызывали)
5. берётся значение в соответствии с идентификатором индексного массива и смещением
1. анализируются входные параметры
2. производится проверка на наличие данного индикатора с данными параметрами в списке произведённых вызовов.
3. если такого индикатора с такими параметрами (идентификатор индексного массива и смещение не сравниваются, то есть как бы не считаются значимыми параметрами) нету, то он создаётся и рассчитывается
4. если такой индикатор уже есть (например, его вызывали на прошлом тике), то проверяется признак пересчёта на текущий момент и, если надо, пересчитывается (индикатор не пересчитывается, если его на данном тике уже вызывали)
5. берётся значение в соответствии с идентификатором индексного массива и смещением
Тогда предложение/вопрос.
Насколько сложно изменить механизм расчета индикаторов (встроенных и пользовательских) для работы тестера и в индикаторах (например с тайм-фреймом H1) для получения более значений высокого порядка (например D1).
Я предлагаю ввести в iCustom дополнительный параметр , вроде ВрЕменная_Свеча и признак вызова из тестера(при бэк-тесте) или такого индикатора. Расчет (ВрЕменная_Свеча) его пусть ляжет на плечи программиста (в крайнем случае) в виде array[Open,Low,High,Close]. Также программист сам осуществит корректное значение shift для индикатора более высокого уровня (например, через ArrayBsearch).
Что имеем? Идет вызов iCustom(,SymbolValPeriodVal,"NameofIndicator",ВрЕменная_Свеча,ПризнакВызова=True,... остальные параметры, CorrectShift).
Расчетчик, получив данный вызов функции отмечает - ПризнакВызова=True, значит механизм расчета пойдет немного по другому.
Во-первых, в новый временный массив копируются все буфера индикатора от начала(shift=Bars) до бара=CorrectShift
Второе: Зачения ВрЕменной серии в точке CorrectShift заменяются array[Open,Low,High,Close] из ВрЕменная_Свеча
Третье: Происходит по стандартной процедуре расчет индикатора в точке CorrectShift
Четвертое. Убиваются все врЕменные массивы, задействованные для этого нестандартного расчета (переполнение памяти избегаем)
Пятое: возвращаем в вызвавшую программу найденое значение.
Если ПризнакВызова=False, работает прежний механизм.
Мне кажется, такое изменение не должно разрушить архитектуру Вашей платформы.
Насколько сложно изменить механизм расчета индикаторов (встроенных и пользовательских) для работы тестера и в индикаторах (например с тайм-фреймом H1) для получения более значений высокого порядка (например D1).
Я предлагаю ввести в iCustom дополнительный параметр , вроде ВрЕменная_Свеча и признак вызова из тестера(при бэк-тесте) или такого индикатора. Расчет (ВрЕменная_Свеча) его пусть ляжет на плечи программиста (в крайнем случае) в виде array[Open,Low,High,Close]. Также программист сам осуществит корректное значение shift для индикатора более высокого уровня (например, через ArrayBsearch).
Что имеем? Идет вызов iCustom(,SymbolValPeriodVal,"NameofIndicator",ВрЕменная_Свеча,ПризнакВызова=True,... остальные параметры, CorrectShift).
Расчетчик, получив данный вызов функции отмечает - ПризнакВызова=True, значит механизм расчета пойдет немного по другому.
Во-первых, в новый временный массив копируются все буфера индикатора от начала(shift=Bars) до бара=CorrectShift
Второе: Зачения ВрЕменной серии в точке CorrectShift заменяются array[Open,Low,High,Close] из ВрЕменная_Свеча
Третье: Происходит по стандартной процедуре расчет индикатора в точке CorrectShift
Четвертое. Убиваются все врЕменные массивы, задействованные для этого нестандартного расчета (переполнение памяти избегаем)
Пятое: возвращаем в вызвавшую программу найденое значение.
Если ПризнакВызова=False, работает прежний механизм.
Мне кажется, такое изменение не должно разрушить архитектуру Вашей платформы.
К сожалению, это абсолютно не принимается.
Жаль. Насколько я понимаю, вызов индикаторов для расчета на массивах пользователя тоже исключается.
Еще вопрос. Есть ли механизмы подмены значений баров (Open,Close,High,Low,Voluem)? С обратным восстановлением? А... кажется все равно не пройдет. Нет возможности принудительно (из программы) заново рассчитать индикатор.
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Берется ли просто из заранее рассчитанного массива индикатора готовое значение, соответствующее заданному EnableShift, или "жизнь начинается с нуля"( фактически EnableShift приравнивается нулю в данный момент времени), то есть все , что есть в будущем становится невидимым, и "расчетчик" индикатора оглядывается назад и начинает считать согласно алгоритма индкатора "MyInduk"?