Я имею в виду "режим кентавра", когда робот торгует параллельно с юзером. Как обрабатываются возможные конфликты? Мои соображения такие.
0. Главный здесь юзер, у него на торговлю нет никаких ограничений.
1. Скрипт должен быть в куре всех действий юзера (и своих, разумеется) и ловить их по прерываниям OnTrade и OnOrder.
2. Я не уверен, что OnTrade вообще нужно обрабатывать - ведь OnOrder в этом случае всё равно должен придти - по нему, похоже, и можно всё посчитать.
3. Скрипт я вижу "одноразовым" - он не должен посылать заявок по данному тикеру, если не обработаны все предыдущие (пофиг, от робота или от юзера).
4. Сами заявки хранятся у брокера, а не в скрипте и даже не в Квике. С другой стороны, подавляющее большинство заявок (по крайней мере, МОИХ заявок), должны бы обрабатываться немедленно (я выставляю цену покупки или продажи соответствующим образом), и потому о них можно забыть сразу после исполнения, т.е. хранить именно в теле скрипта - от первого до последнего OnOrder.
Одним словом, я не знаю, как всё это дело лучше организовать. А кто-нибудь знает?
Пользователь
Сообщений: Регистрация: 25.09.2020
22.11.2020 19:55:09
Ну что, так никто ничего и не посоветует? Ведь заявки со сделками - это ЕДИНСТВЕННОЕ, что должно быть в ЛЮБОМ роботе, и потому этот механизм должен быть вылизан до блеска! Вплоть до включения его в язык. Ладно, излагаю то, что я вижу сам, что собираюсь завтра реализовывать, когда биржа откроется.
1. Скрипт просто посылает заявку на покупку или продажу (sendTransaction) и никак не отслеживает это дело у себя - ведь то же самое может сделать и юзер.
2. О факте существования [зарегистрированной] заявки (от кого бы она ни исходила) скрипт узнаёт по приходу прерывания OnOrder, и тогда регистрирует её у себя. Предполагаем, что заявок может быть несколько на каждый тикер, т.е. это таблица Lua, в которой ключом является код заявки, а значением - код сделки (которое мы вначале обнуляем). В принципе, сюда же можно занести количество лотов и цену - на всякий пожарный.
3. Поскольку прерывания OnOrder, как и OnTrade, здесь приходят "пачками" (заявки у меня обычно вызывают два прерывания, сделки - три), то следующие прерывания OnOrder с тем же кодом просто игнорируем (если это не снятие заявки - в противном случае убиваем элемент таблицы заявок).
4. Я считаю (лучше сказать "надеюсь"), что прерывание OnTrade НЕ МОЖЕТ "потеряться" и придти после того, как пришла информация о другой сделке по той же заявке, а потому держу для каждой заявки только ОДНО поле для (текущей) сделки. Если оно приходит впервые - запоминаю его код по ключу текущей заявки и произвожу по ней действия по изменению своего портфеля и кошелька.
5. Если заявка полностью выполнена (или снята) убиваю заявку в скрипте - все необходимые действия уже произведены.
Кактотаг...
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
23.11.2020 13:02:37
Цитата
Владимир написал: Ну что, так никто ничего и не посоветует?
Писателю десятка бестселлеров с богатейшим опытом разработки мега-систем в детских игрушках грешно советовать. Так что уж как-нибудь сам выгребайся.
Пользователь
Сообщений: Регистрация: 25.09.2020
23.11.2020 13:39:30
swerg, Ну да ну да... советчиков с растопыренными пальцами, "объяснявших", что 2 и "2" это разные вещи, было как собак нерезаных. а вот если головой подумать требуется...
Да выгребусь уж как-нибудь. С диалогом выгреб, а с подачей заявок да приходом квитанций и подавно.
Пользователь
Сообщений: Регистрация: 25.09.2020
24.11.2020 14:52:50
О, сколько нам открытий чудных!..
Syntax error while compiling C:\QUIK\my.lua 237: "goto q" at line 205 jumps into the scope of local "Tr"
Такого я ещё не видывал нигде и никогда! Ну да, заполняемая таблица заявки у меня описана как local Tr={ ["TRANS_ID"]=tostring(k), ["ACTION"]="NEW_ORDER", ---
Но метка-то, блин, стоит ПОСЛЕ неё! Ладно, сделаем глобальной - авось, сожрёт...
Пользователь
Сообщений: Регистрация: 25.09.2020
24.11.2020 15:17:52
Сделал глобальной в мейне таблицу заявок: Tr={}; Инициализацию изменил, соответственно, на: Tr.TRANS_ID=tostring(k); Tr.ACTION="NEW_ORDER"; ... Заявка (по команде из всплывающего меню) прошла и даже исполнилась, "зато" теперь по OnOrder (отлов этой заявки) ругается на "attempt to concatenate a nil value (field 'CLIENT_CODE')". Раньше не ругалась. Я где-то читал, что CLIENT_CODE - необязательный параметр, но без него она у меня заявки не принимала. А теперь чего ей надобно? Может, имя поля какое другое? Может, она мне взад уже не отдаёт код клиента? Нет, не может - раньше ведь работало! Уффф! Большой перекур!
Пользователь
Сообщений: Регистрация: 25.09.2020
09.12.2020 15:09:04
Как оказалось, я страдал чрезмерным оптимизмом: мало того, что прерывания OnOrder и OnTrade приходят пачками (что, конечно, есть форменное свинство и должно быть исправлено), так они ещё приходят и вразнобой! По крайней мере, когда одна заявка реализуется через нескольких сделок: сначала приходит OnTrade с ID заявки и ID сделки, затем с ID заявки и ID ВТОРОЙ сделки, а затем с ID заявки и снова, падла. с ID ПЕРВОЙ сделки! В результате мой алгоритм думает, что сделок совершено больше, чем в действительности. Ну руки бы пообрывал таким программерам! И что мне теперь, держать инфу обо всех сделках до конца сеанса и бегать по ним по всем - вдруг она уже обработана? УЖАС, господа! Столько версий расплодилось - НУ ХОТЬ ЧТО-НИБУДЬ БЫ работало по-человечески!
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
09.12.2020 20:17:55
Чета ржу
Пользователь
Сообщений: Регистрация: 25.09.2020
09.12.2020 20:32:59
swerg, А что ещё делать остаётся? Управление теряется, прерывания идут как бог на душу положит, с типами данных полная задница, например: iT=tonumber(GetCell(T,p1,0).value); - скрипт вылетает, причём даже не хрюкает - смотрю, а он уже полчаса как стоит, а вот iT=tonumber(GetCell(T,p1,0).image); - пока работает. Ну и куча других аналогичных "мелочей". Я ведь писал когда-то, прямо в этой ветке - как чувствовал: 4. Я считаю (лучше сказать "надеюсь"), что прерывание OnTrade НЕ МОЖЕТ "потеряться" и придти после того, как пришла информация о другой сделке по той же заявке, а потому... Зря надеялся.
Пользователь
Сообщений: Регистрация: 27.01.2017
10.12.2020 10:44:26
Владимир, на самом деле, действительно на грани, как минимум непонимания.
Вам, как только Вы появились на форуме, было уже сказано, что есть много тонкостей и нюансов.
Теперь Вы просто собираете все. При этом все это обсуждалось на этом форуме уже много много лет, предложены разные варианты решений.
Я Вам могу еще одну особенность дать - в таблице trades (это там где сделки хранятся, она же по колбеку OnTrade), номер транзакции появляется не всегда сразу. Он может быть 0, а потом меняется на корректный.
Пользователь
Сообщений: Регистрация: 25.09.2020
10.12.2020 10:54:24
Nikolay, Да я понял, понял - "зачем просто, когда можно сложно"?
НАФИГА юзеру "много тонкостей и нюансов"? Прошла сделка - пришло ОДНО прерывание, и дело с концом! Прошло изменение завки - тоже пришло ОДНО прерывание. А эти "тонкости" обычно называют "глюками".
Ну, хорошо: "все это обсуждалось на этом форуме уже много много лет, предложены разные варианты решений". Эти предложения РЕАЛИЗОВАНЫ, наконец, или "как всегда"?
Да мне плевать на таблицу trades - я туда вообще не лезу никогда! Пусть там "номер транзакции появляется не всегда сразу" - мне какое дело? вот когда он "потом меняется на корректный" - тогда и дайте мне НОРМАЛЬНЫЙ OnTrade! Неужели за "много лет" такого "варианта решения" так и не было предложено? Ну, ловите - предлагаю...
Ведь заявки со сделками - это ЕДИНСТВЕННОЕ, что должно быть в ЛЮБОМ роботе, и потому этот механизм должен быть вылизан до блеска! Вплоть до включения его в язык. Ладно, излагаю то, что я вижу сам, что собираюсь завтра реализовывать, когда биржа откроется.
