Ошибки, баги, вопросы - страница 2179
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, конечно, юзание аналога iBarShift выявило эту проблему.
Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,
А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.
Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем.
Скорее всего это и связано с подгрузкой истории
Да, конечно, юзание аналога iBarShift выявило эту проблему.
Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,
А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.
Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем.
Думаю, что идет попытка цикличной синхронизации в ситуации отсутствия баров в запрошенном диапазоне - Bars во всю старается "нормально отрабатывать" и потом сдается по таймауту или кол-ву попыток синхронизации
Надо самому делать проверки значений , чтобы не вызывать Bars для такого случая.
Скорее всего это и связано с подгрузкой истории
Не согласен. Она бы повторно бы тогда не закачивалась снова 22 секунды. Тем более у меня вся история по всем TФ загружена специальным индикатором.
Если бы это была подгрузка, тогда как объяснить, что первым 31 барам нужна подгрузка, а последующим не нужна.
Если бы это была подгрузка, тогда как объяснить, что первым 31 барам нужна подгрузка, а последующим не нужна.
Из документации: При запросе количества баров в заданном диапазоне дат учитываются только те бары, чье время открытия попадает в этот диапазон.
Соответственно прообраз Bars() возвращает ноль, который интерпретируется как отсутствие истории и ::Bars() в случае скрипта как было верно замечено в предыдущем сообщении завершается по таймауту или числу неудачных попыток.
Думаю, что идет попытка цикличной синхронизации в ситуации отсутствия баров в запрошенном диапазоне - Bars во всю старается "нормально отрабатывать" и потом сдается по таймауту или кол-ву попыток синхронизации
Надо самому делать проверки значений , чтобы не вызывать Bars для такого случая.
Вполне возможно.
Но вариантов масса.
Bars очень важная функция, без нее сложно обойтись. Точнее можно обойтись, но ценой повышенной траты ресурсов.
Необходимо безупречное ее функционирование.
Из документации: При запросе количества баров в заданном диапазоне дат учитываются только те бары, чье время открытия попадает в этот диапазон .
Соответственно прообраз Bars() возвращает ноль, который интерпретируется как отсутствие истории и скрипт как было верно замечено в предыдущем сообщении завершается по таймауту или числу неудачных попыток.
Понятно, что ноль.
И что - это нормально 22 секунды на решение что ноль баров в заданном временном промежутке?
Явный же алгоритмический баг внутренней реализации Bars.
Пожалуй надо оформить заявку в сервисдеск по этому вопросу, а то впереди выходные и эта тема может просто затеряться до понедельника.
Понятно, что ноль.
И что - это нормально 22 секунды на решение что ноль баров в заданном временном промежутке?
Явный же алгоритмический баг внутренней реализации Bars.
А мне не понятно как вы отличаете ноль баров в заданном временном промежутке от этого ноля:
Из документации: Если данные для таймсерии с указанными параметрами при вызове функции Bars() еще не сформированы в терминале, или данные таймсерии в момент вызова функции не синхронизированы с торговым сервером, то функция вернет нулевое значение.
Другими словами как отличить результат ноль от ошибки ноль?А мне не понятно как вы отличаете ноль баров в заданном временном промежутке от этого ноля:
Из документации: Если данные для таймсерии с указанными параметрами при вызове функции Bars() еще не сформированы в терминале, или данные таймсерии в момент вызова функции не синхронизированы с торговым сервером, то функция вернет нулевое значение.
В данном вопросе не важно происхождение нуля, а важно то, что этот ноль рожается функцией Bars целую вечность в виде пару десятков секунд.
А мне не понятно как вы отличаете ноль баров в заданном временном промежутке от этого ноля:
Из документации: Если данные для таймсерии с указанными параметрами при вызове функции Bars() еще не сформированы в терминале, или данные таймсерии в момент вызова функции не синхронизированы с торговым сервером, то функция вернет нулевое значение.
Другими словами как отличить результат ноль от ошибки ноль?Ну сами посудите. Если бы перед Вами стояла задача создать аналог функции Bars и был бы дан массив datetime, значения элементов которого убывают с возрастанием номера, другими словами массив отсортированный.
Как Вы думаете - сложно реализовать алгоритм поиска количества элементов этого отсортированного массива в заданном временном промежутке? И если бы в заданном промежутке нет ни одного бара или массив еще не проинициализирован, то нужно возвращать ноль.
Да нет же - алгоритм достаточно простой. Что там может выполняться 22 секунды?
В данном вопросе не важно происхождение нуля, а важно то, что этот ноль рожается функцией Bars целую вечность в виде пару десятков секунд.
Важно именно происхождение, потому что если бы ::Bars() в случае ошибки истории возвращала бы -1, а не 0 (как сейчас) - то и задержки никакой не возникало бы. А сейчас 0 интерпретируется как ошибка и задержка возникает из-за внутренних повторов https://www.mql5.com/ru/forum/1111/page2200#comment_6955559
Более того: допустим ввели дополнительную проверку - задержка пропала. А дальше то что? Получили вы ноль. Это результат или ошибка?