Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Глупость.
Глупость.
До тех пор, покуда "внезапно"(с) не встает вопрос ограниченной производительности системы(не принципиально какой).
Эти дни присматривался к работает OnCalculate и обработке тиковых данных. Ранее писалось, что все делается для избежания "заморозки" криво написанных индикаторов, но если и в самом деле нужно обрабатывать весь поток тиковых данных с момента предыдущего вызова OnCalculate, то при стремительном движении(и откате) цены мы должны получить достаточно "глубокий" массив, есть ли ограничения на глубину тикового массива?
Не хотелось бы услышать ответ, типа "в OnCalculate при такой ситуации, будет получен аккумулирующий тик(и)..., для оптимизации ...".
Кто уже занимается анализом тиковых данных, если ли основания для подобных опасений?
Эти дни присматривался к работает OnCalculate и обработке тиковых данных. Ранее писалось, что все делается для избежания "заморозки" криво написанных индикаторов, но если и в самом деле нужно обрабатывать весь поток тиковых данных с момента предыдущего вызова OnCalculate, то при стремительном движении(и откате) цены мы должны получить достаточно "глубокий" массив, есть ли ограничения на глубину тикового массива?
Не хотелось бы услышать ответ, типа "в OnCalculate при такой ситуации, будет получен аккумулирующий тик(и)..., для оптимизации ...".
Кто уже занимается анализом тиковых данных, если ли основания для подобных опасений?
В 2008-2009 Ренат както написал, что в тиках счастья нет, приводил пример эксперта. Тики и так пропускаются. Если надо, то на каждом вызове получайте https://www.mql5.com/ru/docs/series/copyticks , но желаемую для входа вершину/впадину 50/50 все равно пропустите.
Я здесь пожалуй для массовки отмечусь. Уже месяц пытаюсь понять, почему перестало работать вот это:
Ждем новый релиз на Открытии.
Возобновляю вопросы связанные с оптимизацией и загрузкой исторических данных.
1. Проблема корректной работы функций из набора iClose/iOpen, а данном случае iTime существует и думаю ожидать, что будет все идеально наверное нету смысла. Тогда может их просто убрать из MQL5, чтобы мы лишний раз не наступали на одни и те же грабли? (есть проблема но описывать нету времени, так как нашел решение , очередной "выверташь")
2. Быть может есть какое-то решение, но хотелось бы чтобы оно было документированным, а не очередной выверташь сообщества MQL5. Речь идет о том, как нам быть с асинхронными запросами, которые в свою очередь синхронизируют локальные БД к примеру:
Ключевая фраза "После окончания синхронизации при последующем вызове CopyTicks() вернёт все запрашиваемые тики.", господа как узнать об окончании синхронизации??? Написано так, будто до окончании синхронизации CopyTicks() возвращает к примеру -1, но это не так. Как результат после нескольких перезагрузок индикатора БД синхронизируется и мы действительно получаем весь набор данных, но если я не буду индикатор передергивать то и не получу этот набор, так как я не знаю результата завершения этой чертовой синхронизации.
Ярким примером стали прошедшие стуки, по EURUSD было резкое движение, хоть индикатор и был все это время включен и как бы нормально отрисовал этот период, но после того как его перезагрузил(изменил входные параметры), индикатор стал отражать информацию не корректно, соответственно начались поиски ошибок в индикаторе(несколько раз перекомпилил и перегрузил) но ничего не помогало, а потом произошло то самое "чудо", "При вызове из индикатора CopyTick() сразу же вернёт доступные по символу тики, а также запустит синхронизацию базы тиков", быть может все таки стоит создать(или есть) функция которая может нам подсказать, что в текущий момент синхронизация локальной БД не завершена, эта функция облегчила бы нам задачу и свою очередь позволила бы писать более качественный коненчный продукт для Маркета.
P.S.: Функция SymbolInfoTick к сожалению не обладает таким функционалом.
К сожалению, данный пример не всегда работает:
А точнее работает 1-2 раза из 10 случаев.
Но в выше описанной ситуации не сработал ни разу.
Опять же вопрос, БД обновляется в реалтайме?
Как писал выше, весь период что был проблемным, индикатор работал, т.е. вызов функции CopyTicks() осуществлялся регулярно, но как выясняется это никак не влияло на локальную БД.... Это странно....
В 2008-2009 Ренат както написал, что в тиках счастья нет, приводил пример эксперта. Тики и так пропускаются. Если надо, то на каждом вызове получайте https://www.mql5.com/ru/docs/series/copyticks , но желаемую для входа вершину/впадину 50/50 все равно пропустите.
Возобновляю вопросы связанные с оптимизацией и загрузкой исторических данных.
1. Проблема корректной работы функций из набора iClose/iOpen, а данном случае iTime существует и думаю ожидать, что будет все идеально наверное нету смысла. Тогда может их просто убрать из MQL5, чтобы мы лишний раз не наступали на одни и те же грабли? (есть проблема но описывать нету времени, так как нашел решение , очередной "выверташь")
2. Быть может есть какое-то решение, но хотелось бы чтобы оно было документированным, а не очередной выверташь сообщества MQL5. Речь идет о том, как нам быть с асинхронными запросами, которые в свою очередь синхронизируют локальные БД к примеру:
Ключевая фраза "После окончания синхронизации при последующем вызове CopyTicks() вернёт все запрашиваемые тики.", господа как узнать об окончании синхронизации??? Написано так, будто до окончании синхронизации CopyTicks() возвращает к примеру -1, но это не так. Как результат после нескольких перезагрузок индикатора БД синхронизируется и мы действительно получаем весь набор данных, но если я не буду индикатор передергивать то и не получу этот набор, так как я не знаю результата завершения этой чертовой синхронизации.
Ярким примером стали прошедшие стуки, по EURUSD было резкое движение, хоть индикатор и был все это время включен и как бы нормально отрисовал этот период, но после того как его перезагрузил(изменил входные параметры), индикатор стал отражать информацию не корректно, соответственно начались поиски ошибок в индикаторе(несколько раз перекомпилил и перегрузил) но ничего не помогало, а потом произошло то самое "чудо", "При вызове из индикатора CopyTick() сразу же вернёт доступные по символу тики, а также запустит синхронизацию базы тиков", быть может все таки стоит создать(или есть) функция которая может нам подсказать, что в текущий момент синхронизация локальной БД не завершена, эта функция облегчила бы нам задачу и свою очередь позволила бы писать более качественный коненчный продукт для Маркета.
P.S.: Функция SymbolInfoTick к сожалению не обладает таким функционалом.
Что возвращает SERIES_SYNCHRONIZED в таких случаях?