Скачать MetaTrader 5

Трейдинг: Принцип замены времени в интрадей-торговле

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
MetaQuotes Software Corp.
Модератор
182367
MetaQuotes Software Corp. 2007.07.05 16:05 

New article Принцип замены времени в интрадей-торговле has been published:

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

В вопросах анализа предыдущего движения цен важную роль всегда играет статистическая однородность наблюдений. В условиях, когда эта однородность имеет место, возможно глубокое изучение свойств процесса с целью выявления закономерностей, способствующих построению торговой системы. Однако общеизвестно и будет показано далее, что даже в первом приближении процесс валютного курса не является однородным, а именно имеется существенная неоднородность, связанная с активностью разных сессий: Американской, Европейской, Азиатской и переходами между ними.

Возьму на себя смелость заявить, что мало кто из разработчиков систем – новичков, а также некоторых «опытных», задумывается о том, что даже самые простые индикаторы типа скользящего среднего, будучи связанными со временем, представляют из себя фактически разный агрегат в разное время суток. Безусловно, есть и системы, формулирующиеся в терминах цены, но не времени. Типичный пример – системы по renko и kagi методикам, но таких меньшинство. Большинство же, повторюсь, «завязаны» на время чаще всего опосредованно через индикаторы.

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

Author: kamal

Avals
3183
Avals 2007.07.06 05:13  

Проще было написать скрипт по аналогии c Period_converter и генерить нужные графики bars/tick volume (т.е. бары с одинаковым тиковым объемом). Для этого графика можно применять любые индикаторы не переписывая их.

А вообще, идея хорошая только не факт, что тиковый объем линейно связан с реальным. Эта связь может меняться во времени. Если же рассматривать его как меру волатильности, то проходя через фильры ДЦ он может значительно искажаться, а периодически может меняться и сам фильтр. Поэтому, наилучшим решением было бы не каждый раз формировать бар по реальному тиковому объему (или считать в измененных индикаторах), а делать это на основе усредненного тикового объема для каждого периода времени суток. ИМХО.

kamal
46
kamal 2007.07.10 23:06  
Avals:

Проще было написать скрипт по аналогии c Period_converter и генерить нужные графики bars/tick volume (т.е. бары с одинаковым тиковым объемом). Для этого графика можно применять любые индикаторы не переписывая их.

А вообще, идея хорошая только не факт, что тиковый объем линейно связан с реальным. Эта связь может меняться во времени. Если же рассматривать его как меру волатильности, то проходя через фильры ДЦ он может значительно искажаться, а периодически может меняться и сам фильтр. Поэтому, наилучшим решением было бы не каждый раз формировать бар по реальному тиковому объему (или считать в измененных индикаторах), а делать это на основе усредненного тикового объема для каждого периода времени суток. ИМХО.


Действительно, генерить как period converter можно, но вот только как это делать в режиме реального времени?

Касательно второго предложения то я с ним вцелом согласен, и индикаторы предагал переписывать именно под историческое среднее. Идея операционного таймфрейма в этом плане конечно должна трактоваться также скорее как историческое среднее, чем то как было предложено. Впрочем на практике разница будет только в случае чрезвычайно высокочастотной торговли.

Avals
3183
Avals 2007.07.12 07:27  
kamal:
Действительно, генерить как 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

kamal
46
kamal 2007.07.12 12:37  
Avals:
kamal:
Действительно, генерить как 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. " А так это конечно искомое поведение. На пишите, пожалуйста, подробнее, что предлагается делать, думаю это будет всем полезно.

Avals
3183
Avals 2007.07.13 09:04  
kamal:

О, вот это действительно интересно, но только я к сожалению не понял почему 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. Генерация происходит по выше указанному алгоритму.

Андрей
1084
Андрей 2007.10.29 15:15  

Простите, если еще следите за темой, загляните по - http://onix-trade.net/forum/index.php?showtopic=47239 - не совсем то же самое, но...

Может еще какие мысли возникнут :).

thekoss Karakozov
39
thekoss Karakozov 2013.06.25 21:26  
При использовании  Expected Volumes .mq4 виснит терминал,что посоветуете?
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий