Хотелось бы получить практический пример использования ISecurity.GetSellQueue и ISecurity.GetBuyQueue.

Стаканы доступны только в режиме реальных торгов, в лабораторном тестировании они не доступны. Что пример должен делать?

Скрипт должен торговать на демо счёте в реал тайме.

Повторяю вопрос, что он должен делать со стаканами.

Он должен брать цену и объём на продажу и на покупку, те скрипт должен улавливать большие объёмы.

Суть в том что скрипт должен анализировать стакан и находить в нём большие объёмы, на основании этого выставлять заявки.

Классика:
Условие:
1. Время больше 16 часов.
2. Находим в стакане целое число цены акции (к примеру сегодня газик 193 р. или 192 р.), объем который выставлен на продажу более 1 000 000 акций.
2. Ставим лимитную заявку на 1 копейку ниже (к примеру 192.99 р) "одеваем шорты"
3. Сразу ставим стоп на 21 копейку по выше 193.20 р. с проскальзываением 0.05 %.
4. 193 р. должен быть локальным максимум(сегодняшним).
5. Выводим в безриск на 50 % проданного обема на 21 копейку ниже к примеру 192.78 р (хотя это будет не безриском не учтены комиссия брокера, но для примера нам не надо).
6. Профит 25 % части объема на 48 копеек ниже к примеру 192.49 р.
6. Профит 25 % части объема на 98 копеек ниже к примеру 192.01 р.

Аналогично лонг. Вот такой пример хотим!

Что-то мне подсказывает, что это уже сильно! Надо что-нибудь попроще. Нужен пример в виде блока: Если объем в ячейке бид+"с" ячейки, больше чем за n периодов(например 122 минуты) в этой же ячейке, но меньше чем за k периодов этой же ячейки, и меньше, чем в ячейке аск - "с" ячеек, то true, если нет, то false. Думаю, от такого примера, уже можно плясать игрой в стакане.
Понятно, что все работать буит тока в реале, в этом и вопрос...

Не пойму зачем нам нужен номер ячейки и его сравнение с предыдушем значением за 122 минуты. Я так предпологаю значит должна вестись запись стакана (каждой ячейки) на локальный компьютер. Это разве возможно? Я думал что записывать можно только тики (сделки).
Твой пример можно использовать только в целях сравниение силы быков и медведей.
Каждую ячейку на продажу умножаем цену на объем, а потом все ячейки складываем. Аналогично на покупку. Потом два значения сравниваем. А дальше алгоритм.

Вот в этом и вопрос. Потом уже можно делать системы в стакане.

Nektodron прошу Вас прокомментировать наше обсуждение!

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

Текущая реализация торговой системы TSLab именно на этом и построена, что программа старается обыграть все ситуации, встречающеюся при тренд следящей торговле. А именно: нехватка ликвидности, нерегулярный запуск программы или потеря связи. Для этого в программе предусмотрена не мало настроек, позволяющих корректировать работу в реальных торгах.

Поэтому прежде, чем делать какой-либо пример со стаканом, нужно решить эти проблемы для этого конкретного примера.

На мой взгляд самый простой пример, как можно использовать ISecurity.GetSellQueue и ISecurity.GetBuyQueue - это анализ текущий ликвидности. Т.е. можно написать индикатор, который будет анализировать строчки в стакане на предмет наличия нужного объема при проскальзывании не превышающим какой-то предел.

Напишите предложенный вами пример.

Вот это и хотелось бы видеть при исполнении маркет ордеров, а не закладывать в проскальзывание, как Вы рекомендовали 5%, на ФОРТС 5% - это уже уровень лимитного коридора дня за которым заявки не выставляются. Или такой вариант, цена подошла к границе коридора и какое тогда проскальзывание в маркет ордер закладывать? А если бы стакан анализировался, программа бы понимала на какое количество ордеров по какой цене можно рассчитывать.

Если вы заложили проскальзывание 5% - это не значит, что сделка будет исполнена на 5% выше. Более того 5% рекомендовалось для ММВБ, а не для ФОРТС. И так же было сказано, что проскальзывание нужно подбирать на основе наблюдения. Оно будет разным для разных объемов.
Что касается анализа стакана, это возможность есть в программе (через API) с самого начала. Сейчас в планах есть появление "кубиков" служащих для понимания текущей ликвидности. Однако, для этого еще нужно научить блоки открытия принимать рассчитанное количество лотов, а не только заданное.

Я может быть не правильно понимаю, но заложив проскальзывание в маркет ордер - выставляется лимитка с заданной ценой + проскальзывание, которая естественно и выполняется по лучшей цене.
При работе у границ лимитов, тяжкова-то и времезатратно определять какую глубину проскальзывания выставлять чтобы цена лимитника/маркета не вышла за граница лимита (т. к. такие заявки биржей откланяются) и при необходимости сработал стоп. Поэтому расчёт ликвидности стакана для маркет ордеров было бы само то.
ИМХО, конечно.

Ув. Нектодрон, а нельзя ли ввести функцию замера проскальзывания для конкретного инструмента,объема, таймфрейма.. ну т.е. для конкретного скрипта на основе обмена инфориацией.
Усредненную, за определенный период.. и т.д., но чтобы был какой-то ориентир для задания скрипту..

а каков алгоритм?

Давайте вернёмся к основной теме, предоставте пожалуйста пример анализа стакана используя ISecurity.GetSellQueue и ISecurity.GetBuyQueue.

Увы, у меня его нет, полагался на Ваше, более глубокое нахождение внутри процесса..
Вопрос снимаю чтобы не мешать теме ветки..