Сервисдеск: лень, аутизм или нежелание признать ошибки? Дополнение графиков не родными свечами.
Это тот вопрос, который Вы поднимали месяц назад? https://www.mql5.com/ru/forum/1111/page878#comment_344461
FiftyStars:
...История же такая, какая есть. Мы не обладаем глубокой минутной историей. Для вашего же удобства более глубокая история представлена дневными барами.
Если вам это не удобно - ограничивайте использование этой истории вручную.
Суть ответа была известна уже тогда (https://www.mql5.com/ru/forum/1111/page878#comment_344518):
Но боюсь, что он (ответ) будет примерно такой: "программист сам в состоянии вычислить граничную дату и ограничить глубину запрашиваемой истории"..
Обратился в сервисдеск с проблемой присоединения к графикам низких ТФ свечей высших ТФ при отсутствии истории на низших ТФ. То есть на графике М1, перейдя в начало истории мы видим свечи совсем не с М1, а D1, а то и W1. Из за такого присоединения функция SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) возвращает не дату, на которой кончается история М1, а самую дату самого первого бара вне таймфрейма, то есть указанный таймфрейм вобще не влияет на результат.
...
SERIES_BARS_COUNT возвращает количество свечей(баров) принадлежащих именно конкретному символу и периоду(таймфрейму)
SERIES_FIRSTDATE возвращает дату открытия самой первой свечи(бара) принадлежащей конкретному символу и периоду(таймфрейму).
Дополнительные сведения
...
Функции отрабатывают корректно.
То что вы видите - следствие вашей предыдущей заявки по качеству истории.
История же такая, какая есть. Мы не обладаем глубокой минутной историей. Для вашего же удобства более глубокая история представлена дневными барами.
Если вам это не удобно - ограничивайте использование этой истории вручную.
Отмазка откровенная, программист не может предусмотреть все варианты бития истории чтоб прописать функцию поиска первой даты ТФ. Сегодня они такие завтра появятся новые выкрутасы, причём без ведома MQ, диллинг например накуролесит чего то.
Да и зачем это нужно если есть стандартная функция, а вот то что она выдаёт погоду на позавчера это уже откровенный баг.
В чём суть проблемы для программиста:
нужно перебрать варианты критериев по которым именно вот этот бар может считаться первым баром выбранного ТФ, а все предыдущие допиской со старшего ТФ, при чём при таком поиске перебор придётся делать для каждого бара пока не найдёшь, те много раз. В барах могут быть разрывы типа пропущенный бар (это прямое следствие выбраного MQ формата записи баров), в барах могут быть разрывы типа выходной/праздничный день. И как в такой какофонии признаков определить что вот этот бар нужный, непонятно.
В чём суть проблемы для MQ: (если мы подразумеваем что они собираются её решать)
при сшивании истории шифронуть в файл данные о точках сшива (их не много, максимум 21 по количеству ТФ, на практике их 2-3), ВСЁ вопрос решён. Дальше пиши функцию для считывания этой защищённой инфы и выдачи пользователю через запрос.
спасибо, не надо за трейдеров решать.
это ж на какую свежую голову после пятницы надо было принимать такой ход - вставить старшие бары в М1 таймфрейм ???
кто вообще дал право - каверкать сформированные многолетние принципы?
Если вам это не удобно - ограничивайте использование этой истории вручную.
спасибо, не надо за трейдеров решать.
это ж на какую свежую голову после пятницы надо было принимать такой ход - вставить старшие бары в М1 таймфрейм ???
кто вообще дал право - каверкать сформированные многолетние принципы?
Алекс не утрируй, склейка ТФ была нужна для правильного расчёта всех остальных ТФ, после того как приняли решение расчитывать все ТФ из М1.
Если помнишь это позволило нафигачить аж 21 ТФ (включая нестандартные).
Об этом не раз говаривали. Возврата к старой системе хранения каждого ТФ в отдельности не будет, ты же понимаешь.
А вот то что реализация добавила геморою программистам это факт. И вопрос то плёвый в решении, ан нет, мы лучше знаем что вам нужно :(
так вот меня и интересует
Если вам это не удобно - ограничивайте использование этой истории вручную.
Алекс не утрируй, склейка ТФ была нужна для правильного расчёта всех остальных ТФ, после того как приняли решение расчитывать все ТФ из М1.
Решается установкой идентификатора в истории и при считывании если данные за бар не принадлежат М1 то не выводить в М1, не принадлежат М5 то не выводить на М5. Ну или да...в FirstDate записать дату сшива баров текущего периода с барами высшего периода и у пользователя появится реальная возможность узнать с какой даты начинать обработку чтобы не зацепить старшие бары.
Ситуация, конечно, маразматичная.
Нельзя ни рисовать такие графики, ни возвращать из функций такие значения.
Хотите строить из М1 - стройте. Не хватает М1 - придумайте, как выкрутиться, но не за наш счет.
(все обращено, естественно, к MQ)
- www.mql5.com
Поддерживаю, ерунда это.
А если стоят разделители периодов такая красота получается.
И в коде приходиться извращаться ((.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Обратился в сервисдеск с проблемой присоединения к графикам низких ТФ свечей высших ТФ при отсутствии истории на низших ТФ. То есть на графике М1, перейдя в начало истории мы видим свечи совсем не с М1, а D1, а то и W1. Из за такого присоединения функция SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) возвращает не дату, на которой кончается история М1, а самую дату самого первого бара вне таймфрейма, то есть указанный таймфрейм вобще не влияет на результат. На запрос получил отмазку что пользователям так удобно, и крайнюю дату на каждый таймфрейм каждого символа нужно выставлять вручную. Прошу прощения, но разве эту функцию не должна выполнять функция SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) и чем тогда отличается SERIES_FIRSTDATE при указанном ТФ M1 от SERIES_FIRSTDATE при указанном ТФ W1 если результат один и тот же?
Что за бред? Кому и чем это удобно? Никто не хочет видеть W1 свечи на M1 графиках. Ну кроме мазохистов...
Прихожу к выводу: либо разработчики - аутисты(живут в своем мире, где описанное выше и ниже это норма, а точнее не норма, а работа на 5+), либо им лень это исправлять, либо же принцип "Как же так, мы никогда не ошибаемся, у нас все хорошо". Ну еще есть варианты: прикалываются, не знают как исправить.
Вот скриншоты, на них четко видна линия присоединения истории разных тф:
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
запрос 1:
Версия и битность терминала
Build 712 x86
Описание проблемы
Исторические данные мелких таймфреймов продолжаются историческими данными более крупных таймфреймов. То есть, например, история EURUSD на М1 заканчивается ~04.01.1999, и к графику, рассчитанному по М1 слева прикрепляется график D1 за период до 04.01.1999.
В приложенных скриншотах это видно. Из-за этого неверно работает функция SeriesInfoInteger с параметром SERIES_FIRSTDATE. Функция возвращает не самую первую дату по символу-периоду, а первую дату всей истории(включая таймфреймы D1,W1 и MN1).
Последовательность действий
Прокрутка графика к началу истории
Полученный результат
Продолжение графика историческими данными с более крупных таймфреймов.
Ожидаемый результат
Ограничение графика при окончании исторических данных на данном таймфрейме.
Дополнительные сведения
Запрос 2:
Версия и битность терминала
build 712 x86
Описание проблемы
Описание в документации:
SERIES_BARS_COUNT
Количество баров по символу-периоду на данный момент
long
SERIES_FIRSTDATE
Самая первая дата по символу-периоду на данный момент
datetime
Из-за присоединения истории бОльших ТФ к графикам низших ТФ в случае отсутствия истории за конкретный период времени на низших ТФ и присутствия истории за этот же период на бОльших ТФ, на графике, например, М1 присутствуют свечи с графика D1.
Готовится-ли решение данной проблемы? Существуют-ли решения данной проблемы на данный момент, кроме ограничения вручную?
Последовательность действий
Использование этих функций
Полученный результат
SERIES_BARS_COUNT на низких таймфреймах(до D1) возвращает количество свечей(баров) принадлежащих символу и периоду(таймфрейму) плюс количество свечей с ближайшего бО'льшего таймфрейма, для которого есть исторические данные
SERIES_FIRSTDATE на низких таймфреймах(до D1) возвращает дату открытия самой первой свечи(бара) в истории.
Ожидаемый результат
SERIES_BARS_COUNT возвращает количество свечей(баров) принадлежащих именно конкретному символу и периоду(таймфрейму)
SERIES_FIRSTDATE возвращает дату открытия самой первой свечи(бара) принадлежащей конкретному символу и периоду(таймфрейму).
Дополнительные сведения
...
Функции отрабатывают корректно.
То что вы видите - следствие вашей предыдущей заявки по качеству истории.
История же такая, какая есть. Мы не обладаем глубокой минутной историей. Для вашего же удобства более глубокая история представлена дневными барами.
Если вам это не удобно - ограничивайте использование этой истории вручную.