Трейдинг: Принцип замены времени в интрадей-торговле
Проще было написать скрипт по аналогии c Period_converter и генерить нужные графики bars/tick volume (т.е. бары с одинаковым тиковым объемом). Для этого графика можно применять любые индикаторы не переписывая их.
А вообще, идея хорошая только не факт, что тиковый объем линейно связан с реальным. Эта связь может меняться во времени. Если же рассматривать его как меру волатильности, то проходя через фильры ДЦ он может значительно искажаться, а периодически может меняться и сам фильтр. Поэтому, наилучшим решением было бы не каждый раз формировать бар по реальному тиковому объему (или считать в измененных индикаторах), а делать это на основе усредненного тикового объема для каждого периода времени суток. ИМХО.
Проще было написать скрипт по аналогии c Period_converter и генерить нужные графики bars/tick volume (т.е. бары с одинаковым тиковым объемом). Для этого графика можно применять любые индикаторы не переписывая их.
А вообще, идея хорошая только не факт, что тиковый объем линейно связан с реальным. Эта связь может меняться во времени. Если же рассматривать его как меру волатильности, то проходя через фильры ДЦ он может значительно искажаться, а периодически может меняться и сам фильтр. Поэтому, наилучшим решением было бы не каждый раз формировать бар по реальному тиковому объему (или считать в измененных индикаторах), а делать это на основе усредненного тикового объема для каждого периода времени суток. ИМХО.
Действительно, генерить как period converter можно, но вот только как
это делать в режиме реального времени?
Касательно второго предложения то я с ним вцелом согласен, и индикаторы предагал переписывать именно под историческое среднее. Идея операционного таймфрейма в этом плане конечно должна трактоваться также скорее как историческое среднее, чем то как было предложено. Впрочем на практике разница будет только в случае чрезвычайно высокочастотной торговли.
Действительно, генерить как period converter можно, но вот только как это делать в режиме реального времени?
Касательно второго предложения то я с ним вцелом согласен, и индикаторы предагал переписывать именно под историческое среднее. Идея операционного таймфрейма в этом плане конечно должна трактоваться также скорее как историческое среднее, чем то как было предложено. Впрочем на практике разница будет только в случае чрезвычайно высокочастотной торговли.
Для того, чтобы обновление было real-time нужно чтобы масштаб времени был фиксированным, но возможно нестандартным. Например М47 :) Второе предложение на счет взятия темпа времени по средней, как раз это решает. Возьмем полные сутки (период цикла активности) и разобъем эти сутки на равные интервалы по средней активности с требуемой точностью (минимальный средний тиковый объем). Допустим у нас получилось 130 интервалов. Делим сутки 24*60/130=11. Т.е. можно генерить файл М11. Открывать его через "автономно", но он будет работать real-time. Время внутри дня будет условным, а без этого и не обойдешься. А затем собирать эти условные М11 как на истории, так и real-time точно так, как в скрипте Period_converter. Собирать для точности (особенно в активное время) прийдется из минуток. Получится например, что на спокойном рынке М11 будет состоять из 70-80 минут, а на быстром рынке в американскую сессию из 3-4. Остается только находить этот множитель для каждого периода и составлять новые бары. Будет правда вопрос, что например в сутки вмещается не целое кол-во 11-ти минуток, но это решается округлением, или пересчетом множителя. ИМХО.
Кроме того, что ненужно переписывать все индикаторы, преимущество в том, что можно задавать новый "операционный" тайм-фрейм (даже не тайм, а volume-frame) и наблюдать его визуально.
P.S. В плане представления цены в зависимости от активности по
времени, интересно так же представление в несколько иной плоскости
- активности по ценам. Это формализм MarketProfile и VolumeProfile. http://forex.kbpauk.ru/showflat.php/Cat/0/Number/88231/page/1/fpart/1/vc/1
Действительно, генерить как period converter можно, но вот только как это делать в режиме реального времени?
Касательно второго предложения то я с ним вцелом согласен, и индикаторы предагал переписывать именно под историческое среднее. Идея операционного таймфрейма в этом плане конечно должна трактоваться также скорее как историческое среднее, чем то как было предложено. Впрочем на практике разница будет только в случае чрезвычайно высокочастотной торговли.
Для того, чтобы обновление было real-time нужно чтобы масштаб времени был фиксированным, но возможно нестандартным. Например М47 :) Второе предложение на счет взятия темпа времени по средней, как раз это решает. Возьмем полные сутки (период цикла активности) и разобъем эти сутки на равные интервалы по средней активности с требуемой точностью (минимальный средний тиковый объем). Допустим у нас получилось 130 интервалов. Делим сутки 24*60/130=11. Т.е. можно генерить файл М11. Открывать его через "автономно", но он будет работать real-time. Время внутри дня будет условным, а без этого и не обойдешься. А затем собирать эти условные М11 как на истории, так и real-time точно так, как в скрипте Period_converter. Собирать для точности (особенно в активное время) прийдется из минуток. Получится например, что на спокойном рынке М11 будет состоять из 70-80 минут, а на быстром рынке в американскую сессию из 3-4. Остается только находить этот множитель для каждого периода и составлять новые бары. Будет правда вопрос, что например в сутки вмещается не целое кол-во 11-ти минуток, но это решается округлением, или пересчетом множителя. ИМХО.
Кроме того, что ненужно переписывать все индикаторы, преимущество в том, что можно задавать новый "операционный" тайм-фрейм (даже не тайм, а volume-frame) и наблюдать его визуально.
P.S. В плане представления цены в зависимости от активности по
времени, интересно так же представление в несколько иной плоскости
- активности по ценам. Это формализм MarketProfile и VolumeProfile. http://forex.kbpauk.ru/showflat.php/Cat/0/Number/88231/page/1/fpart/1/vc/1
О, вот это действительно интересно, но только я к сожалению не понял почему M11 не будет просто одинацатиминутками? Ну то есть кокретно вот это непонятно "Получится например, что на спокойном рынке М11 будет состоять из 70-80 минут, а на быстром рынке в американскую сессию из 3-4. " А так это конечно искомое поведение. На пишите, пожалуйста, подробнее, что предлагается делать, думаю это будет всем полезно.
О, вот это действительно интересно, но только я к сожалению не понял почему M11 не будет просто одинацатиминутками? Ну то есть кокретно вот это непонятно "Получится например, что на спокойном рынке М11 будет состоять из 70-80 минут, а на быстром рынке в американскую сессию из 3-4. " А так это конечно искомое поведение. На пишите, пожалуйста, подробнее, что предлагается делать, думаю это будет всем полезно.
Подсчитываем средний объем, например для каждой минуты дня. Получится распределение которое вы представили в своей статье. Подсчитываем суммарное кол-во тиков (фактически средний дневной объем). Далее пользователь ввел кол-во разбиений (параметр скрипта). Это и будет новый операционный фрейм. Например, ввели 100. Среднее-дневное кол-во тиков, например 1956. Получается, что в одном новом баре будет 19,56 тиков. Далее для каждого из этих 100 баров находим сколько минуток ему соответствует (по среднему объему для минуток, чтобы сумма тиков была 19). Например, 1-ому 2 минуты, 2-ому 3 минуты, ..., 45-ому 7 минут, .... Теперь мы можем собирать новые быры. Например, 1-ый бар дня будет: Open=Open(1-ой минуты), Close(закрытие 2-ой), High(максимальное значение от 1-ой до 2-ой минуты); 2-ой бар дня будет: Open=Open(3 минуты), Close=Close(5 минуты), ... и т.д. и т.п.
Но нам нужно выводить эти бары в какой-то фиксированный TF (чтобы MT с ним мог работать). Для этого мы вычисляем скольки минутам должен соответствовать один новый бар: 24*60/100=14. Т.е. у нас искусственно вводится TF - М14 только для того, чтобы в сутки влезло 100 новых баров. А дальше все как в Period_converter: сначало генерирум историю, затем зацикливаемся на обновление real-time. Генерация происходит по выше указанному алгоритму.
Простите, если еще следите за темой, загляните по - http://onix-trade.net/forum/index.php?showtopic=47239 - не совсем то же самое, но...
Может еще какие мысли возникнут :).
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
New article Принцип замены времени в интрадей-торговле has been published:
В статье изложена концепция операционного времени, позволяющая получать более однородный поток цен. Представлен код измененного скользящего среднего, учитывающий это преобразование времени.
В вопросах анализа предыдущего движения цен важную роль всегда играет статистическая однородность наблюдений. В условиях, когда эта однородность имеет место, возможно глубокое изучение свойств процесса с целью выявления закономерностей, способствующих построению торговой системы. Однако общеизвестно и будет показано далее, что даже в первом приближении процесс валютного курса не является однородным, а именно имеется существенная неоднородность, связанная с активностью разных сессий: Американской, Европейской, Азиатской и переходами между ними.
Возьму на себя смелость заявить, что мало кто из разработчиков систем – новичков, а также некоторых «опытных», задумывается о том, что даже самые простые индикаторы типа скользящего среднего, будучи связанными со временем, представляют из себя фактически разный агрегат в разное время суток. Безусловно, есть и системы, формулирующиеся в терминах цены, но не времени. Типичный пример – системы по renko и kagi методикам, но таких меньшинство. Большинство же, повторюсь, «завязаны» на время чаще всего опосредованно через индикаторы.
Все вышесказанное относится очевидно только к интрадей-системам. Для более крупных таймфреймов сезонность, если и присутствует, то не так явно выражена. В торговле же интрадей это чрезвычайно существенно и, зачастую, ведет к тому, что система показывает разную прибыльность в разное время. Обсудим подробнее, с чем связаны такие эффекты и как с ними бороться.
Author: kamal