Особенности языка mql5, тонкости и приёмы работы - страница 235
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если перестало работать, хорошо бы узнать, а правильно ли это.
Если делать не объекты, а указатели, то и старый вариант будет работать.
Если перестало работать, хорошо бы узнать, а правильно ли это.
Если делать не объекты, а указатели, то и старый вариант будет работать.
Отличное замечание и спасибо за наводку!
Да, и в правду, с указателем ситуация отлично решается:
Любителям быстрых алгоритмов. Тем кто борется за наносекунды :)
Задача: Найти время открытия бара по заданному времени и ТФ, когда точно известно, что бар в это время существует. Например, по времени открытия и закрытия позиций.
Большинство программистов воспользуется связкой iTime и iBarShift. Это будет самая медленная реализация, особенно такая реализация требует актуальной истории закаченных данных или вычесленных массивов. Более того, такой подход может выдавать ошибки при отсутсвии нужной истории.
Более продвинутые программисты решат эту задачу через структуру MqlDateTime и фукцию TimeToStruct(). Это не плохое решение и достаточно быстрое.
Но существует третье решение, которое более производительней предыдущего решения в несколько раз:
Главная сложность в этом алгоритме - это расчет времени начала месяца (выделено зеленым цветом) Пожалуйста, не пытайтесь понять работу алгоритма. Там происходит магия, которая получилась в результате движения от простого к сложному. Обратный путь от сложного к простому пройти будет намного трудней.
Также выйгрыш в производительности обеспечивается алгоритмом получения секунд в баре из ТФ взамен стандартной функции PeriodSeconds() - выделено желтым цветом
Прикладываю тестовый скрипт, который расчитывает и сравнивает производительности всех трех методов:
Контрольная сумма с iBarShift не будет совпадать, т.к. iBarShift работает с реальными барами. Констрольная сумма будет совпадать только на MN1 и W1 таймфреймах, т.к. в истории таких баров нет дырок.
Производительности будет выше если использовать в цикле маленький временной шаг (меньше одного дня) когда начинает работать алгоритм сохранения предыдущих вычислений:
Чрезмерные значения для алгоритма через iBarShift (выделено синим цветом) обусловлено текущем отсутсвием необходимой истории или вычесленных массивом ТФ, что инициирует их закачку.
После закачи результат будет следующим:
Любителям быстрых алгоритмов. Тем кто борется за наносекунды :)
...😮😲😳🥴🤪
...
аа..
ммм...
ооооо....
гкхм... Не думал, что мой простой вопрос выльется вот всюдатакоевот.
Вот прям О
😮😲😳🥴🤪
...
аа..
ммм...
ооооо....
гкхм... Не думал, что мой простой вопрос выльется вот всюдатакоевот.
Вот прям О
да, Артем, развел ты меня на время.
Сработал спортивный интерес.
Надеюсь пригодится кому-нибудь, и мне в том числе. :))
да, Артем, развел ты меня на время.
Сработал спортивный интерес.
Надеюсь пригодится кому-нибудь, и мне в том числе. :))
Конечно пригодится. Супер. Ещё раз спасибо тебе!
ЗЫ. Вот это позабавило: "корректно считает только до 28.02.2100 !!!!"
Что потом-то делать будем?
Конечно пригодится. Супер. Ещё раз спасибо тебе!
ЗЫ. Вот это позабавило: "корректно считает только до 28.02.2100 !!!!"
Что потом-то делать будем?
хаха.
Сомневаюсь что этот алгоритм будет востребован 75 лет. Уже квантовые компьютеры наверное будут править миром, в которых совсем другое программирование.
если честно, то лениво было учитывать полностью Григорианский календарь. 2000-й был высокостным, а 2100 уже нет.
хаха.
Сомневаюсь что этот алгоритм будет востребован 75 лет. Уже квантовые компьютеры наверное будут править миром, в которых совсем другое программирование.
если честно, то лениво было учитывать полностью Григорианский календарь. 2000-й был высокостным, а 2100 уже нет.
для MN можно предрасчитанный массив использовать, там данных-то почти всего ничего
Ln2(12 месяцев * стo лет)...11 if`ов и сравнений в двоичном поиске, зато без прочих вычислений
для MN можно предрасчитанный массив использовать, там данных-то почти всего ничего
Ln2(12 месяцев * стo лет)...11 if`ов и сравнений в двоичном поиске, зато без прочих вычислений
для MN можно предрасчитанный массив использовать, там данных-то почти всего ничего
Ln2(12 месяцев * стo лет)...11 if`ов и сравнений в двоичном поиске, зато без прочих вычислений
а, сначала, неправильно прочитал.
Не - ошибаешься. Не прокатит увеличение производительности. Все равно упрешься в вычисления. Да и доступ к элементам массива очень сильно тормозит алгоритм.