Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
То есть, можно будет иметь очень быстрый индикатор с такой вот конструкцией?
Скорее нет, OnCalculate будет вызываться не на каждом тике, а после пачки тиков.
Если это так, то это отличная новость!
У нас есть идея для индикаторов, которые не содержат флага #property tester_everytick_calculate, включать режим расчета на основе приема пачки тиков, а не на каждом тике.
Это позволит кардинально решить проблему тормозных индикаторов, сохранив возможность гарантированной обработки каждого тика для некоторых индикаторов.
Предлагаю другое решение.
SymbolInfoTick
Возвращает текущие цены для указанного символа в переменной типа MqlTick.
Параметры
Возвращаемое значение
Тогда в OnCalculate достаточно будет прописать только такую конструкцию
Такое решение видится более гибким и удобным и в плане использования и реализации.
ЗЫ Еще лучше было бы нумерация тиков, с возможностью получить номер текущего и индикаторного тика. Но такой вариант более сложный для разработчиков. Поэтому, наверное, не стоит.
Предлагаю другое решение.
Если же ничего не делать со стороны разработчиков (между прочим это очень хороший вариант), то можно и сейчас обойти все тормоза таким образом
Если же ничего не делать со стороны разработчиков (между прочим это очень хороший вариант), то можно и сейчас обойти все тормоза таким образом
Ну вот не нужны тики посреди бара, все равно принудительно пропускаются. Давайте дождемся реализации от mql.
Ну вот не нужны тики посреди бара, все равно принудительно пропускаются. Давайте дождемся реализации от mql.
Честно говоря, не понимаю, что мешало страждущим написать решение своей проблемы самим?
И почему разработчики должны здесь что-то менять?
Решение выше можно оформить в виде mqh-файла и одной строкой подключать к любому индикатору, как это, например, делается в Init_Sync. Но там хоть реально кода пришлось написать прилично и не очевидного. А здесь простые несколько строк.
С заморозкой обновления чужого невидимого таймфрейма после реконнекта связи разобрались и исправили. Причина была в неправильных статусах кеша именно после реконнекта.
Бета версия 1946 доступна через Help -> Check Desktop Updates -> Latest Beta Version.
Ринат, 3 дня тестов проблем нет, спасибо!
Честно говоря, не понимаю, что мешало страждущим написать решение своей проблемы самим?
И почему разработчики должны здесь что-то менять?
Страждущие никак не могут изменить количество приходящих тиков в индикатор, они их пропускают в индикаторе до нового бара, если индикатор долго считает, то тики все равно пропускаются. Под реалии как-то приходится подстраиваться.
Если для одного символа пиковое значение ~800 тиков в минуту, то для синтетика из нескольких символов уже 2300 тиков в минуту. Открыв один синтетик и один символ из него - пик ~3000 тиков в минуту. Добавим еще другой таймфрейм того же синтетика и того же символа, и получаем... Хорошо, экранов Элдера было три, получаем пиково ~9000 тиков в минуту или 150 тиков в секунду. Ринат уже написал про вопросы производительности. Зачем пропускать через мультисимвольный-мтф индикатор холостые 150 тиков в секунду, если нужен 1-н тик в минуту для всех тф символа? Аналогично, в преимуществах хостинга mql указывается отсутствие накладных расходов со стороны хост системы, терминал это тот же хост только для индикаторов и экспертов. Если расчет индикатора состоит из RSI(3) + EMA(5)+ EMA(7), то конечно, никакой проблемы в ближайшие 10 лет пока не предвидится.
В синтетиках(фактически мультисимвольный индикатор от терминала) Разработчики как-то придумали слепливать несколько символов, зачем дублировать элементы этой системы(допустим даже не идеальной) на уровне рукоблудства программера в индикаторе? Если систему можно упростить, то почему бы это не сделать. Когда еще земля стояла на трех слонах, 5-и секундный тф не просто так придумали.
Upd. Можно ввести тф 5 секунд без истории и на нем тики соответственно только раз в 5 секунд, а также оттестировать всякие решения(компиляция индикатора с каким нибудь префиксом для работы только на 5S, другие индикаторы на нем не будут запускаться) - существующая идеология терминала не трогается, поэтому можно будет менять и переиначивать решения, а лучшее/оптимальное решение в ходе тестирования образуется.
(СУВЖ к Вашим разработкам библиотек, синтетикам, открепленным окнам и т.д. Разработчиков).
Да хоть миллион тиков в минуту, от этого решение не рабочим не становится.
Да хоть миллион тиков в минуту, от этого решение не рабочим не становится.
Вопрос не к рабочести решения. Целесообразность вызова индикатора на каждом дошедшем до него тике, перед которым неизвестное количество тиков было пропущено, к тому же рассматривается некое устаревание тика ??? Раз что то пропускается(с ростом нагрузки) и не известна актуальность пришедшего тика, то аналитическую задачу привязанную ко времени эта ситуация не решает - если нет, то зачем с этим заморачиваться. Вообще запретить поток тиков в индикаторы, оставить тики в индикатор от платформы раз в 5 секунд - в минуту 12 тиков, этого достаточно.
Вопрос не к рабочести решения. Целесообразность вызова индикатора на каждом дошедшем до него тике, перед которым неизвестное количество тиков было пропущено, к тому же рассматривается некое устаревание тика ??? Раз что то пропускается(с ростом нагрузки) и не известна актуальность пришедшего тика, то аналитическую задачу привязанную ко времени эта ситуация не решает - если нет, то зачем с этим заморачиваться. Вообще запретить поток тиков в индикаторы, оставить тики в индикатор от платформы раз в 5 секунд - в минуту 12 тиков, этого достаточно.
Глупость.