Ограничение кеша индикатора. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...
Скорее всего вот этот вариант сможет помочь. Можно рабочий максбар выставить в 100 000, а из индикаторов по необходимости запрашивать бОльшую глубину. Но это только предположения - в реализации могут вылезти серьезные проблемы.
...Навскидку ответить не смогу (кроме общих проблем со своевременной готовностью всех связанных данных), так как не описано в каком месте у Вас появилась проблема.
Лучше с готовым примером и описанием проблемы напрямую обратиться в сервисдеск к разработчикам.
Проблема появилась уже при запуске А2 когда он входит в калькуляте данные всех требуемых А3 ещё не готовы тк А3 одного из символов до сих пор не может получить данные.
Обычно это символ не очень часто используемый, и как результат наверняка кешируется по остаточному принципу (но это уже догадки).
И ещё, тк я заполняю в буферы индикатора не всю историю то мне на вне необходимо передать количесво заполненных данных, для чего создаётся ещё один параметричекий буфер передающий 4 значения. Количество данных (не ратес тотал а реально заполненных данных) даты начала и окончания (требуется для последующей межсимвольной синхронизации) и флаг успешности расчёта(тк может возникнуть ситуация что по данному символу нет файла истории для парсинга).
И вот ради этих 4-х данных индикатор так же выделяет в кеше 4 000 000 памяти. Тут концепция выделения памяти не выдерживает никакой критики.
ЗЫ те программное ограничение выделяемой под буфер памяти нужно однозначно.
ЗЗЫ Ну а если реализуете передачу массивов через пользовательское событие (как это описано в Передача данных между индикаторами - простое решение наболевшей проблемы) но на уровне языка (чтоб без длл) то это будет полный фурор.
То есть, вопрос сводится к тому, чтобы из MQL5 задавать желаемое ограничение глубины индикатора?
Если в кеше нет данных, то кеш открывается на указанную глубину, но если кто-то другой (например, чарт) запросит больше, то кеш перестроится и пересчитается заново. Так?
Я ещё раз переосмыслил ваше сообщение:
для начала нужно разделить индикаторы на рисуемые и расчётные.
В индикаторах где не заданы параметры отрисовки буфера (вот эти например)
выделение памяти должно управляться через ArrayResize().
дальше можно развить эту концепцию и управлять выделением памяти под каждый буфер в отдельности, те если свойство не задано то выделение идёт стандартно, если же задано то выделение памяти ограничено и ни при каких новых барах без санкции на то ArrayResize() память не выделяется.
Я ещё раз переосмыслил ваше сообщение:
для начала нужно разделить индикаторы на рисуемые и расчётные.
Базовый кеш истории не может быть разным для разных чартов и индикаторов - это принципиальный момент. То есть, не может быть такого, чтобы размер кеша истории отличался от буфера индикатора.
Кеш можно изначально заявлять определенного размера (отличного от максбарс) и растить его вглубь.
Базовый кеш истории не может быть разным для разных чартов и индикаторов - это принципиальный момент. То есть, не может быть такого, чтобы размер кеша истории отличался от буфера индикатора.
Кеш можно изначально заявлять определенного размера (отличного от максбарс) и растить его вглубь.
Как вариант передавать на вне массивы не заявленные как индикаторные буфера? Над их длинной то, полный контроль имеется.
ЗЫ те если будет болтаться один буфер индикатора на всю длину это не страшно, зато к примеру 8 расчётных массивов будут подконтрольны по длине и свободно передаваемые на вне. Синтаксис обозначения какой массив передаётся на вне это уже вопрос реализации.
Как вариант передавать на вне массивы не заявленные как индикаторные буфера? Над их длинной то, есть полный контроль.
ЗЫ те если будет болтаться один буфер индикатора на всю длинну это не страшно, зато к примеру 8 расчётных массивов будут подконтрольны по длинне и свободно передаваемые на вне. Синтаксис обозначения какой массив передаётся на вне это уже вопрос реализации.
Свободная передача массивов (с контролируемым пользователем размером) в/из индикаторы для отрисовки (и для других полезных в хозяйстве поручений) было бы просто СУПЕР.
Это не очень-то просто сделать. Хотя очень хочется иметь такой механизм. Возможно, оптимальной реализацией, с точки зрения универсальности и совокупных затрат, было бы расширение и развитие концепции глобальных переменных. Например, сделать тип Object встроенным, и реализовать на уровне терминала глобальные переменные типа "Object & сыновья" при этом все динамические массивы и строки унаследовать от него же (от Object). Идея, возможно, сыровата, но доработать до практичной конструкции мне кажется возможно.
// Может быть что-то типа Variant, реализованного как контейнер для произвольных объектов. Наверное основная проблема здесь - динамический контроль типов.
// Если слишком сложно сделать глобальные переменные произвольных пользовательских типов (в рамках наследования от Object), то реализовать хотя-бы глобальные переменные-массивы стандартных (встроенных) типов.
Это бы сняло проблемы с принятием решения о времени жизни и хранении Shared-объектов между сессиями и - на уровне глобальных переменных уже есть разделение на "хранимые" и "односессионные" переменные.
Я не утверждаю, что это "единственно-возможное" или "самое правильное" решение, просто плохо представляю себе простую реализацию передачи из потока в поток через события массивов и других сложно структурированных или просто объёмистых объектов, относительно которых передача по значению выглядит неразумной. Передача же по ссылке всегда означает расшаривание памяти со всеми вытекающими проблемами реализации.
Это не очень-то просто сделать. Хотя очень хочется иметь такой механизм. Возможно, оптимальной реализацией, с точки зрения универсальности и совокупных затрат, было бы расширение и развитие концепции глобальных переменных. Например, сделать тип Object встроенным, и реализовать на уровне терминала глобальные переменные типа "Object & сыновья" при этом все динамические массивы и строки унаследовать от него же (от Object). Идея, возможно, сыровата, но доработать до практичной конструкции мне кажется возможно.
// Может быть что-то типа Variant, реализованного как контейнер для произвольных объектов. Наверное основная проблема здесь - динамический контроль типов.
// Если слишком сложно сделать глобальные переменные произвольных пользовательских типов (в рамках наследования от Object), то реализовать хотя-бы глобальные переменные-массивы стандартных (встроенных) типов.
Это бы сняло проблемы с принятием решения о времени жизни и хранении Shared-объектов между сессиями и - на уровне глобальных переменных уже есть разделение на "хранимые" и "односессионные" переменные.
Я не утверждаю, что это "единственно-возможное" или "самое правильное" решение, просто плохо представляю себе простую реализацию передачи из потока в поток через события массивов и других сложно структурированных или просто объёмистых объектов, относительно которых передача по значению выглядит неразумной. Передача же по ссылке всегда означает расшаривание памяти со всеми вытекающими проблемами реализации.
Вы читали статью Передача данных между индикаторами - простое решение наболевшей проблемы ?
обернуть С++ методы описанные в статье в mql5 обёртки (чтоб программист не имел прямого доступа к ячейке памяти) и передавать через событие указатели. Вот только не силён я в безопасности, насколько это может быть опасно в контексте вскрытия кода mql5 ?
Если же этот метод не идёт в разрез безопасности то проблем с реализацией нет.
Вы читали статью Передача данных между индикаторами - простое решение наболевшей проблемы ?
обернуть С++ методы описанные в статье в mql5 обёртки (чтоб программист не имел прямого доступа к ячейке памяти) и передавать через событие указатели. Вот только не силён я в безопасности, насколько это может быть опасно в контексте вскрытия кода mql5 ?
Если же этот метод не идёт в разрез безопасности то проблем с реализацией нет.
Я читал. Спасибо что напомнил, сейчас сижу перечитываю. Возможно буду этот механизм юзать (только модифицирую слегка).
Что до "фицияльного" внедрения этой фишки в mql5 - сильно сомневаюсь. Здесь используется работа с указателями, которых в mql нет и не будет (мой прогноз).
Ибо управляемый доступ к памяти, является одной из основопологающих концепций mql-программирования с позиций МетаКвотов (Ренат, поправьте, если неправ). И то, что они лояльно относятся к подобному хакерству (хотя и достаточно интеллегентному), вовсе не означает, что они будут внедрять эти же механизмы в "фицияльный" mql. Мне кажется, даже "хорошо обёрнутая" реализация подобного механизма, повлечёт за собой как минимум декларирование какого-то нового механизма разделения памяти, со своими mql-правилами доступа (включая набор соответствующих ограничений). Хотя это и возможно. Почему бы и нет.
А в плане запроса к разработчикам "давайте уже что-то делать, нужен нормальный совместный доступ к массивам" - я горячо поддерживаю. Да, доступ к "соседям" нужен. Да, очень нужен. Да, желательно решать на уровне mql...