Восстановление тикового потока из минуток.

Данную ветку создал с несколькими целями.

1. Изложить свою точку зрения на то как должен выглядеть график который мы видим на экране и подход к его анализу.

2. Получить инструмент, который можно использовать в чемпионате и реальной торговле.

Для целостности изложения буду дублировать важную с моей точки зрения информацию, выложенную тут же на форуме.

Самая важная, то с чего все начинается https://www.mql5.com/ru/forum/102066/page9#19442

Рис.1

Здесь в этом потоке заключена вся (ну или почти вся) информация для технического анализа. Это то, что на входе ДЦ. Он в свою очередь фильтруя этот поток транслирует его нам в виде тиков. Допустим некую среднюю с точностью до 4 знака после запятой, причем он точно (да и никто) не знает истинную цену, поэтому относительно этой средней выставляется спред. В терминах статистической теории - доверительный интервал оценки неизвестной величины.

Т.е. истинная цена лежит, где-то рядом с точкой (Ask-Bid)/2 + Bid. Вот именно она должна отражаться на графике и именно «поведение» этой точки мы должны прогнозировать. В дальнейшем буду называть её истинной точкой (ИТ)

Попытки прогнозировать Bid (Close) cчитаю не совсем верным т.к. это попытка прогноза границы доверительного интервала. Некоторые ДЦ используют (заявляют что используют) фиксированный спред, что с точки зрения статистики не совсем верно, если конечно это не спред +- 3 лаптя правея солнца. Величина спреда должна быть величиной переменной в зависимости оттого, что происходит там на межбанке.

Поясню это из рисунка 1. Допустим, что оба этих графика не подвергались никакой обработке. На первом рисунке поток широкий, следовательно и доверительный интервал оценки (спред) должен быть шире, по сравнению со вторым потоком, где поток узок.

Считаю одним из признаков «правильного» ДЦ – плавающий спред, т.к. там делается логичная и возможно корректная обработка входного потока.

К сожалению, представление движения интересующего нас объекта (цены) в виде свечей (которым уже более 3 веков) не совсем устраивает, т.к. не в полной мере отражает, что же происходит с ценой и приводит к неоднозначности выражающейся в том, что начинаем использовать различные комбинации OHLC, но ведь это неправильно попасть в истинную точку при этом можно только случайно.

И самое неудобное это дыры. Ведь если произвести простейший расчет (высказывание Renat от 19.12.2006 14:21 Вот отчет по тиковому потоку EURUSD (8000 тиков за 2 часа)» см. ссылку выше) получается больше 1 тик в секунду. Но нам транслируют его отфильтрованным + еще много чего накручивают и получаем вот это

Рис.2

Интервал времени с 22:25 до 22:59 т.е. 29 баров должно быть, а тут 24 - пяти баров нахватает (и с этим мы будем работать на чемпионате), что дополнительно усложняет нам обработку. А ведь цена была, она никуда не делась. Возьмем другой ДЦ ту же валюту, тот же интервал времени.

Рис.3

Все 29 баров на месте.

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

Поэтому стоит задача, имея минутную историю, максимально точно восстановить тиковую историю. К сожалению, абсолютно точно восстановить не удастся (хотя может я и ошибаюсь в этом прошу помощи), особенно за расстановку тиков по времени.

Любые индикаторы, в том или ином виде обращаться к истории, т.е. к данным, но эти данные должны быть правильными. Сохранение тиков по множеству валютных пар уже реализовано https://www.mql5.com/ru/code/7777 и можно реализовав работу с файлом (доработав сборщик) решить эту задачу. Но есть недостатки

1. Файловые операции занимают много время. Плюс по правилам чемпионата не понятно можно ли это делать (файловые операции).

2. При разрыве связи (появлении дыр) данные не заполняться из доступной истории

3. При инициализации нет тиков, советник вынужден молчать пока не наберет достаточную историю.

Поэтому необходима процедура, которая будет заполнять массив тиковыми данными + при наличии дыры заполнять её из минуток, в двух вариантах с использованием записи в файл (для реальной работы) и только массив (для чемпионата).

Процедура восстановления тиков из минуток

Если один тик – устанавливаем его на 30 сек.

Два тика – на 15 сек и на 45.

Три - Open на 15 сек Close на 45, третий на 30 сек. (Н-L)/2

Четыре и более – разбиваем минуту на интервалы соответствующие количеству тиков и расставляем их в направлении от Open к Close. (Пример 6 тиков – ставим на 5, 15, 25, 35, 45, 55 сек) каждый тик имеет приращение (Close-Open)/Volume относительно Open.

Таким образом для реала должны иметь файл без дыр следующей структуры (6 полей)

1. Дата (дд.мм.гггг)

2. Время (час:мин:сек)

3. TimeCurrent() (сек от 1970)

4. Bid или 0 (если восстанавливали)

5. Ask или 0 (если восстанавливали)

6. (Ask-Bid)/2 + Bid если данные восстанавливались иначе 0.

Для чемпионата

1. TimeCurrent() (сек от 1970)

2. (Ask-Bid)/2 + Bid

Глубина хранимой истории (массива для обработки) задается количеством дней желательно неделя.

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