<HELP> for explanation

Блог им. AlexGru

Алготрейдинг, скорость тестирования на истории

День добрый.
Это некое «продолжение» моего первого поста про МТС http://smart-lab.ru/blog/153067.php.

Знаю, что многие тестируют МТС на Wealth-Lab,TSLab,Quik и т.д. Интересно, какая у вас скорость тетсирования? Бар в секунду, при интервале к примеру в год.

У меня на связке Oracle  + MT4, cейчас получаются следующие значения.
MIN_DATE             MAX_DATE         CNT            DUR_SEC     SPEED
03.01.2010            31.12.2010        74174        262,918        282
Получается 4-5 минут на год (282 бара в секунду). 

При этом ещё не было оптимизировано железо, Oracle на уровне DBA, простой ПК. А вот алгоритм на котором проводился тест в двух словах следующий:
Для каждого вновь пришедшего бара M5, при наличии в БД 700 баров, анализируеются последние 700 быров, цены которых ранжируются по убыванию, тем самым мы получаем для каждого бара все наиболоее значимые горизональные уровни, от которых был отскок. Минимальное количество данной цены в срезе. Затем все эти ранги сохраянются и мы анализируем ситуацию на предмет пробития такого уровня сверху, если пробили и опустились на фиксированный процент, то входим в шорт.

Трейлинг совсем отключен, как и управление объёмом. Так же для каждого среза но длинной 25 баров считаем коэффициент наклона прямой. И небольшая математикая для определения потенциала. Моё опыт работы с этим добром подсказывает, что включение трейлинга и прочего, уровнит скорость примерно процентов на 20%. Полностью же законченный алгоритм в некоторой версии и с логированием будет работать на скорости 50 баров в секунду. Как я и писал ранее, это не HFT, и скорость 50 баров в сукунду на реальной торговле будет не просто с мегазапасом. 
Какая у вас скорость, я слыхал, что по несколько дней тестируют, т.к. нельзя залезть внутрь и оптимизировать алгоритмы. При этом. Мне вот интересно, разного рода программы типа Wealth-Lab,TSLab,Quik.
При тетсировании хранят ли всю историю пришедшую? в памяти? 
 Кстати тестировал свою наработку сразу на 10-ти инструментах, на всех одинаковая скорость, процессор не перегружается, оперативка в пределах нормы. Потенциал для роста очень большой. А если ещё учесть, что сейчас ssd на каждом углу и многоядерные процессоры. + Для БД можно рядом поставить отдельный сервак, где будет Linux и всё будет предельно заточено на скорость, от параметров ядра, и сетевых настроек, до тонкого тюнинга Oracle. Железо сейчас дешевое относительно, софт весь «бесплатный» для личного использования. Выходит и тут простор для работы. 

 Вернусь к вопросу, какова скорость тестов ваших идей на истории в ваших средах?
Спасибо. 
 

Часто распространенная ошибка новичков. Скорость тестирования по барам выдает не скорость тестирования алгоритма, а скорость выставления и исполнения сделок на истории.

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

Поэтому большинство тестеров в погоне за скоростью выдает подчас абсолютно нереальные результаты, которые не подтверждаются на практике. Вам советую, раз вы идете своим и нерациональным путем, сразу закладываться на это. Как только вы начнете вычислять все необходимые вещи, то увидите, что скорость тестирования упадет в разы. И тут на помощь могут прийти только генетические алгоритмы. Которые есть в WLD (нет в TS Lab и конечно же в терминале для ручной торговле Quik).

Мне кажется, вы только начинаете свой путь алготрейдера. Тогда я вам дам совет. Не гонитесь за скоростью. Гонитесь за точностью. Она вам сбережет не один депозит.
Евгений, Скорость исполнения в данном случае не причем т.к.
она примерно постоянная 0.2 — 1 сек. — а медленно, но в масштабе, один ордер пусть даже в 5 минут погоды не меняет.
Комиссии помимо спрэда нету, спрэд на популярных парах мал и лежит в малом диапазоне. В реально торговле это конечно будет учитываться (аномалии спреда), но это так же не сделает погоду. Проскальзывание наблюдается крайне редко, поэтому тоже не в счет.
AlexGru, тогда вы везунчик. Так как о таком алгоритме мечтают многие алготрейдеры. Или, что более вероятно, просто еще не до конца оценили все риски и факторы.

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

Mr. Bean

Stas Ivanov, Почитайте сколько сил и главное миллионов или миллиардов корпорация Oracle тратит на CBO, и внутренюю архитектуру БД, многие супер профессионалы от программирования и математики работают там, а ядро и низкий уровень там конечно на C/C++. Т.е. уже человеческие ресурсы и силы вложены, зачем мне писать, то что уже написано и написано хорошо на том же Java. Java в данном случае ограничен, если сравнить с Oracle в скорости обработки больших объемов., что в алготрейдинге бывает полезно. К примеру. Нахождение паттернов на всей истории размером несколько Гб, (размер вашей RMA к примеру меньше). Как вы напишете такое на Java, вам придется где-то в файлах хранить котировки и кусками подкачивать в память, делать сравнения и т.д. В Oracle это уже все правильно и максимально оптимально реализовано в виде SGA/PGS кэшей. + Надо ещё это написать и чтобы правильно работало, в SQL думаю нет сомнений. Тем более все таки не все на SQL, а так же и на PL/SQL, а у него есть уровень компиляции в машинный код. + В самом оракле есть поддержка написания хранимых процедур хоть на Java, хоть на C, причем эти хранимки конечно могут быть на отдельной машине, и использовать ресурсы этой машины.
Stas Ivanov,
Java\C — почему они рядом? Конечно максимальная скорость будет на C, да ещё на C заточенном под платформу, да ещё с ассемблерными вставками. Но это нужно глубочайший опыт работы с языком и знание его. Java и PL/SQL примерно думаю сравнимы,
по скорости в ряде задач. К примеру есть вектор и надо найти экстремумы, на Java полагаю надо писать сортировку (хотя наверное есть уже написанные пакеты). в Oracle, это решается с помощью SQL, в том числе с использованием аналитических и/или оконных функций. Можем провести эксперимент какой-нибудь если есть желание и сравним скорость реализации на Oracle и Java и скорость работы алгоритмов.?
Вчера мерял — 265 тыс тиков в сек, то есть 1 год за 40 сек
avatar

Bocman


Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Залогиниться

Зарегистрироваться
....все тэги
Регистрация
UP