Библиотеки: Calendar - страница 2

[Stanislav Korotky]

fxsaber:

Во всех HTML-календарях (включая штатный и в Терминале) тройка (Actual, Forecast, Previous) = (Actual, Forecast, Revised). Поэтому на истории нельзя использовать Revised-поле до наступления следующего соответствующего события. Остальные - можно.

Я не работал со здешним календарным API - его документация оставляет желать лучшего (потому была бы востребована более логичная библиотека). Разве нельзя запрашивать массив изменений события, начиная с указанного change_id? Оно почему-то не привязано ко времени. К сожалению, это все вопросы больше по самому календарю, а не библиотеке, но поскольку библиотека поверх календаря, для неё они тоже остаются открытыми. Проблема с изменениями в том, что по прошлой практике использования внешних календарей я замечал, что некоторые поля могут корректироваться, так сказать, задним числом и потому тестировать нужно с учетом хронологии изменений.

Не понял каким образом previous=revised (в структуре MqlCalendarValue есть все 4 поля: actual, prev, revised, forecast) и почему нельзя на истории использовать revised - имхо, revised может появиться (если пересмотрели previous) в любой момент между прошлым выпуском события и следующим, то есть как раз на истории.

[fxsaber]

Stanislav Korotky:

Я не работал со здешним календарным API - его документация оставляет желать лучшего (потому была бы востребована более логичная библиотека). Разве нельзя запрашивать массив изменений события, начиная с указанного change_id? Оно почему-то не привязано ко времени.

Каждое изменение в календаре имеет свой change_id. Поэтому можно запросить все изменения с определенного change_id до текущего.

Не понял каким образом previous=revised (в структуре MqlCalendarValue есть все 4 поля: actual, prev, revised, forecast) и почему нельзя на истории использовать revised - имхо, revised может появиться (если пересмотрели previous) в любой момент между прошлым выпуском события и следующим, то есть как раз на истории.

В календарях Вы можете наблюдать только три поля для события. В API - четыре. Revised - самое последнее уточняющее значение, которое может прийти хоть через неделю после получения Actual. В этом причина некоторого логического запрета использования Revised в бэктестах.

Вижу довольно узко сценарии удобного использования календаря. Если у Вас есть свои варианты - озвучивайте. Возможно, библиотека имеет не оптимальный для Ваших сценариев API. Тогда будем думать.

Тема, похоже, совсем новая.

[traveller00]

Функции работы с GMT есть, но похоже не используются. Не знаю, нужны ли они там.

[fxsaber]

traveller00:
Функции работы с GMT есть, но похоже не используются. Не знаю, нужны ли они там.

На будущее оставлены. Т.к. календарь привязан ко времени сервера, а взят может быть со стороны.

[Aleksey Mavrin]

fxsaber:

Вижу довольно узко сценарии удобного использования календаря. Если у Вас есть свои варианты - озвучивайте. Возможно, библиотека имеет не оптимальный для Ваших сценариев API. Тогда будем думать.

Тема, похоже, совсем новая.

Судя по описанию возможностей календаря МТ, напрашивается запилить что-то типа Observer-а с мониторингом всех изменений, и прихода новых событий по подписке, и изменения значений Actual, Revised .

Тогда думаю может быть удобно.

[fxsaber]

Aleksey Mavrin:

Судя по описанию возможностей календаря МТ, напрашивается запилить что-то типа Observer-а с мониторингом всех изменений, и прихода новых событий по подписке, и изменения значений Actual, Revised .

Терминологически не понял.

[Andrey Khatimlianskii]

fxsaber:

Терминологически не понял.

https://refactoring.guru/ru/design-patterns/observer

[fxsaber]

Andrey Khatimlianskii:

https://refactoring.guru/ru/design-patterns/observer

Спасибо. Если речь идет про OnCalendar, то некая симуляция через change_id-механизм будет.

Сценарии применения лучше, конечно, схематичным кодом продемонстрировать.

[Aleksey Mavrin]

fxsaber:

Спасибо. Если речь идет про OnCalendar, то некая симуляция через change_id-механизм будет.

Вы говорите о симуляции событий календаря, которые в дальнейшем возможно введут штатно в МТ5.

Я же имел ввиду механизм подписки на интересуемые события, в т.ч. изменение Revised, раз он может в любой момент меняться.

Если не знакомы с паттерном Наблюдатель, рекомендую к изучению ссылку Андрея.

Суть идеи кратко в том что например:

мне для торговли надо знать все события по EUR важностью выше 3. Я обращаюсь провайдеру (объект класса,  который управляет подписками и оповещениями, ещё называется издатель, может быть одиночкой), оформляю подписку.

И в дальнейшем провайдер сам мониторит все изменения в интересуемых меня событиях и оповещает меня (вызывая метод обработки событий с соответствующей информацией).

[fxsaber]

Aleksey Mavrin:

Суть идеи кратко в том что например:

мне для торговли надо знать все события по EUR важностью выше 3. Я обращаюсь провайдеру (объект класса,  который управляет подписками и оповещениями, ещё называется издатель, может быть одиночкой), оформляю подписку.

И в дальнейшем провайдер сам мониторит все изменения в интересуемых меня событиях и оповещает меня (вызывая метод обработки событий с соответствующей информацией).

Никакой кастомный объект не может проверять себя без соответствующего вызова. Т.е. это обязан прописать пользователь у себя в коде. Раз прописал - значит и обработку делает сам.

change_id-механизм очень прост: запускаете метод Refresh. После чего получаете данные, что и где обновилось в составленном вами списке событий.

CALENDAR Calendar;

Calendar.Set(...); // Задали список событий, что хотите отслеживать.

if (Calendar.Refresh(...)) // Если из списка что-то обновилось - обрабатываем, как вздумается.