Ошибки, баги, вопросы - страница 2180
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Понятно, что ноль.
И что - это нормально 22 секунды на решение что ноль баров в заданном временном промежутке?
Явный же алгоритмический баг внутренней реализации Bars.
А мне не понятно как вы отличаете ноль баров в заданном временном промежутке от этого ноля:
Из документации: Если данные для таймсерии с указанными параметрами при вызове функции Bars() еще не сформированы в терминале, или данные таймсерии в момент вызова функции не синхронизированы с торговым сервером, то функция вернет нулевое значение.
Другими словами как отличить результат ноль от ошибки ноль?А мне не понятно как вы отличаете ноль баров в заданном временном промежутке от этого ноля:
Из документации: Если данные для таймсерии с указанными параметрами при вызове функции Bars() еще не сформированы в терминале, или данные таймсерии в момент вызова функции не синхронизированы с торговым сервером, то функция вернет нулевое значение.
В данном вопросе не важно происхождение нуля, а важно то, что этот ноль рожается функцией Bars целую вечность в виде пару десятков секунд.
А мне не понятно как вы отличаете ноль баров в заданном временном промежутке от этого ноля:
Из документации: Если данные для таймсерии с указанными параметрами при вызове функции Bars() еще не сформированы в терминале, или данные таймсерии в момент вызова функции не синхронизированы с торговым сервером, то функция вернет нулевое значение.
Другими словами как отличить результат ноль от ошибки ноль?Ну сами посудите. Если бы перед Вами стояла задача создать аналог функции Bars и был бы дан массив datetime, значения элементов которого убывают с возрастанием номера, другими словами массив отсортированный.
Как Вы думаете - сложно реализовать алгоритм поиска количества элементов этого отсортированного массива в заданном временном промежутке? И если бы в заданном промежутке нет ни одного бара или массив еще не проинициализирован, то нужно возвращать ноль.
Да нет же - алгоритм достаточно простой. Что там может выполняться 22 секунды?
В данном вопросе не важно происхождение нуля, а важно то, что этот ноль рожается функцией Bars целую вечность в виде пару десятков секунд.
Важно именно происхождение, потому что если бы ::Bars() в случае ошибки истории возвращала бы -1, а не 0 (как сейчас) - то и задержки никакой не возникало бы. А сейчас 0 интерпретируется как ошибка и задержка возникает из-за внутренних повторов https://www.mql5.com/ru/forum/1111/page2200#comment_6955559
Более того: допустим ввели дополнительную проверку - задержка пропала. А дальше то что? Получили вы ноль. Это результат или ошибка?
Скорее всего это и связано с подгрузкой истории
Так прикол в том, что первый Print отрабатывается без задержек, т.е. история по H4 уже загружена.
А если поменять в CopyTime H4 на W1, то тормозов совсем не будет. Значит и история по W1 тоже уже загружена.
Просто Bars входит в ступор от времени находящегося в промежутке от CurrentTime() до времени открытия нулевого бара.
Важно именно происхождение, потому что если бы ::Bars() в случае ошибки истории возвращала бы -1, а не 0 (как сейчас) - то и задержки никакой не возникало бы. А сейчас 0 интерпретируется как ошибка и задержка возникает из-за внутренних повторов https://www.mql5.com/ru/forum/1111/page2200#comment_6955559
Более того: допустим ввели дополнительную проверку - задержка пропала. А дальше то что? Получили вы ноль. Это результат или ошибка?
Везде в моих алгоритмах не важно в результате чего получен ноль: не попадания баров в данный промежуток или отсутствие массива как такового.
Вы уводите в сторону от проблемы.
Вы уводите в сторону от проблемы.
Я излагаю суть проблемы, Вы же зациклились на своем частном случае. Судя по вашему предыдущему сообщению вы до сих пор не поняли в каких случаях происходит задержка (это помимо причины) хотя на предыдущей странице все подробно изложено.
Может этот скрипт поможет в понимании
Я излагаю суть проблемы, Вы же зациклились на своем частном случае. Судя по вашему предыдущему сообщению вы до сих пор не поняли в каких случаях происходит задержка (это помимо причины) хотя на предыдущей странице все подробно изложено.
Я уже выше сформулировал свое мнение о том, в каком случае происходит задержка.
Еще раз:
зависание Bars происходит в случае, если start_time находиться в диапазоне от времени открытия нулевого бара запрашиваемого ТФ до TimeCurrent(). (только лишь гипотеза, но проверенная практикой)
Да, ошибка происходит в частном случае. Но частных случаев не должно быть в стандартных встроенных функциях языка программирования.
А Ваша "суть" сутью таковой не является, т.к. Вы просто цитируете справку по команде Bars, с которой я отлично ознакомлен. Код ошибки в функции Bars не предусмотрен, потому как в этом нет необходимости.
Тем более в данном случае мы имеем дело с полностью сформированными массивами таймсерий.
Это хорошо видно из слегка дополненного кода моего скрипта:
Результат:
Может этот скрипт поможет в понимании
Ваш скрипт демонстрирует эту проблему - зависание.
так как временной диапазон start_time - stop_time лежит внутри недельного бара.
Если выйти за пределы недельного бара, тогда зависания не будет:
Спасибо за более наглядный пример
В МТ4 функции CopyHigh, CopyLow (другие не смотрела) вызвали критическую ошибку при отсутствии истории в тестере. Советник тестировался на Н1, а запрос был с М1
1 15:14:35.410 2017.01.04 19:54:24 Access violation read to 0x0A971FE8 in 'C:\Users\Halyna\AppData\Roaming\MetaQuotes\Terminal\287469DEA9630EA94D0715D755974F1B\MQL4\Experts\____________.ex4'
3 15:14:35.465 2017.01.04 19:54:24 Testing pass stopped due to a critical error in the EA