Без торговой системы профитная торговля невозможна в принципе. Потому что, если у трейдера нет собственной торговой системы, его торговля напоминает хаотичное совершение сделок, основанное скорее на удаче, а не на понимании рынка и крепкой базе знаний.

Иными словами, торговая система — главный инструмент, который делает торговлю трейдера прибыльной.

Но как разработать торговую систему? С чего начать?

Для того, чтобы помочь вам в этом разобраться, Евгений Домрачев проведет открытый урок со своего курса “Профессиональный трейдинг”.

Урок будет состоять из трех важных частей:

Часть 1. Основания для сделки.
— Вход в сделку, графические точки входа
— Выход из сделки
— Управление позицией (выход, трейл-стоп) 

Часть 2. Финансовое управление капиталом
— На чем вы зарабатываете, а на чем теряете
— Соотношение риск/прибыль
— Соотношение профит/лось

Часть 3. Дисциплина и психология трейдера
— Как торговать в строгой дисциплине
— Работа с основными эмоциями — страхом и жадностью
— Контроль эмоций во время торговли

( Читать дальше )

Поскольку торговых систем у меня много, то мне нужно каким-то образом отбирать из них лучшие. Я, кстати, решил перестать использовать слово «стратегия» и заменить его словом «система». Это более точно, поскольку стратегия — это нечто неформальное, и если это формализовать в жёсткие правила, то получим уже систему. Вопросы терминологии и однозначного понимания понятий важны потому, что большинство конфликтов и искажений в коммуникации происходит из-за недопонимания или иного трактования сложных понятий.

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

Итак, на что я смотрю:

Метрики использования капитала (эффективность использования торгового времени).
Позволяют мне отбросить системы, которые постоянно сидят в рынке или наоборот, слишком редко осуществляют сделки.

• % дней, в которые совершались сделки, по отношению к общему числу торговых дней

( Читать дальше )

Ранее я писал, что моя ботоферма выглядит примерно так:

Перед своей поездкой далеко и надолго я купил к ней ИБП от автомобильных аккумуляторов на 600 Вт. Вначале припер из машины акк на 190 Ач для теста. И конструкция проработала более суток. Но с 190 Ач у меня чуть пупок не развязался. В итоге перед отъездом купил два дешевых по 75 Ач, (что вышло дешевле 190) и подключил их параллельно. Аварийные отключения бывают раза два в год, но не более чем на 4 часа. Но эти китайские машинки сами себя не включат, а тут питание на сутки, все должно работать.
Вроде все предусмотрел Штирлиц, но беда пришла, откуда не ждали.
Год назад, чтобы не передавать показания по ЭЭ мне мой друг директор местной энергетической компании «по блату» бесплатно поставил счетчик с GSM. Но эта тварь не только передает показания, но и автоматом отключает ЭЭ. Я по старой привычке платил раз в квартал, когда сумма накопится, а в этот раз не успела накопиться вырубили вчера автоматом. в период 14-17.
Узнал я об этом поздно, за ужином, когда поедал вкуснейшие грузинские хинкали. С горя закрыл все позы вручную и накатил чачи, причем лишнего. 

( Читать дальше )

Дмитрий Овчинников написал пост про системы, которые регулярно оптимизируют параметры. Такую идею ранее описывал Коля Московский лоссбой, когда предлагал оптимизировать систему на интервале год, месяц, неделя,… (перечень интервалов могу путать)
Год назад я решил протестировать похожую идею. Сделал тестер, который в начале каждого месяца оптимизировал параметры системы на пересечении двух МА, затем месяц торговал, затем опять оптимизировал и месяц торговал. И прогнал такой бэктест на истории 8 лет.
Цифр сейчас нет, но такой подход не смог обыграть портфель такой же системы с постоянным облаком параметров. По крайней мере держался на уровне средней системы из портфеля.
Причина, как мне кажется, заключается в том, что, когда рынок внезапно менялся (например на СВО), система еще месяц продолжала торговать старую формацию.Также, возможно были ошибки в моем тестере и мои выводы неверны.

Коллега @Ho_Chu при каждом удобном случае говорит мне, что необходимо пересчитывать системы на основе последних данных. Коллега @bascomo, наверное единственный известный мне алго, эксплуатирующий этот механизм в промышленном варианте, написал в последнее время пару статей, чем подогрел мое любопытство. 

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

Для лабораторной работы взял одну из рабочих систем с тремя параметрами для оптимизации, определил диапазон параметров и периоды IS и OOS 

1. Разбил  OOS на интервалы с длительностью в 1 месяц. Проводил оптимизацию IS для каждого из интервалов OOS на периоде в 6 месяцев до этого периода и использовал лучшие параметры IS, различные для каждого из соответствующих периодов OOS.

( Читать дальше )

Надоели паутины проводов на столе. Сделал серверную стойку или ферму, если положить:



Цель достигнута

В прошлой теме о решении проблем с каналами связи, один из пользователей отлично резюмировал в нескольких строках. Вот они:

Если вкратце, то все проблемы каналов связи решаются так:

1. Мало денег — домашний сервер, резервный канал. Мониторим руками, можно какую-нибудь пищалку прикрутить на обрывы. Если сломался внешний контур — значит сидим и ждём пока починят.
2. Есть чутка денег — выносим сервер наружу. Получаем алерты в телегу, реагируем руками.
3. Есть ещё чутка денег — дублирующий сервер к варианту 2, пингуем друг-друга, пингуем из третьего места, пингуем пинговалку, обрабатываем результаты.
4. Есть еще больше денег — всё тоже что и п.2. п.3, но только в биржевой стойке.
5. Проблемы связи с торговой системой к пунктам 1-3: Мониторим коннект, переподключаемся, если есть альтернативные сервера.  Если всё завалилось, то используем альтернативные терминалы, звоним брокеру.
6. Проблемы связи с торговой системой, если завалилась биржа — сидим и смотрим.

( Читать дальше )

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

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

Для начала предлагаю обсудить способ снижения таких неторговых рисков, как «вылетел сервер», «перезагрузилась ось», т.е. проблемы, связанные с функционированием собственного оборудования.

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

( Читать дальше )

1 Пользую 7 лет выделенный сервак в датацентре. Но тслаб отожрался до 20 гиг, требует 2ух моторного серебряного ксеона о 24ех ядрах и 48ми потоках. А стоит такое чудо ажно 250к в год ну и сам тслаб 40к в год. Т.е 10 за лет сервак прожирает новый авто. И сбоит этот сервак стабильно раз год.

2 На грудь прыгнула здоровенная жаба — платить такие деньжища. И решил попробовать смастерить подходящую замену серверу из говна и палок.

3 Мысль была в том, чтоб взять два компа. Поставить их в разных городах, чтоб исключить проблемы с электричеством, интернетом и техникой. Т.е оба компа сразу не сдохнут, электричество одновременно не отключится и интернет одновременно не пропадет. На обоих компах поставить тслаб, соеденить их через облако, и как только один компов дает сбой — отключать его, включать второй комп и поднимать резервную копию с облаков.

( Читать дальше )