22 января 2014, 20:52

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

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

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

алгоритмический трейдинг роботы

Константин Б

Новосибирск

614

с 15 июля 2011

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

skatino
22 января 2014, 21:08
для начала расскажи что ты имеешь ввиду когда говоришь «горизонтальный уровень»?
+1
Alex
22 января 2014, 21:19
перпендикуляр к вертикальному уровню?
0
- Константин Б
  23 января 2014, 05:02
  Alex, уровень определенной по шкале цены — горизонтальный уровень
  0
Bock
22 января 2014, 21:22
«Агоритмический трейдинг» — поправьте)
0
- Константин Б
  23 января 2014, 10:18
  Bock, Спасибо исправил)
  0
Тимофей Мартынов
22 января 2014, 21:28
Вариант уровня поддержки

если
low[5 бара] < low[от 10 до 6 бара]
low[5 бара] < low[от 4 до 0 бара]
то через low[5] рисуем горизонтальную линию
0
- Дмитрий Столетов
  22 января 2014, 21:58
  JC, это скорее нечто похожее на фрактал.
  Автор же, как я понял, имеет в виду зону некоторой консолидации.
  0
  - Тимофей Мартынов
    22 января 2014, 22:11
    Иван Правдин, про зону консолидации ничего не сказано. Спрашивается:
    
    «Как определить горизонтальный уровень в алгоритмической системе?»
    0
Андрей Егоров
22 января 2014, 21:29
чтобы формализовать надо описать, что это горизонтальный уровень и почему он должен быть именно здесь, а потом уже по этому «ТЗ» составлять программный код. Но вот описание кроме Вас никто не сделает, по тому что никто не знает Вашего представления о горизонтальных уровнях
0
Seroja
22 января 2014, 21:42
Перемещать уровень в зависимости от ситуации? Или он должен сам автоматически перемещаться в зависимости от ситуации? Я правильно понимаю, что программа сама должна находить уровни? Можно через процедуру расчёта кластеров по точкам закрытия (открытия/макс/мин) на заданном отрезке графика.
0
Дмитрий Столетов
22 января 2014, 22:07
Во-первых нужно решить на каком количестве баров ищём консолидацию.
В принципе можно задать и диапазон баров, но это уже чуть сложнее.
1. Считаем среднюю цену каждого бара (open+close)/2.
2. Вычисляем среднюю для всех средних баров из п.1.
Таким образом мы получаем ориентир.
3. Идём по барам и смотрим на сколько отклонились их цены открытия и закрытия от средней из п.2.
4. Если все отклонения не выходят за заданный нами диапазон, то мы обнаружили зону консолидации.

Для начала пойдёт.
То же самое можно сделать и просто для цен закрытия и открытия, чтобы не попадать на формации типа ромба.
0
AlexeyTikhonov
22 января 2014, 22:23
скользящим окном длиной N, определяете ошибку равную сумме квадратов разности между текущим значением в этом окне и началом интервала. Минимум этого функционала, и есть Ваш самый горизонтальный уровень.
0
Машковский Евгений
23 января 2014, 00:34
Проблема еще в том, что его надо будет запомнить и со временем этих уровней накопится Н-ое число, а дальше как определить который из них важнее…
0
- AlexGru
  23 января 2014, 07:45
  Машковский Евгений, Для каждого вновь пришедшего бара смотрим окно назад на N баров., где в рамках окна для каждого бара считаем количество баров в разные стороны (до границ окна) для которых цена меньше текущего бара (при проходе по всем в рамках окна). Ранжираем. Далее выбираем этот максимум по рангу. Таким алгоритмом отсекаем края окна и именно ищем локальные экстремумы. Далее это значение(цена уровня) с датой последнего бара пишем в БД. Так же не сложно сюда добавляется влияние объема, не все локальные, даже ярко выраженные экстремумы важны. Так копим единую таблицу уровней, в которой с приходом каждого нового бара ранги пересчитываются. На Oracle + SQL(PL/SQL) это делается элементарно, быстро, просто и понятно., и есть возможность махом просчитывать все эти уровни для многих инструментов (только сервак пошустрее).
  +1
  - Константин Б
    23 января 2014, 10:23
    AlexGru, была мысль определять важность уровня следующим образом: храним все уровни за определенный промежуток времени например месяц, два, три и т.п. Затем смотрим сколько раз цена воспринимала этот уровень как сильный, т.е. начиналась консолидация (или сколько раз мы автоматически определяли данный уровень как уровень (плюc/минус погрешность). А дальше рейтинг 1- слабый локальный, 2-4 — средней важности уровень, 5-и т.д. очень важный уровень. (для примера: у нас за квартал система 7 раз определила уровень 140 000 следовательно уровень нифигово важный и ключевой и если перед ним есть уровень 139500 определенный 1 раз, то смотрим на 140 000 ).
    0
- Дмитрий Столетов
  23 января 2014, 09:02
  Машковский Евгений, думаю, что важность уровня можно определить по объёмам, которые прошли внутри него.
  Ну и по его длине.
  Чем длиннее консолидация, тем больше(резче) будет движение.
  0
  - Константин Б
    23 января 2014, 10:24
    Иван Правдин, Тогда скорее не внутри него а на границах уровня, например свечи которые прокалывали уровень или касались его. Какой там был объем в сравнении со средним объемом за n число баров назад
    0
    - Дмитрий Столетов
      23 января 2014, 10:38
      Константин Б, смотря что с чем сравнивать.
      Если ранжировать уровни, то одно, а если сравнивать уровень с недавней историей, то другое.
      0
SergeyJu
23 января 2014, 11:24
Интересно, что на невнятно сформулированный вопрос пытаются дать внятно сформулированные ответы. Да еще и разные…
0
- Константин Б
  23 января 2014, 14:20
  SergeyJu, почему вопрос не внятен? Как алгоритмизировать определение горизонтального уровня (по шкале цена)?
  0
SergeyJu
24 января 2014, 16:44
Что такое «по шкале цена».
Моя твоя не понимайт.
Не я один задался вопросом, что Вы имели в виду. Вы никому реально не ответили.
Возможно, проблема не в алгоритмизации понятия, а в его неопределенности для Вас. Типа, сами не знаете, что хотите.
0