Ситуация: тестирование на М5 и на М1 дает разное количество входов за 1 и тот же период времени. В результате анализа входов выясняется ситуация, что некоторые минутные свечи отсутствуют в данных. Например, отсутствует свеча в 09:49. И все бы ничего, если Вам не надо было войти точно в 9:50.
TS Lab видит, что свечи в 9:49 нет, и не входит на открытии свечи в 9:50. «Не запостил — не было». Вы, задавая вход, как бы задаете свечу закрытия и входите на открытии (надеюсь, правильно объясняю) следующей свечи.
Но если заданной свечи не было, то на следующей Вы не сможете зайти. Вход пропущен. Или выход.
Как решить такую проблему? Ведь она может случиться и в реальности. Ну не будет сделок в течении минуты и что? Куда крестьянину податься?
А если надо будет использовать ещё более мелкий ТФ? что делать там?
Мне представляется, что надо бы формировать виртуальную свечу в заданный момент времени из нескольких периодов времени назад так, чтобы среди этих периодов времени гарантированно была хотя бы одна реальная свеча.
Многие, наверняка, отметили пафосные высказывания одного достойнейшего человека, который за простенького робота, условно «на стохастике», не постеснялся запросить 1,5 миллиона рублей и полгода времени… я и тогда понимал, что это даже не овер-прайс, а нечто более гнусное, а сейчас тем более.
Где же амбула? А амбула, мои уважаемые читатели заключается в том, что, я, который ни разу не программист, причем от слова «совсем», не поленился найти и купить за 300 рублей (да-да, я не шучу ни разу) «болванку» в интернетах. Почему «найти и купить»? Потому что мне нужен был хоть какой-то образец для начала работы))). В результате, за полдня, на этой болванке, простейший индикатор, который выполняет простейшие расчеты, был мной создан на Луа и помещен в Квик. Считает все корректно, хотя из-за незнания синтаксиса многое пришлось делать неэлегантно. Например, вместо того, чтобы брать 1-2 бара назад, мне пришлось сильно переписывать формулы, оперируя тем, что есть под рукой, т.е. средними и пр. Причем львиная доля времени ушла на то, чтобы понять, что «любой чих» (пропущенная запятая, случайно поставленный энтер или разрыв строки) влечет неполадку в работе и потребует ещё полдня на поиск этих «чихов». Так что о «сложности» алгоритма можно составить вполне твердое убеждение))). И что теперь? Моя убежденность в афигевшести запрашивавшего такие бабки только усилилась.
В 3-х прошлых темах были затронуты проблемы с каналами связи, оборудованием, внезапными остановками торгов и планками – приостановками торгов из-за вылета цены за границы диапазона.
Причем, как и следовало ожидать, в субботу в одну из тем набежала туча, вероятно, связанных акков и поминусовала комментарии.
Хочу снова поблагодарить всех тех, кто привнес в обсуждения полезные мысли и заставил по новому взглянуть на суть вопроса. Остальным надо выразить признательность за поднятие темы в топ )).
Если Вы здесь впервые, то не ждите здесь обсуждения точек входа, торговой системы или Грааля. Тема не о них.
Здесь предлагается обсуждать только «движок», т.е. то, что должно идеально работать с любым торговым алгоритмом, будь то стохастик, кривые средние или нейросеть на 3-х нейронах.
Хотел было предложить новую, довольно интересную тему по контролю за соблюдаемостью или трастовостью алгоритма и изложить пару методов, но решил этого не делать.
Вместо этого, предлагаю высказаться об этом окружающим.
Как Вы определяете, что «алгоритм уже умер и робота надо выключать»? Что делать в дальнейшем, — переоптимизировать и включить заново или переквалифицироваться в управдомы и пойти мести улицы – здесь не обсуждается.
Как Вы понимаете, что всё, — пора?
В прошлых 2-х темах мы затронули проблемы, связанные с нерыночными рисками… Например, — разрывы связи, вылеты сервера, перезагрузка операционки, а также внезапные остановки торгов по неизвестным причинам. Желающие могут ознакомится с выводами в соответствующих темах, которые легко найти по тэгу «торговые роботы». Причем некоторые коллеги были настолько любезны, что смогли обобщить обсуждения и сформулировать изящные резюме.
Ныне я предлагаю обсудить решение, связанное с приостановкой торгов по одному или нескольким инструментам.
Вечером 30 августа 2022 года Газпром объявил о новой рекордной выплате дивидендов. В результате, утром 31 августа, на торгах акциями Газпрома было минимум 10 приостановок торгов. Сначала был гэп на открытии, затем неоднократные приостановки торгов.
Что делать в таких случаях?
Если у нас случилась приостановка торгов на время, то как это понять на уровне алгоритма?
Вероятно, можно ввести простое условие об отсутствии тиков по каким-либо инструментам одновременно, которое будет означать приостановку торгов. И, наоборот, наличие тиков по каким-нибудь другим инструментам из этой же или из другой секции мосбиржи. Тогда, для этого, нужно задавать несколько дополнительных и несвязанных инструментов, по наличию тиков на которых мы будем делать вывод о том, что «это просто приостановка торгов по заданным инструментам». Тогда, если найдется хотя бы один такой проверочный инструмент, по которому продолжают поступать тики, то мы, таким образом, поймем, что у нас есть ситуация простой «приостановки торгов», а не чего-то худшего.
Вместо этого можно было бы сделать систему анализа сообщений, поступающих с биржи или от брокера, но это, вероятно, было бы намного сложнее в реализации.
Мнения? Критика? Предложения?
В прошлой теме о решении проблем с каналами связи, один из пользователей отлично резюмировал в нескольких строках. Вот они:
Если вкратце, то все проблемы каналов связи решаются так:
В буржуйнете довольно развита система взаимопомощи и обмена информацией о «приколах», создаваемых роботостроителям брокерами и/или биржами. Если кто-то обнаруживает новый «прикол», то почти сразу же выкладывает это в паблик, чтобы уберечь средства других людей от истощения. И лишь у нас каждый стремится спрятать под одеялом свои наработки.
Почему бы нам не создать такую тему и не обменяться мыслями/технологиями/решениями по строительству/созданию почти идеального робота? Я говорю не об алгоритмах – прячьте их сколько хотите – это индивидуальная вещь. Я говорю об общих принципах построения роботов, которые должен применять/учитывать любой роботостроитель.
Для начала предлагаю обсудить способ снижения таких неторговых рисков, как «вылетел сервер», «перезагрузилась ось», т.е. проблемы, связанные с функционированием собственного оборудования.
Разумеется, можно запретить автоматическое обновление операционной системы, но отвергать такой риск мы не можем, как не можем отвергать риск внезапной неисправности чужого или своего сервера, на котором установлен робот. Мы же, как никак, под санкциями. Можно допустить любое развитие событий.