будет отрабатываться некорректно при PERIOD_W1 и PERIOD_MN1, т.к. отсчет ведется с 1 января 1970 года, а это не понедельник, а четверг. И в каждом месяце разное количество секунд.
Не проверял - потому что надо знать точно, будет работать код или нет под конкретную ситуацию, а то пенять на другого не корректно, если сам ошибся.
Я говорю о таких вот ситуациях, допустим у нас в сутках 14 часов(или меньше, если не было котировок каждый час), у меня чарт M1 и мне надо узнать сдвиг бара по M15 в прошлом дне. Т.е. будет ли корректно все работать, если в часе получилось 45 минут или в сутках 14 часов или ещё какие выпады временные/свечные?
Я лично считаю, что целесообразно использовать такую функцию:
Ну вот, например, у меня есть канал, одна из характеристик которого время начала (левая граница). И мне нужно этот канал строить на разных ТФ. Ну какая у меня еще альтернатива, кроме как через время найти в новом ТФ номер бара?
Да и много еще чего.
Например, когда я объединяю всеТФ в один с логарифмической шкалой. Это очень классная тема. Здесь тоже не обойтись без аналога iBarShift
Я лично считаю, что целесообразно использовать такую функцию:
Но необходимо отметить, что это не полный аналог штатной функции MQL4 iBarShift как минимум по причине, что в ней нет параметра Exact
В остальном она идентична.
Прикладываю простой скрипт на MQL4, который показывает полную идентичность штатной и данной функции.
Если значения от штатной функции iBarShift и моей функции не равны, тогда Print. У меня ничего не напечатало.
Нет, не печатало из-за Comment()
Если его убрать, то идет рассогласование на 1, но я не считаю это ошибкой, т.к. по сути определение нового бара происходит в двух алгоритмах со сдвигом на полбара. Мой вариант определения нового бара кажется мне более логичным, чем штатный.
На мой взгляд использование функции SeriesInfoInteger является излишнем, ведь она весьма не бесплатная.
Было:
Стало:
Выигрыш в скорости где-то в полтора раза.
2% выигрыш. Замечание.
будет отрабатываться некорректно при PERIOD_W1 и PERIOD_MN1, т.к. отсчет ведется с 1 января 1970 года, а это не понедельник, а четверг. И в каждом месяце разное количество секунд.
Это нужно добавить в Документацию PeriodSeconds.
Не проверял - потому что надо знать точно, будет работать код или нет под конкретную ситуацию, а то пенять на другого не корректно, если сам ошибся.
Я говорю о таких вот ситуациях, допустим у нас в сутках 14 часов(или меньше, если не было котировок каждый час), у меня чарт M1 и мне надо узнать сдвиг бара по M15 в прошлом дне. Т.е. будет ли корректно все работать, если в часе получилось 45 минут или в сутках 14 часов или ещё какие выпады временные/свечные?
Я лично считаю, что целесообразно использовать такую функцию:
Но необходимо отметить, что это не полный аналог штатной функции MQL4 iBarShift как минимум по причине, что в ней нет параметра Exact
В остальном она идентична.
Прикладываю простой скрипт на MQL4, который показывает полную идентичность штатной и данной функции.
Если значения от штатной функции iBarShift и моей функции не равны, тогда Print. У меня ничего не напечатало.
2% выигрыш. Замечание.
Что, правда что-ли?
Мне лениво было ставить GetMicrosecondCount(), и я доверился профилированию.
Что, правда что-ли?
Мне лениво было ставить GetMicrosecondCount(), и я доверился профилированию.
Профилирование - это о другом. 2% - максимальный выигрышь, который можно получить.
250 миллионов вызовов в Тестере на моей машине дает экономию в 1 секунду.
Однозначно, Ваш вариант лучший! Но я даже не представляю, зачем в MT5 работать с барами.
Но я даже не представляю, зачем в MT5 работать с барами.
Я это использую когда управляю мышкой. Например здесь.
Я это использую когда управляю мышкой. Например здесь.
Да, вот этого и не понимаю.
Да, вот этого и не понимаю.
А я не понимаю непонимания ))
Ну вот, например, у меня есть канал, одна из характеристик которого время начала (левая граница). И мне нужно этот канал строить на разных ТФ. Ну какая у меня еще альтернатива, кроме как через время найти в новом ТФ номер бара?
Да и много еще чего.
Например, когда я объединяю всеТФ в один с логарифмической шкалой. Это очень классная тема. Здесь тоже не обойтись без аналога iBarShift
Я лично считаю, что целесообразно использовать такую функцию:
Но необходимо отметить, что это не полный аналог штатной функции MQL4 iBarShift как минимум по причине, что в ней нет параметра Exact
В остальном она идентична.
Прикладываю простой скрипт на MQL4, который показывает полную идентичность штатной и данной функции.
Если значения от штатной функции iBarShift и моей функции не равны, тогда Print. У меня ничего не напечатало.
Нет, не печатало из-за Comment()
Если его убрать, то идет рассогласование на 1, но я не считаю это ошибкой, т.к. по сути определение нового бара происходит в двух алгоритмах со сдвигом на полбара. Мой вариант определения нового бара кажется мне более логичным, чем штатный.
А я не понимаю непонимания ))
Я не понимаю смысл использования баров. CopyRates и т.д.
Почему так медленно работает скрипт?
2018.03.30 09:21:05.208 BS (Si Splice,H4) 1 Start=15 Stop=3 Day_Shift=0 index=0
2018.03.30 09:21:05.208 BS (Si Splice,H4) 1 Start=2018.03.26 00:00 Stop=2018.03.29 00:00 Day_Shift=2018.03.29 20:00 index=0
2018.03.30 09:21:20.209 BS (Si Splice,H4) 2 Start=15 Stop=3 Day_Shift=0 index=0
2018.03.30 09:21:20.209 BS (Si Splice,H4) 2 Start=2018.03.26 00:00 Stop=2018.03.29 00:00 Day_Shift=2018.03.29 20:00 index=0
2018.03.30 09:20:49.300 Scripts script BS (Si Splice,H4) loaded successfully
2018.03.30 09:21:20.209 Scripts script BS (Si Splice,H4) removed