Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ну так дыры в истории и есть причиной последствий бага.
код абсолютизирует допущение, что дыр нет.
что происходит в коде
1. new_shift ты задаешь равным НОМЕР_БАРА_H1 * 4 - это первое допущение, что нужный тебе М15 бар будет отстоять на ровно в 4 раза большем индексе, чем H1
2. ts[new_shift][TIME_INDEX] - тут ты это допущение используешь. берешь время М15 бара, по полученному индексу.
Но индекс у тебя изначально НЕВЕРНЫЙ. так как в истории М15 - дыра оказалась на надцатом баре.
Ты вышел из ситуации циклом подгонки и это скрыло реальные индексы дыр - for(int i=new_shift; i<new_shift+4
этот цикл спасает допущение, пытаясь найти нужное время бара среди 4 соседних.
но по логике - искать ты не должен вообще. а должен сразу брать нужный бар shift*4. Ибо допустил, что индекс М15 должен быть 100% на *4 месте от H1. зачем же его подгонять циклом i<new_shift+4 ??
в дальнейшем не учитываешь накапливающуюся ошибку для последующих правильных смещений новых shift.
в результате уже через 4 дыры на М15 начинается сплошное расхождение.
и всё. баг в коде становится очевиден.
я только что загрузил историю, создал таймфреймы - на моем тесте расхождения начинаются только на последнем баре конца истории М15,
А где твой правильный код?
Константин, это несерьезно с твоей стороны.
Кто тут из нас кодер ты или я? :)
просил найти ошибку - я нашел. даже пояснил где.
Константин, это несерьезно с твоей стороны.
Кто тут из нас кодер ты или я? :)
просил найти ошибку - я нашел. даже пояснил где.
Вот моя переделанная функция перевода из М15 в Н1 сделал так, но ошибки все равно лезут...
почему так сложно? у тебя ведь и так есть iTime на PERIOD_H1, shift. зачем вручную вычислять sec ?
и если уж начал бежать от i=0, то беги до row
и проверять не
sec == ts[i][0]
а
sec <= ts[i][0]
таким образом ты сделал свою неоптимизированную iBarShift с параметром exact=false
почему так сложно? у тебя ведь и так есть iTime на PERIOD_H1, shift. зачем вручную вычислять sec ?
и если уж начал бежать от i=0, то беги до row
и проверять не
а
таким образом ты сделал свою неоптимизированную iBarShift с параметром exact=false
т.е. рассогласования происходят из-за дыр на графике? бред какой то :(
я ведь на сравнении ищу одинаковое время открытия бара на H1 и M15
я ведь на сравнении ищу одинаковое время открытия бара на H1 и M15
sec <= ts[i][0]
потом проверь сразу на равность
sec == ts[i][0]
если равно, то ок, иначе функция выдаст ближайший по времени i.
кстати - если выполнилось условие
sec <= ts[i][0]
то тут ты сможешь проверить сразу на равность shift*4 и найденного i
по допущению они должны быть равны, иначе на чарте найдена дырка
break из функции будет по условию
потом проверь сразу на равность
если равно, то ок, иначе функция выдаст ближайший по времени i.
кстати - если выполнилось условие
то тут ты сможешь проверить сразу на равность shift*4 и найденного i
по допущению они должны быть равны, иначе на чарте найдена дырка
Судя по выводам в файл, на графике имеется отсутствие М15 начиная с 29 числа. А я вижу все бары на графике на М15 и на Н1.
Провел анализ истории на наличие дыр этим скриптом https://www.mql5.com/ru/code/7093 и другими - результат одинаковый, с 02.01.2013 года у меня дыр нет ни на Н1 ни на М15, для достоверности считал каждый отсутствующий бар дырой. А судя по выводу моей функции, дыр нет только в последних сутках, а если проанализировать вывод, то получается, что расхождения начинаются на окончании предыдущей недели. Но ведь дыр там нет если верить скрипту. В чем может быть причина уже не понимаю вообще. Подскажите куда копать.
Во вложении результат моей истории и выводы функции на схождение/расхождение.