Glukator (Все сообщения пользователя)

Указывая объем книги пишут "Бла-бла -- 847 с.". Когда пишут "стр. 847" - значит, указывают на конкретное место. Странно не знать этого тому, кто претендует на "академичность".

А еще странно, что претендующий на "академичность" так и не научился ни понимать написанное, ни врубаться в контекст разговора. Зато советы раздает на уровне старухи Шапокляк, направо и налево.

Разговор шел о неоднородности случайного процесса, представленного биржевыми данными. VPM ответил, что есть методы _приведения_. На что я совершенно логично спросил, в какой книге по теории случайных процессов об этих методах можно почитать:
Каким надо быть оленем, чтобы не понять, что вопрос о книге, содержащей информацию на _конкретную_ тему? Короче говоря, nikolz, если есть что сказать по делу - пожалуйста, а так лучше помолчи - за умного сойдешь.

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

Возможно, дело в годе издания, но в первая книга закончилась на стр. 835, а во второй с. 540 указывает на оглавление. В любом случае ни там, ни там не нашел даже упоминания об однородности/неоднородности случайных процессов ни в оглавлении, ни в предметном указателе.
Интересный вывод, но нет :) Механика торговли - да, построена по идеям Владимира. Потому что эти идеи - о решении объемных задач малыми ресурсами с минимальными глюками. В остальном же мы, видимо, просто приходим постепенно к сходным решениям - почему бы и нет?

Эмм... немного странный вопрос. Свечи - это всего лишь форма представления. Считаю по рекуррентной формуле для среднего, запрашивая LAST раз в секунду из ТТТ. Кому надо - можно и L() и ׁׁH() и O() и ֻC() аналогично высчитать, не скипидаря мозг и не засирая память посредством CreateDataSource() и иже с ним (сейчас у меня "на выпасе" 226 тикеров, если под каждый CreateDataSource() вызывать - то легче повеситься, а первым повесится ноут, где все это вертится).Если книжку подскажете по теории случайных процессов, где описаны такие методы - вот тогда спасибо скажу, удовлетворю свой академический интерес. А индикатор - это, все-таки, реализация чего-то. Предпочитаю _понимать_ то, что делаю.Это не контр-тренд, все-таки. В зависимости от ситуации может быть и так, и иначе - не раз убеждался, контролируя сделки по графикам "пост-фактум". И наперед совершенно неизвестно, как оно будет в случае конкретной сделки.
А вот это интересно - у меня тоже была мысль ввести такую "прогрессивную" просадку, но пока наблюдаю за тем, что есть. Надо будет на истории потестить.

Ну это само собою, превышение просадкой порога - только одно из условий. Их у меня сейчас 4:
1. собственно, превышение порога просадки;
2. хотя бы один из старших таймфреймов (при движении от старшего к младшему) подтверждает снижение (если есть данные по этим таймфреймам);
3. на хотя бы одном из младших таймфреймов (кроме 10 секундного), при проверке от старшего к младшему, движение остановилось или зафиксирован рост;
4. этот рост не сожрал предыдущее падение.

Ошибся, не СКЗ конечно, а СКО.

Тренд я не определяю, поэтому не могу сказать, "контр" или нет :) Я вижу достаточно глубокую просадку - и покупаю 1 лот в расчете на отскок. Если цена не развернулась, усредняю позицию при движении вниз.
ׁH() и L() не считаю, индикаторов никаких тоже, максимальное значение отслеживаю только для закрытия по тейк-профиту. СКЗ считать имело бы смысл при однородности нашего случайного процесса, но это ведь не так. Сейчас тикер дохлый и на 0.5% не ходит, а через минуту вожжа под хвост ударит, и рванет он хрен знает куда.

Я еще в процессе осмысления/отладки, многое может и выкину за ненадобностью. Чем проще - тем лучше, сам так считаю.
Сортировка тут только для определения наибольшей просадки. Всю позицию скидываю исключительно из соображений удобства при расчете прибыли и быстрого высвобождения средств. Заявки у меня со вчерашнего дня тоже продлеваются, только вот вопрос: курс "рядом" - это где? Я пока задал "не далее, чем 5 шагов цены" при условии малой активности, но еще надо посмотреть. Стоп двигаю точно так же только вверх на уровень половины текущей прибыли. Может, я раньше неясно выразился.

Курица моя еще молодая, я ей мозги периодически подкручиваю )
У меня пока задан фиксированный порог просадки >= 2%, от которого скрипт начинает интересоваться тикерами. А 2% - это довольно много. И если на часовом таймфрейме такая просадка не обнаружена, то на двух- или трехчасовом вполне может нарисоваться. Хотя, иной раз, и на 30-секундном бывает ))

Сложно все у вас. У меня тогда точно "лопата" %))
Есть 9 таймфреймов, по ним считаю средние, по двум средним на каждом - просадки. Сортирую тикеры по величине просадки. Где перевалили за заданный порог (скажем, больше, чем минус 2%) - кидаю тестовые заявки на 1 лот. Исполнились? Запоминаем таймфрейм, по которому открывались, следим дальше. Не исполнились - хрен с ними, снимаем. Просадка тикера из портфеля больше, чем на 2% относительно цены последней покупки? Отлично, докупаем еще лот, если деньги есть. Тикер из портфеля растет? Двигаем виртуальный "стоп", сначала в безубыток, потом на половину прибыли и т.д. Считаем доходность по текущему bid-у с учетом всех комиссий. Перевалила за 25%гг? Скидываем нахрен всю позицию. На случай буйного роста есть еще критерий выхода по тейк-профиту при откате цены на четверть от локального максимума. Вот пока, упрощенно, и вся лопата )

Вам не кажется, что где-то здесь явное противоречие? =)
Риск - это, все-таки, мат. ожидание потерь, а не абсолютная величина. Представьте, что рынок сыплется, т.е. в среднем все тикеры стабильно и энергично ползут вниз - и тогда эти 99 (ну, к слову, не 99, а около четырехсот пятидесяти - процент каждый раз будет от меньшей суммы) неудачных сделок быстренько выщелкают все, что смогут, если каждый раз "резать убыток". Т. е. понятие "риска" тут однозначно связано, помимо ваших ставок "1 к 3-м", еще и с выбором точки входа.

Мне кажется, VPM под сделкой подразумевает удержание позиции от открытия до закрытия, а не сам факт покупки/продажи.Интересно, из каких соображений вы этот риск оцениваете. Ежли я что-нибудь в чем-нибудь понимаю, то риск - это величина потерь помноженная на вероятность эти потери поиметь. Т. е. подразумевается оценка апостериорных вероятностей наступления двух возможных исходов, причем не "когда-нибудь", а желательно в заданное время.  

Затем, что инструмент надо выбирать по задаче. У трактора с плугом в 10 метров тоже есть сильные стороны, вот только чтобы грядку вскопать, лучше все же взять лопату - быстрее и проще, и соседский забор сносить не надо.

VPM, вот честно, не все ли равно, для чего язык был создан? Другого нет. Что дали - с тем и работаем. Дали бы tcl - писали бы на нем. В начале  знакомства с lua в квике я тоже бросался на все подряд - и ООП, и кучу обратных вызовов, и dll, и черт знает что еще. Но в итоге выкинул нахрен всю эту требуху. Оставил чистый lua, чистый процедурный стиль и минимум необходимых функций, позаимствовав многие идеи Владимира со страниц этого форума. Идеи как раз конкретные и выраженные обычным русским языком, а не килобайтами кода. За это ему спасибо.

Если все задачи условно разделить на два рода "как делать" (механика торговли) и "что делать" (алгоритмы торговли, управление портфелем), то по первым вопросов у меня не осталось: заявки подаются, исполняются и снимаются как задумано, сделки обрабатываются так, что я знаю свою прибыль (или убыток) с каждой закрытой сделки с точностью до копейки, учет портфеля ведется и ничего не теряется, и даже есть маленький диалог, чтобы "на лету" отбирать у скрипта деньги или наоборот.

Куда важнее "что делать" - но об этом здесь не говорят. И по этой части у меня вопросы есть, но на них должен, видимо, каждый должен ответить сам - заплатив за эти ответы деньгами со своего счета :))

"Так" - это как? Делать простые вещи через архисложную жопу? Не согласен. А что такое "потенциал использования lua" мне вовсе непонятно.
"Хорошо" и "сложно" - это вовсе не одно и то же. "Совершенство достигается не тогда, когда нечего прибавить, а тогда, когда уже нечего отнять" - не помню, кто сказал, но мысль правильная.
Так и давайте может уже перейдем к задачам. Конкретным. А то все "многозадачность", "многопоточность", "фреймворки", а чем вся эта херня делу поможет (и какому конкретно делу) - вообще неясно.

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

Х**ня какая-то. У меня глаза вытекли.

Возвращаясь к вопросу, поставленному в теме.
Неделю назад отправил свой скрипт в свободное плавание вот с такой конструкцией в OnTrade():Если is_maker == false, то считаем, что сделка прошла по рынку.
Последующее сопоставление логов скрипта с отчетом брокера о сделках не выявило расхождений между ними в вопросе разделения сделок на мейкерные и тейкерные.

В целом, значит, можно утверждать, что хотя бы у одного брокера (ВТБ), хотя бы на одной версии квика (10.3.1.13) эта конструкция работоспособна.

Конечно, поэтому. Не потому же, что алгоритмы хорошо продуманны  
А если серьезно, я из ваших идей многое для себя взял по части механики торговли. От использования единственного прерывания OnTrade() со стеками сделок и заявок с ограниченным временем жизни до распределения операций в цикле main() по прерываниям на 0.25/0.5/1.0/2.0 секунд для балансировки нагрузки на проц ввиду его дохлости. Осталось еще вот только сама малость - алгоритмы довести до уровня, чтоб на комиссии можно было плевать :))

Владимир, таблицу "состояние счета" я стараюсь не открывать. В целом она, конечно, хороша. Два только недостатка:
1. Эта сволочь неведомым образом в случайное время (особенно, почему-то, во время закрытия дневной сессии) начинает тормозить квик так, что в скрипте 1-секундный интервал sleep() в цикле main() растягивается на реальных 4 секунды и больше. Но это у меня. Возможно потому, что под биржевые игрушки выделен старый нетбук с 2 гигами памяти и каким-то там селероном о двух вёдрах.
2. Для решения задачи расчета комиссии на отдельные сделки совершенно бесполезна :)

А поподробнее? В каком портфеле? Имеете в виду значение exchange_comission в данных, приходящих в OnTrade()?
Так никто и не говорит о том, что надо что-то "гарантировать". Речь о том, чтобы надежно узнать, какой именно была состоявшаяся сделка, чтобы рассчитать размер комиссии - а когда еще это делать, если не по факту заключения сделки? Может, квик чего-то там и присылает в OnTrade() о комиссиях, но насколько можно этим данным доверять, вот вопрос. Я в курсе, что вы на комиссии болт кладете (или уже нет?), но мне лично спокойнее, когда учет денег ведется возможно точнее.Вот всю подобную хрень я и имею в виду, когда говорю, что квик - штука местами странная, а работает все это с кучей условностей. Сам стараюсь от квика брать только минимум самых необходимых данных. А то полезешь глубже - а там два бита вместо одного, или еще какое-нибудь говно кучерявое.  

Игорь М, спасибо! Лишь бы оно работало. А то ж знаете сами, квик такая штуковина чудесатая. Есть-то много чего, только работает все это порой довольно странно и с кучей условностей :)  

А вопрос-то правильный, интересный и нужный. И хорошо бы узнать, что скажут об этом разработчики.
Поскольку внятного ответа так и не было, подниму тему вновь. Вопросов здесь, на самом деле, два:
1. Какой параметр в таблице сделок (или в данных, получаемых от прерывания OnTrade) позволяет определить, была ли сделка "тейкерной" или "мейкерной" в том смысле, что заложен в комиссионные тарифы Мосбиржи?
2. Зависит ли передача этого параметра в терминал пользователя от настроек на стороне брокера?

Вместо "чел" подставь "nikolz", вместо "это" - 95% собственных опусов. Вот это будет правильная постановка вопроса.

Не вижу связи между названием темы здесь и содержанием статьи. Уж для чего-чего, а для решения прикладных задач на клиентской стороне QUIK вся эта муть нахрен не нужна. С серверами и "интеграциями" сисадмины брокера пусть сношаются.

Не по теме, просто пришлось к слову. Товарищи разработчики, а что надо было курить, чтобы нагромоздить такую вот дикую мешанину из параметров, когда часть из них на одном языке, часть на другом, и вся эта хрень еще зависит от языка интерфейса программы?! В английском словаре слов не нашли что ли, раз понадобилось притащить в КОД русский язык?

Владимир, про дело вкуса согласен. Только чтоб этот вкус сформировать, надо некоторое время поковыряться. А если хочется ускорить процесс, то хорошо спросить у людей более опытных - на то мы здесь все и собрались :) За разъяснения спасибо.

Владимир, вопрос к вам по оценке ликвидности тикера. В целом, я сейчас поступаю так же, как вы многократно описывали - считаю число изменений цены за последнюю минуту и ранжирую значения на несколько диапазонов. Из вашего опыта, при каком значении этого параметра на тикер можно не обращать внимания, считая "мертвым"? Сейчас считаю тикер дохлым, если цена изменилась 3 или меньше раз в последнюю минуту. Только вот сдается мне, надо или интервал для оценки увеличивать, либо уменьшать это значение: один из тикеров дважды сползал вверх на 3 с лишним процента и обратно, находясь при этом в "мертвом" состоянии. Следовало бы забрать прибыль, а скрипт не обращал на него внимания ))

Вроде, кучу способов уже накидали )
Я для себя избрал самый ленивый способ - через curl.

Владимир, ну и вы ведь в коде предусмотрели все эти возможности - отсутствие задержек, прорисовки, отправки транзакций, симуляцию сделок (OnTrade же не приходит?) - тоже своего рода "заглушки". Тут уж кому как удобнее - либо сразу встроить все это в рабочий код, либо подменять часть квиковских функций на время работы с данными из файлов. Не шибко одно другого труднее :)

Владимир, вы как-то писали, что предусмотрели работу своего скрипта по историческим данным. Для этого вы его тоже в терминале квика запускаете? Если от квика используется пяток функций, вполне можно заместить их "заглушками" и запускать скрипт для отладки через lua.exe. Ну при условии, конечно, что отлаживаются только алгоритмы торговли, а не взаимодействие с глючным терминалом :)

Спасибо за ответ.

Здравствуйте. Неправильно отображаются графики цены фьючерсов, которые экспирируются в следующем году. Пример на скриншотах. VBH2 - проблем нет, VBH3 - отображает данные за 2013 год.

Выставить лимитную заявку практически в первую секунду сессии можно при помощи стоп-заявки "стоп-цена по другому инструменту". Я делаю так:
1. инструментом условия выбираю тот же инструмент, по которому хочу выставить заявку;
2. стоп-цену выставляю заведомо ниже ожидаемой цены открытия;
3. цену покупки/продажи, соответственно, нужную мне.
Как только сессия откроется и пройдет первая сделка, выставится лимитка по заданной цене.
Вот только автоматически прикрыть эту лимитку стопами так же легко не выйдет - тут, действительно, или пишите скрипт, или выставляйте стопы заранее. Но в последнем случае есть риск нарваться на непредвиденное :)

Хочу уточнить, правильно ли я понял здесь и ранее. Вы используете только по одной последней "свече" каждого таймфрейма, а каждая свеча по сути пара оценок (среднее и дисперсия) за интервал?

Послушай, умник. Единственный дебил на этом форуме - это ты. Ты лезешь как затычка в каждую жопу со своими "грамотными" советами изучить по 10 ненужных фреймворков и прочим бредом для решения тривиальных задач. В чрезвычайной ценности и эффективности предлагаемых тобою решений все имели возможность убедиться.  

Может, я чего-то не понимаю, но нахрен такие сложности? Откройте демо-счет с квиком у любого брокера и отлаживайте свои скрипты, покуда терпения хватит.  

Спасибо за ответ. Ваш подход мне понятен, и я с ним в большинстве согласен. В моем случае уход от любых асинхронных вызовов обусловлен дрянной связью (YOTA), которая имеет привычку отваливаться в любую секунду и восстанавливаться, когда ей вздумается. Отправив заявку, можно OnTrade и не дождаться. А через 10-15 минут, когда QUIK соизволит восстановить подключение после серии ошибок "вы уже работаете в системе", все равно придется разбираться с числом позиций, чтобы понять, что же за это время изменилось. В таких условиях работать на коротких таймфреймах невозможно, и надо в первую очередь обходить различные глюки связи.

Нули в trans_id мне пока не прилетали, возьму на заметку.

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

Не знаю, насколько сложная у вас задумка, но позволю себе поделиться мыслями.
1. OnTrade идет нафиг, как и большая часть калбеков.
2. Вы выставили заявку по конкретному инструменту. Контролируйте ее исполнение по флагам, но тут есть нюансы.
3. Если даже заявка по флагам исполнена - не факт, что она не отклонена биржей или брокером. В таком случае в таблице заявок она не появится, хоть запроверяйтесь. Поэтому либо сверяете число открытых позиций через getFuturesHolding до и после исполнения заявки, либо ловите OnTransReply и проверяете коды ошибок. Но слепо полагаться только на order.flags нельзя.
4. Цену исполнения заявки можно получить из таблицы trades. Связь между заявкой и сделкой лично мне больше нравится прослеживать через trans_id - идентификатор транзакции будет одинаковый у заявки и заключенной по ней сделки. Если вы входите в рынок по стоп-заявке, то trans_id будет одинаковый у всех - у стоп-заявки, у выставленной по ней лимитки и у сделки. Идентификаторы присваивайте инкрементно с какого-нибудь большого значения, например с 1000000.
5. Обращения к таблицам QUIK - сравнительно медленные операции, но если ваш робот не выставляет по 10000 заявок в час - то это неважно.

P.S. ZayavkaIspolnena_F_Buy = true - простите, но это жесть. Учите английский.

Сам задал вопрос, сам себе и отвечу.
Да, оба пункта имеют место быть. Но есть одна проблема с отслеживанием значения linkedorder.
Как известно, при срабатывании стоп-заявки прилетает OnStopOrder(). При первом его вызове значение linkedorder вероятнее всего будет иметь значение 0, поскольку номер выставленной лимитной заявки еще не будет известен. Но когда лимитная заявка выставится, OnOrder() по ней может быть вызван раньше, чем OnStopOrder(), который принесет нам номер выставленной лимитки в атрибуте linkedorder. И при обработке в OnOrder() мы не сможем только по значению атрибута linkedorder стоп-приказа (который в тот момент все еще равен 0) установить соответствие между стоп-заявкой и порожденной ею лимиткой. А вот по trans_id - можем, поскольку выставленная стоп-приказом лимитная заявка получает то же значение этого атрибута, что и у стоп-приказа.

swerg, спасибо!

Здравствуйте. Каким образом правильно идентифицировать лимитную заявку, порожденную срабатыванием стоп-заявки?
1. Номер выставленной лимитки содержится в поле linkedorder породившей стоп-заявки.
2. Значение trans_id у порожденной лимитки совпадает с trans_id стоп-заявки, по которой она выставлена.

Оба пункта имеют место быть?

Здравствуйте.
Выставляю лимитную заявку через sendTransaction(), далее в OnOrder() через флаги проверяю ее состояние (активна, исполнена или снята).
Вопрос вот в чем. Сложилось впечатление, что при достаточно быстром исполнении заявки сразу прилетает статус "исполнена", минуя состояние "активна". Это так и есть, или я чего-то упустил?