Алгоритмический трейдинг: формализаций определения горизонтальных уровней?

22 января 2014, 20:52
|
Константин Б

Добрый день коллеги.
Занимаюсь алгоритмическим трейдингом не первый день, но возникла проблема в самомо простом наверное и логичном (как многим может показаться) месте.
Как определить горизонтальный уровень в алгоритмической системе?
не задавать его вручную, а именно формализованно его определять и перемещать в зависимости от ситуации.

Хотелось бы услушать конструктивные мнения по данному поводу)

43 | ★3

21 комментарий

для начала расскажи что ты имеешь ввиду когда говоришь «горизонтальный уровень»?

skatino

22 января 2014, 21:08
Ответить

перпендикуляр к вертикальному уровню?

Alex

22 января 2014, 21:19
Ответить

Alex, уровень определенной по шкале цены — горизонтальный уровень

Константин Б

23 января 2014, 05:02
Ответить

«Агоритмический трейдинг» — поправьте)

Bock

22 января 2014, 21:22
Ответить

Bock, Спасибо исправил)

Константин Б

23 января 2014, 10:18
Ответить

Вариант уровня поддержки

если
low[5 бара] < low[от 10 до 6 бара]
low[5 бара] < low[от 4 до 0 бара]
то через low[5] рисуем горизонтальную линию

Тимофей Мартынов

22 января 2014, 21:28
Ответить

JC, это скорее нечто похожее на фрактал.
Автор же, как я понял, имеет в виду зону некоторой консолидации.

Дмитрий Столетов

22 января 2014, 21:58
Ответить

Иван Правдин, про зону консолидации ничего не сказано. Спрашивается:

«Как определить горизонтальный уровень в алгоритмической системе?»

Тимофей Мартынов

22 января 2014, 22:11
Ответить

чтобы формализовать надо описать, что это горизонтальный уровень и почему он должен быть именно здесь, а потом уже по этому «ТЗ» составлять программный код. Но вот описание кроме Вас никто не сделает, по тому что никто не знает Вашего представления о горизонтальных уровнях

Андрей Егоров

22 января 2014, 21:29
Ответить

Перемещать уровень в зависимости от ситуации? Или он должен сам автоматически перемещаться в зависимости от ситуации? Я правильно понимаю, что программа сама должна находить уровни? Можно через процедуру расчёта кластеров по точкам закрытия (открытия/макс/мин) на заданном отрезке графика.

Seroja

22 января 2014, 21:42
Ответить

Во-первых нужно решить на каком количестве баров ищём консолидацию.
В принципе можно задать и диапазон баров, но это уже чуть сложнее.
1. Считаем среднюю цену каждого бара (open+close)/2.
2. Вычисляем среднюю для всех средних баров из п.1.
Таким образом мы получаем ориентир.
3. Идём по барам и смотрим на сколько отклонились их цены открытия и закрытия от средней из п.2.
4. Если все отклонения не выходят за заданный нами диапазон, то мы обнаружили зону консолидации.

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

Дмитрий Столетов

22 января 2014, 22:07
Ответить

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

AlexeyTikhonov

22 января 2014, 22:23
Ответить

Проблема еще в том, что его надо будет запомнить и со временем этих уровней накопится Н-ое число, а дальше как определить который из них важнее…

Машковский Евгений

23 января 2014, 00:34
Ответить

Машковский Евгений, Для каждого вновь пришедшего бара смотрим окно назад на N баров., где в рамках окна для каждого бара считаем количество баров в разные стороны (до границ окна) для которых цена меньше текущего бара (при проходе по всем в рамках окна). Ранжираем. Далее выбираем этот максимум по рангу. Таким алгоритмом отсекаем края окна и именно ищем локальные экстремумы. Далее это значение(цена уровня) с датой последнего бара пишем в БД. Так же не сложно сюда добавляется влияние объема, не все локальные, даже ярко выраженные экстремумы важны. Так копим единую таблицу уровней, в которой с приходом каждого нового бара ранги пересчитываются. На Oracle + SQL(PL/SQL) это делается элементарно, быстро, просто и понятно., и есть возможность махом просчитывать все эти уровни для многих инструментов (только сервак пошустрее).

AlexGru

23 января 2014, 07:45
Ответить

AlexGru, была мысль определять важность уровня следующим образом: храним все уровни за определенный промежуток времени например месяц, два, три и т.п. Затем смотрим сколько раз цена воспринимала этот уровень как сильный, т.е. начиналась консолидация (или сколько раз мы автоматически определяли данный уровень как уровень (плюc/минус погрешность). А дальше рейтинг 1- слабый локальный, 2-4 — средней важности уровень, 5-и т.д. очень важный уровень. (для примера: у нас за квартал система 7 раз определила уровень 140 000 следовательно уровень нифигово важный и ключевой и если перед ним есть уровень 139500 определенный 1 раз, то смотрим на 140 000 ).

Константин Б

23 января 2014, 10:23
Ответить

Машковский Евгений, думаю, что важность уровня можно определить по объёмам, которые прошли внутри него.
Ну и по его длине.
Чем длиннее консолидация, тем больше(резче) будет движение.

Дмитрий Столетов

23 января 2014, 09:02
Ответить

Иван Правдин, Тогда скорее не внутри него а на границах уровня, например свечи которые прокалывали уровень или касались его. Какой там был объем в сравнении со средним объемом за n число баров назад

Константин Б

23 января 2014, 10:24
Ответить

Константин Б, смотря что с чем сравнивать.
Если ранжировать уровни, то одно, а если сравнивать уровень с недавней историей, то другое.

Дмитрий Столетов

23 января 2014, 10:38
Ответить

Интересно, что на невнятно сформулированный вопрос пытаются дать внятно сформулированные ответы. Да еще и разные…

SergeyJu

23 января 2014, 11:24
Ответить

SergeyJu, почему вопрос не внятен? Как алгоритмизировать определение горизонтального уровня (по шкале цена)?

Константин Б

23 января 2014, 14:20
Ответить

Что такое «по шкале цена».
Моя твоя не понимайт.
Не я один задался вопросом, что Вы имели в виду. Вы никому реально не ответили.
Возможно, проблема не в алгоритмизации понятия, а в его неопределенности для Вас. Типа, сами не знаете, что хотите.

SergeyJu