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

Здравствуйте.
А можно ли получить демо доступ к серверу, обслуживающему старые версии QUIK?
Ну, или по другому, -- подключиться на демо со старой версии.

Более свежие версии вообще не загружались. По совету таких же разработчиков, как сам, пришлось откатиться на 8.13.
Поймите, загрузить график с первого вызова функции -- это ещё не самоцель (сама цель).

Спасибо.
И еще вопрос. Он ранее поднимался . . .
Может сейчас есть какое-то решение.
У меня запрос графика, как правило срабатывает только со второго раза.
Что посоветуете?

Да, предыдущего.

Зарегистрировать . . .  Да, было бы здорово.

Продолжаю про заказ данных.
Сейчас работает. Однако, . . .
Крайне неудобно (и вообще странно, что это в настройках)
перезаказывать данные заново НЕ ПРОГРАММНО.
Есть ли способ делать это, не прибегая к WIN API (программно нажимая графические кнопки)?

А с клавишами, да, действительно, -- помогло.

Возможно, надо уточнить, что "эксперименты" ставились в субботу.
Код такой:
function test_CDS()
  if ds ~= nil then return -1 end
  ds = CreateDataSource("SPBFUT", "RIH3", INTERVAL_TICK)
    if  ds == nil then return -1 end
  ds:SetEmptyCallback()
  sleep(100)
  size = ds.Size
  return ds
end;
На момент "экспериментов" проверок "if . . ." могло не быть.
Сейчас сразу после второй проверки (т.е. непосредственно перед ds:SetEmptyCallback()  )   еще  sleep(300)  стоит.
Нужен ли? Что скажете? А, может, "противопоказан"?
Еще полазил по форумам и описаниям, код поправил. У меня в конструкции:
  ds=CreateDataSource(Class_Code, Sec_Code, INTERVAL_M15)
  ds:SetEmptyCallbac()
  sleep(100)
"с прошлых времен" во второй строке вместо двоеточия точка стояла. . .  ???

Или, может, есть какой-то способ получить эти данные (с начала ПРЕДЫДУЩЕЙ сессии) с помощью имеющегося функционала?

Версия терминала 8.13

Приветствую ВСЕХ.
Вопросы к разработчикам.
На вечорке, секция FORTS наблюдаю такую картину.
При перезаказе данных (Система/Настройки/Основные настройки/Программа/Получение данных/Обезличенные сделки/Перезаказать данные)
В ТОС данные с начала вечорки предыдущей сессии
В тиковых данных от CreateDataSource -- только текущей.
Это так должно быть???
Если да, то имею пожелание сделать одинаково = с предыдущей сессии как в ТОС.

В меню у отдельных пунктов, как-то, например, Создать окно / Котировки F4 или Система/Настройки/Основные настройки F9 ,   . . .
так вот эти функциональные клавиши не работают . . .
Это только у меня / так должно быть / не досмотрели / временно отключили и забыли . . .
Если не первое, то неплохо бы поправить (или убрать подсказки хотя бы) -- не портить мнение о разработчике . . .

Здравствуйте.
Не люблю создавать новые темы (что есть -- то есть).
И ведь, вопрос-то, пустяковый (для тех кто знает).

Скажите, пожалуйста,
где почитать
или изложите непосредственно в ответ
про
форматы числовых данных d16.5 и d16.6 ???

Заранее благодарен.

А работоспособность 32 разрядной версии еще долго будет?

Никак не привыкну к "функционалу"  этого форума.
Тем не менее имею желание сообщить, что интересы брокеров (читай, прямых покупателей продукта ARQA) могут весьма различаться с хотелками самой ARQA.
Посему, ...  мы  ... ВСЕГДА  . . .  приделывали костыли к тому, чего нам "предоставила" ARQA.
Костыли - уже, -- наши, чего мы теряем?
Как понимаю, своих траблов в V7, они в V7 "признавать" больше не будут, что ВОВСЕ не означает, что брокеры НЕ БУДУТ поддерживать серверы на V6 и V7. . .     ИЛИ . . . ARQA "думает" иначе  . . . ?
Как, резюме,  . . . ситуация принципиально хуже НЕ СТАЛА.

Здравствуйте, ВСЕ.
Подумал, что лучше ветки для вопроса всё-равно не найти . . .
Скажите пожалуйста, а на каком протоколе общается сервер QUIK с терминалом QUIK последней семерки и 64-х разрядной?

Думал, может, за определенное время дойдет до саппорта/разработчиков, или, может, роботостроители поддержат. . .
Сергей "ситуации" отличаются именно ТЕМ, что приходит калбек (хотя измененный стакан в срез не попал).
Если изменений не было, -- и калбека не было.
А полезность заключается именно в том, что на стороне клиента не нужно принимать стакан, т.к. он от предыдущего отличаться НЕ БУДЕТ.
Но, если пришел калбек, скрипт "знает", что изменения в стакане были, но время тратить на получение стакана бессмысленно.

При частичном изменении мы могли бы получать только строки с изменившимся объемом (т.е., например всего 3 строки вместо 100).

Господа роботостроители, прошу поддержать или объяснить, в чем я заблуждаюсь.

 8-битный плавающий...   должно быть, однако,  8-бАЙтный плавающий...  

Позвольте, встряну.
А не правильней ли. Область видимости NmbrOfCandles вынести за границы Init
И вместо #t использовать ее.

Понятно.
А принципиальная в нем необходимость/отличительные особенности, если биржа (возможно, не все секции?)
сама айсберги поддерживает/обеспечивает?

Про биржевой, вообще-то.

Цитата
Sergey Gorokhov написал: есть наш разработанный через отдельный модуль

Сергей, а он "программированию поддается" (программно можно такую заявку выставить)?
Я-то полагаю, что "Ваш" специально разработан, чтобы это дело алгоритмизировать БЕЗ программирования?

Да, и еще, я правильно понимаю, что после того, как брокер мою лимитку на биржу отправил, о её судьбе он может только "догадываться"?
Я, разумеется, не говорю о случае, когда "этот" уровень цены с встречная сторона уже "съела" (когда всё очевидно, "опять же" при условии, что транзакции на снятие этой лимитки я не подавал).

И, я правильно понимаю, что калбеков  OnOrder (например) при исполнении такой заявки будет тьма,
НО    linkedorder у  них будет -- единым?

Сергей, спасибо за развёрнутый ответ.
Всё понятно.

Сергей, вопрос к ВАМ.
С учетом того что написано на:
http://forum.moex.com/viewtopic.asp?t=21226&topicdays=0&postorder=asc&start=60

ПРИЗНАЮСЬ ЧЕСТНО, . . .
полностью не перечитал.
Есть такое на FORTS?
Если есть,  -- Где такие заявки "хранятся" (брокер / биржа)?

Мне неприятно это констатировать, НО уже минут 10 "ПИШЕТ" . . .  

Блин, наблюдаю,  . . . ) долго думает, дОлго пишет, чувствую, сейчас  . . .   "на  В  ишет".   ))

Сергей, вопрос ЕСТЬ.
Однажды столкнулся с такой вот "неожиданностью".
Мой брокер (очень близкий к вершине по рейтингу, разным рейтингам) не транслировал отдельные параметры, по отдельным инструментам,
далее (ВНИМАНИЕ) на отдельном из своих СЕРВЕРОВ.
Вопрос такой.
Есть ли в "арсенале" QLUA нечто специально "заточненное", чтобы программно "понять", что "данный" сервер какие-то нужные скрипту "параметры" НЕ транслирует?

Спасибо, он не пАймёт, он -- нАвичок (такие синие, с хвостами)

Я не спрашивал того, где могут быть (ожидая на бирже) выставлены мои стопы.
У меня, знаете ли,  пинг до брокера --    230-270.
География, "паммаешь ли".

Меня интересовало не место, а преимущества/вред от СТОПОВ  ДЛЯ БОТОВ.
Меня интересует, Честно ли ЭТА ОБРАБОТКА происходит.
И меня, разумеется, не интересуют рейтинги брокеров, составленные брокерами или ММВБ.

Ваша чукча, нака, сразу -- пЫсатель,   нака,     нИРазу -- не читатель.

"Прошу понять".

Это-то -- "вещь" известная и ни кем не скрываемая.

У-у-ффф. Всё самое лучшее для программера -- это то, что нашел или сделал САМ.

https://smart-lab.ru/blog/309922.php
Неужели всё -- ТАК?
(Знак вопроса долго не ставился как и переключение рус/лат, наверное это -- ЗНАК . . . )) . . . .)

"Всем -- Спасибо, Все -- свободны . . ."

Но если мнения есть, думаю, все с удовольствием почитают.

Видел такие в ордерлоге.
Странное дело. Флага встречной там НЕТ.
А по ценам в заявке и сделке -- явно с претензией на встречную.
Х-м. Будем ЗНАТЬ.

Сергей Спасибо. Но мой вопрос-то был примерно такого плана.
применять в роботе стопы или от них  -- "больше зла"?
Стопы (вред):
1. больше заявок, которые надо обрабатывать (больше потенциальных багов)
2. размещение на сервере у брокера, потенциально имеющего в своем арсенале алгоритм "собирания"  этих самых стопов (не дай бог, если он еще и ММ)
3. усложнение алгоритма обработки вариативности событий
Поясню.
У меня необходимость применения стопов ассоциируется с "желанием" построить робота использующего необходимость реакции в быстродействующих процессах (не важно открытие позы или ее закрытие)
На первый взгляд обрисовываются возможные проблемные вопросы:
Например, исполнился покупающий СТОП, а лимитка от него исполнилась частично.
Варианты обработки:
1 выставлять на исполненную часть СЛ и ТП (стоплосс и тейкпрофит) и ждать полного исполнения;
2 или ждать полного исполнения, до него СЛ и ТП НЕ выставлять
3 или на НЕисполненную часть заявку снимать и выставлять СЛ и ТП
А еще пока снимали, заявка еще исполнилась (частично или полностью), -- в связи с чем алгоритм еще дополнительно "накручивается".

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

В связи с чем хочется услышать.

Какие явные преимущества имеет робот, работающий именно "через" СТОП-приказы?

Спасибо

А сами команды подписаться/отписаться, которые по 30 инструментам следуют парами 1 раз в каждые 2-3 минуты -- для брокера "не забота"?

А сам факт множественной подписки и отписки брокеру  -- только "на руку", т.к.  85-90%% времени трафика именно по стаканам удается сократить?

Уважаемые Разработчики!
Вопрос -- такой.
Есть идея -- работать со Множеством инструментов из бота.
В Сетапе закладываются Фильтры (быть/не быть   входу в сделку), в том числе -- И по данным из стакана.
Робот -- типа, скальпер, т.е. (далее данные согласно моему ИМХО-видению алго-скальпера):
Средняя частота Проверок (период между проверками), когда нужен стакан -- 10-20 секунд.
Подразумевается, что: "10-20 сек. прошло, а Событие для проверки стакана не наступило, -- следующая проверка -- через 10-20 сек."
Реальная потребность в данных из стакана -- секунд 30 (на/из 2-3 мин., как видится).
Смысл в том, что потребность в данных из стакана имеется (например) 10-15% всего времени.
И, т.о.:
1. Связывая Объем трафика и необходимость в Значительных данных из стакана (с одной стороны);
2. И, заставляя брокера (его сервер, что вроде бы, должно происходить прозрачно/автоматически, т.е. для брокера) (, -- с другой),
Далее Вопрос:
Усматриваете ли Вы со Своей стороны какие либо проблемы, связанные со множественным подписанием/отпиской на/от стакан(а) по Множественным (до 30, например) инструментам?
Секция -- FORTS.

PS. (лимитные) ВЫСТАВЛЕННЫЕ(АЯ) по итогам исполнения стоп-заявки" . . .

Тогда, может быть, "коллеги" выше имели ввиду: "как узнать, как сработали ЗАЯВКИ (лимитные) по итогам исполнения стоп-заявки", -- а не сама стоп-заявка?

Николай, скажите, пожалуйста, какие явные преимущества имеет робот, работающий именно "через" СТОП-приказы?

Что-то участники форума всё-таки "стесняются".
Или считают свои знания САКРАЛЬНЫМИ?

Как-то делал "связки", типа quik с коннектором, программа анализа (предполагалось в будущем -- робот) и дополнительное приложение с несколькими сервисами (показывать главное, реализовывать стронний поток). Обе программки должны били еще следить друг за другом и квиком, чтоб не было зависаний. должны были друг друга перезапускать, заставлять коннектиться и т.п.
Связь между приложениями реализовывал с использованием SendMessage (в том числе).
Возникали ситуации, когда SendMessage не получал ответа по причине единого потока, ждущего самого себя.
Приходилось по всякому изъязвляться.
Так вот, были ситуации когда вышеописанные схемы на двухядерном компе работали, а на целероне отказывались.

Не совсем так.
Косвенные признаки ЕСТЬ.
Не всегда.
Если рассмотреть агрегированную (smart) сделку, которая цепляет несколько встречных с малыми объемами, ТО
в некоторых случаях изменение open_interest (далее OI) = 2 * qty или -2 * qty (оба открывались, оба закрывались).
Значит активный участник (с бОльшим объемом) открывался (в первом случае) и закрывался (во втором).
Зная, что делал активный, и как менялся OI, можно рассчитать, что делал каждый встречный участник.
В отдельных случаях можно увидеть как активный участник "переворачивался".
Можно вычислить направление изменения OI активного участника и при изменении OI на величину меньшую 2 (> - 2).
Smart - сделка характеризуется единым временем и направлением.

Да, и "опять же", если робот хоть сколько-нибудь позиционный, "умные заявки" тоже никак в концепцию покупающих стопов не вписываются.

Всем ПРИВЕТ и масса наилучших пожеланий.
А вот и снова я со своими вопросами.
Как всегда - не люблю создавать новых тем.
Контент этой наиболее полно соответствует тому что меня интересует.
(Спасибо автору топика и отдельное -- _sk_).
Не все еще перерыл, но на свои вопросы ответа (готового), чувствую не найду.
Поэтому пишу сюда.
Есть куча собственных наработок.
И в очередной раз нахлынула идея/желание/стремление как-то это всё наконец-то попытаться "монетизировать",
говоря проще всё-таки -- написать собственного бота.
Поскольку в сетапы торговых операций готов засунуть всё-что только можно, --
пришлось сделать собственный коннектор, на базе которого уже создан "скелет" робота.
Сначала хотелось программные единицы "развязать" (бот и коннектор), чтобы отладку бота вести не в DLL,
но исторически все "экспериментальные вещи" свалились в 1 кучу -- коннектор+бот (в одном флаконе),
Определенное время (почти 2 года) этот "скелет" у меня пролежал "без мучений".
За это время что-то поменялось в Квике, что-то нового узнал/от\крыл для себя (ну и кое-что также и забыл, как без этого).
Бот делался как-бы на общественных началах (протестировать определенную идею, старую известную).
Идея (в том, чтобы бот "кидал отложки") была не моя.
Тогда меня привлекла мысль/идея (вполне, возможно, -- ошибочная), что мне его будет проще отлаживать (в том числе и на боевом счете,
на котором денег нет, но исполнение стопов-то от того не зависит).
Однако, "возникли мысли" и другие.
А если лот -- не маленький (не 1 бумажка), и исполнится сразу не полностью, должна на остаток выставиться лимитка?
А если стоп-лимит и тейк-профит (уже после покупающего стопа) настроены с отрицательным спредом, тоже
будет лимитка?
В общем, получается, что от "ведения сделки" никак не отвертеться?
А еще есть определенные ограничения в заявке стоп-лимит и тейк-профит.
А еще разные мысли по поводу нежелания светить свои стопы брокеру.
А еще вот тут советы: http://www.bot4sale.ru/forum-menu/amisharp-forum/191-neskolko-voprosov-po-stopam-zayavkam-i-pozitsii...
Встречал еще пару сайтов, источники для данного поста не сохранил.
Если речь об HFT не идет . . .
Насколько (и где, по каким причинам) нужны стопы (например, для быстрой покупки, если твой же брокер тебя по ним же и не "отлюбит")?
Так же и с трейлингом сделки, может, "ну их в баню" стоп-лимит и тейк-профит.
А правильнее свой алгоритм трейлинга написать.
И даже защитный стоп обрабатывать самостоятельно (бот будет, так чтоб брокер его не видел).
Вобщем, хотелось бы для себя, прежде чем в очередной раз "засучить рукава", разрешить, если можно так сказать,
некоторые стратегические вопросы.
Что посоветуют более старшие в программировании ботов товарищи?
Обсуждение со стороны заказчиков ботов/потенциальных заказчиков также приветствуется.
Особенно по вопросам не программной реализации, а общих вопросов видения того, как боты/стратегии должны работать.
Прошу не стесняться.

Д. Д.
Если актуально ? . . .
Как вам такой вариант.

"Еще можно отслеживать изменения в ТТП (истории)".
Наступило время новой свечи (в таблице ТПП), а к-во сделок (проторгованных объемов) НЕ изменилось (т. е. сделок НЕ БЫЛО).

PPS. Вместо пустой таблицы QLUA может отправить Nil (например).

PS. Приходит Nil, и стакан (такой же ровно как "старый") принимать НЕ НАДО, прелесть -- в этом.

Здравствуйте, .. . . .   Ой ответили . . . 5 дней я не ждал . . . "устал", . . . "прошу прощения".
Сейчас просматриваю, и . . . обнаружил, . . .
За ответ спасибо.
В Вашем примере таблица изменений должна прийти пустой, -- "всего-то делов".
Что имеем?
1. Мы "обременены знанием", что изменения были.
2. Как и Ваш "новый стакан", не отличающийся от "старого", пустая таблица -- ровно настолько же информативна (знаем, что изменения были, какие --  не понятно).

Собственно, вот о чём и прошу.

Сергей, а что мешает "запоминать" стакан и новый сравнивать с предыдущим?

Добрый день. Всех с прошедшими.
Не отвечает ARQA.
Посему "нечайно" перечитал топик.
В результате к автору по изначальной теме возникли замечания.
1. Чтобы правильно оценить время исследуемой операции, необходимо отнимать время, полученное между вызовами подряд процедуры определения времени. Хотя в данном случае это и не очень актуально.
2. Чтобы терминал не ставил данной задаче более низкий приоритет, желательно выполнять процедуру в калбеке.

Добрый день.
Нашел у себя p2gate_ru.pdf.
Посмотрел.
На стр. 71  Таблица orders_aggr: Агрегированные стаканы.
Понимаю.
Но, зачем. Читал еще где-то, что оная не шлется постоянно, а (например,) раз в 3 минуты (на всякий случай, либо по запросу).
Получается брокер гоняет трафик вместо данных. ЗАЧЕМ?
Ордерлог всё решает.
И заметьте, я не прошу "весь" стакан (все изменения), а лишь -- в пределах агрегированного (50 х 50 на FORTS).