Получается что? Получается все индикаторы и советники, которые тестируются (или используют данные ) на исторических тиках начиная с периода ранее 2018-го года не могут претендовать на "достоверные"!
Ну разве не так? Если даже "граальный" советник основывается на заведомо не корректных данных, то он окажется "граальным сливатором"...
Я у своих брокеров не могу получить тики ранее 2019-го. Поэтому решил (многие тут пишут, что тестируют всё чуть ли не за 20 лет) проверить свой индикатор на MQL-DEMO. И всё бы ничего... Индикатор учитывает гэпы. Но ТАКИЕ!!! Чисто случайно обратил на это внимание... Что ж - теперь никому не верить? По 100 раз перепроверять данные, которые должны быть как "аксиома"?
Вопрос то не в том, что не работает определение начала цикла, а в том, что не смотря на проверку > 0.0 цены тиков оказываются нулевыми! Я прекрасно понимаю, что если и в этом месте применить нормализацию, то, возможно, ошибок станет меньше. Тем не менее вопрос остаётся: почему в истории тиков значение может быть, например, 0.00000000001 ???
for(int i = 0; i < ticks_size; i++)
{
bid_last = NormalizeDouble(ticks[i].bid, Digits());
ask_last = NormalizeDouble(ticks[i].ask, Digits());
А если в самом начале цикла for, когда тик равен нулю, просто не брать его в расчет и через continue пропустить?
Не совсем понял...
Читаем первый тик.
Условия не срабатывают.
Если тик (бид или аск) имеют цену ( > 0 ), то присваиваем их значение "предыдущему".
начиная со второго тика уже сравниваем разницу.
Беда в том, что при всех этих манипуляциях всё-равно пишется, что последний тик == 0 !!!
И вот тут я впадаю в ступор )))) Как так? Если тик несёт 0, то присваивания не может быть по определению. Если он чутка больше, то нормализация должна этот "чуток" убрать! Далее, я сделал проверку тика на 16-и знаках после запятой. НОЛЬ! А присваивание происходит...
Если тик несёт 0, то присваивания не может быть по определению. Если он чутка больше, то нормализация должна этот "чуток" убрать! Далее, я сделал проверку тика на 16-и знаках после запятой. НОЛЬ! А присваивание происходит...
Если тик несет 0, то у вас нет присвоения переменным _prev. В распечатках и не видно, чтобы потом bid_prev, ask_prev были равны 0.
После заданных вопросов, уже сам увидел, что у меня строго прописан индекс 0. А приказ "продолжить" никак его не изменяет. Поправил. Не, конечно пересмотрю внимательно все логи, но, по предварительной оценке, глобальное непонимание исчезло!
Остался самый первый вопрос: почему контейнер с тиками содержит в себе тик из следующего контейнера???
FQ 0 14:56:01.977 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Первый тик >>> 2015.01.07 00:00
RJ 0 14:56:01.992 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Конец периода... 145 <=> 178 День недели = 3 >>> 0:0:0 >>> 2015-1-14
CJ 0 14:56:01.992 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) >>>>>>>> Размер недельных тиков = 513768
QO 0 14:56:02.084 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Конец периода... 115 <=> 60 День недели = 2 >>> 23:59:57 >>> 2015-1-20
LN 0 14:56:02.084 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) >>>>>>>> Размер недельных тиков = 459349
HP 0 14:56:02.140 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Конец периода... 66 <=> 72 День недели = 2 >>> 23:59:58 >>> 2015-1-27
2021.07.12 09:58:32.375 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Конец периода... 46 <=> 93 День недели = 5 >>> 23:54:59 >>> 2021-7-2
2021.07.12 09:58:32.478 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Конец периода... 258 <=> 4 День недели = 5 >>> 23:54:59 >>> 2021-7-9
2021.07.12 09:58:32.482 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) Конец периода... 214 <=> 72 День недели = 1 >>> 10:0:28 >>> 2021-7-12
2021.07.12 09:58:32.482 nCandles_FgAMAp_1W_1.03 (GBPUSD,H1) >>>>>>>> Размер недельных тиков = 23404
Как попадают "лишние" тики в заказанный контейнер? И как с этим бороться?
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Не должны, но не обязаны.
Получается что? Получается все индикаторы и советники, которые тестируются (или используют данные ) на исторических тиках начиная с периода ранее 2018-го года не могут претендовать на "достоверные"!
Ну разве не так? Если даже "граальный" советник основывается на заведомо не корректных данных, то он окажется "граальным сливатором"...
Я у своих брокеров не могу получить тики ранее 2019-го. Поэтому решил (многие тут пишут, что тестируют всё чуть ли не за 20 лет) проверить свой индикатор на MQL-DEMO. И всё бы ничего... Индикатор учитывает гэпы. Но ТАКИЕ!!! Чисто случайно обратил на это внимание... Что ж - теперь никому не верить? По 100 раз перепроверять данные, которые должны быть как "аксиома"?
Да и у кого их перепроверять?
.....
Этих пропусков не так уж и много, пара сотен за неделю.
Угу... Только почему то за 3,5 последних года их нет... А остальное? Что не так? И ПОЧЕМУ?
Спасибо, парни, за ответы, но!
Вопрос то не в том, что не работает определение начала цикла, а в том, что не смотря на проверку > 0.0 цены тиков оказываются нулевыми! Я прекрасно понимаю, что если и в этом месте применить нормализацию, то, возможно, ошибок станет меньше. Тем не менее вопрос остаётся: почему в истории тиков значение может быть, например, 0.00000000001 ???
Результат остался прежним.
По EURUSD 17-й тоже не катит...
Результат остался прежним.
По EURUSD 17-й тоже не катит...
А если в самом начале цикла for, когда тик равен нулю, просто не брать его в расчет и через continue пропустить?
А если в самом начале цикла for, когда тик равен нулю, просто не брать его в расчет и через continue пропустить?
Не совсем понял...
Беда в том, что при всех этих манипуляциях всё-равно пишется, что последний тик == 0 !!!
И вот тут я впадаю в ступор )))) Как так? Если тик несёт 0, то присваивания не может быть по определению. Если он чутка больше, то нормализация должна этот "чуток" убрать! Далее, я сделал проверку тика на 16-и знаках после запятой. НОЛЬ! А присваивание происходит...
Сергей Таболин:
Если тик несёт 0, то присваивания не может быть по определению. Если он чутка больше, то нормализация должна этот "чуток" убрать! Далее, я сделал проверку тика на 16-и знаках после запятой. НОЛЬ! А присваивание происходит...
Если тик несет 0, то у вас нет присвоения переменным _prev. В распечатках и не видно, чтобы потом bid_prev, ask_prev были равны 0.
Я предлагал типа такого сделать:
Здравствуйте, уважаемые.
Я уже было склонился к мысли, что это в реализации моей логики есть косяки, но некоторые моменты не позволяют это принять.
Давайте с самого начала. Логика индикатора:
Подскажите, где хромает логика?
Ну и сразу вопрос, который к логике не имеет прямого отношения.
Индикатор строит свечи на тиках за неделю.
Я запустил индикатор от даты 2015.01.07 (среда, день недели - №3)
Ожидалось, что последний тик должен быть во вторник, день недели №2.
Но распечатка показывает, что
последний тик в недельном контейнере был не 13-го, а 14-го. Почему? Хотя в дальнейшем всё как и ожидалось... Почти.
Куда пропали недельные тики между этими датами?
А тут пропали уже месяцы!
И ни одного сообщения об ошибке или отсутствии тиков!
Я совершенно не понимаю, что происходит.
Главное - СПРОСИТЬ!!! )))
После заданных вопросов, уже сам увидел, что у меня строго прописан индекс 0. А приказ "продолжить" никак его не изменяет. Поправил. Не, конечно пересмотрю внимательно все логи, но, по предварительной оценке, глобальное непонимание исчезло!
Остался самый первый вопрос: почему контейнер с тиками содержит в себе тик из следующего контейнера???
Как попадают "лишние" тики в заказанный контейнер? И как с этим бороться?