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

Повторное срабатывание колбеков - явление нормальное... OnOrder у меня и раньше многократно срабатывали, никак не мешали, а OnTrade стал многократно срабатывать только на днях.

Я не стал запоминать Id сделок в таблице, в тектовую переменную пихать и т.п. Можно все проще сделать:
Идентификаторы сделок увеличиваются. Это порядковый номер сделки на сервере. То есть, обрабатывать нужно только те вызовы, где идентификатор больше ранее приходивших.

Эээээ... блин... а чего-то это их не отличить?! trade_num же есть... )))))
Извините, редко программлю, не все помню )
Большое спасибо!

Сергей, предложенное решение выглядит очень рискованным. У меня парный трейдинг. Заявки по инструментам А и B выставляются одновременно. Конкретный сегодняшний пример. По инструменту А заявка была исполнена за две сделки А1 и А2, причем, по первой OnTrade сработал 6 раз, по второй 3 раза и по другому инструменту тоже 3 раза, и все это было жутко перемешано:

A1
A1
A1
A1
A2
A1
A1
A2
B
A2
B
B

Если бы объем по А1 и А2 был одинковым, их бы вообще не отличить... Мне как сравнение с номером последней сделки помочь может и как часто обновляется эта таблица сделок?
Все это нужно для быстрого расчета текущей позиции, которую вообще-то можно и в getItem("FUTURES_CLIENT_HOLDING",i).totalnet посмотреть... только эта таблица обновляется жутко редко. Наверно, где-то в настройках можно это время уменьшить, но все равно... За время между обновлениями можно так наторговать, что торговать будет нечем :) И каков вообще практический смысл от этих колбэк фукнций, если собственную позицию приходится определять вот так криво через анализ таблиц?

Не припомните ли вы обсуждение какого-либо более быстрого и надежного способа?

Спасибо!

Сергей, а изменения-то где и с чем они связаны? Робот у меня работает всего два месяца, все это время приходило по одному OnTrade на одну фактическую сделку. Это было удобно. Что и почему изменилось сейчас... и как теперь отличать новые и повторные OnTrade с одинаковыми идентификаторами?

Вообще, колбэки не сама биржа шлёт? Я не уверен, апдейт Quik имеет какое-нибудь отношение к многочисленным срабатываниям OnTrade?

Добрый день

Сегодня согласился обновить файлы в Quik, получил проблемы с роботом.
Суть: ранее OnTrade вызывался только один раз, а теперь по 3-6 раз. Ранее многочисленные вызовы колбэк-функций наблюдал только в OnOrder.
Кроме того, дважды сегодня Quik самопроизвольно упал, чего раньше не наблюдалось. Может, просто совпадение...
Текущая версия 7.2.1.5.

Не вполне понятно, что делать c множественными вызовами OnTrade. Допустим, в заявке был указан объем 2. Из этого объема прошла сделка объемом 1. Потом пришел новый колбэк OnTrade с объемом 1 и тем же идентификатором заявки. Как понять, это повторное срабатывание OnTrade на первую половину или до конца уже исполнилась заявка, т.е. вторая половина пришла?

Кто-то еще поимел подобные проблемы... и проблемы ли это вообще? :)

Спасибо!

Вооот! Точно! Не в OnTrade нужно ловить, и не сделки!
СПА-СИ-БО!

Это ирония или что?
Я всерьез рассчитываю, что именно указанная в описании функции переменная/таблица будет содержать необходимые данные.

полагаю, что есть в описании функции, то и будет работать:
function OnTrade(trade)
function OnTrade(trades)
function OnTrade(ooooooo)

ooooooo.qty - рабочий вариант, ась?

Уважаемые господа, вопрос не решен.

В таблице trade нет никакого balance. Я анализирую то, что приходит в OnTrade.
Есть trade.value, но это объем в деньгах, ничем не помогает.

Печалька такая: независимо от того, полностью или не полностью выполнена заявка, биты "0" и "1" в flags ВСЕГДА нулевые. Это проверено экспериментально. Конкретно код такой:
   if bit.band(trade.flags,1) == 0 and bit.band(trade.flags,2) == 0 then isComplete = true else isComplete = false end
Может, тут ошибка? Я ее не вижу. Следующий бит "2" срабатывает при аналогичной проверке на buy/sell корректно:
   if bit.band(trade.flags,4) > 0 then operation = sell else operation = buy end

Как проверить-то?!
Не хочется запоминать отправленное в заявке значение объема, а потом смотреть на пришедшее в OnTrade trade.qty, вычитать и сравнивать с нулем... это будет костыль какой-то.

Heeeeeeeeeeeeeeeeeeelp !!!
Спасибо!

"тайно" =)
Постановка вопроса претендует на раскрытие глобального коварного замысла, несомненно, вредоносного по своей сути :)

А можно ли использовать только balance без битовых проверок?

Добрый день
Как узнать, полностью ли выполнена заявка?
Из мануала:
бит 0 (0x1)  Заявка активна, иначе – не активна  
бит 1 (0x2)  Заявка снята. Если флаг не установлен и значение бита «0» равно «0», то заявка исполнена  

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

Итак, "0" и "0" или "0" и "1"?

Спасибо!

Большое спасибо всем поучаствовавшим.
Решение видно. Совпадение расчетной ЕМА с ЕМА из Quik точное.

Добавлю, что Quik наверняка не анализирует данные за пределами своих 3000 свечей. Это проверялось.
То есть, понятно, что моя расчетная длинная EMA, тянущаяся из глубин истории, куда "правильнее", но это никак не греет. Нужно найти способ рассчитать "неправильную" EMA из Quik.

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

Добрый день!
Не понятно, как считаются EMA в Quik.
Нужно посчитать EMA вне Quik (анализ исторических данных), а в реальной торговле я беру EMA из Quik. Соответственно, очень хотелось бы, чтобы расчетная EMA совпадала с фактической EMA.
Текущее понимание вещей:
1. для расчета EMA используется EMA предыдущей свечи
2. для расчета самой первой EMA какого-то отрезка берется среднее арифметическое (МА) того же периода (точно ли???)
3. Quik хранит около 3000 свечей в истории

Для малых периодов проблема не стоит остро. Если считать EMA с периодом 200, например, то после 3000 свечей расчетная EMA200 и фактическая EMA200 близки с разумной погрешностью, а вот когда я пытаюсь посчитать EMA2000, например, то тут "жесть" полная. Погрешность такая "конская", что анализ ист. данных теряет смысл.

Опыты показали, что МА2000 из Quik действительно отступает от первой свечки цены актива на 2000 позиций (как и первая EMA200 появляется после 200 свечек цены). Итак, первая точка EMA2000 появляется на 2001 свечке в соответствии с ожиданиями. Однако, эта первая точка явно не равна среднему арифметическому close первых 2000 свечей цены. На левом конце EMA2000 самая гигантская погрешность. С расчетом последующих свечек по формуле $emaPrev + (2*($LastClose - $emaPrev)/($period + 1)) погрешность уменьшается, но к моменту торговли, т.е. после еще 1000 свечек она все еще остается гигантской и неприемлемой.

Что делать?

Так... экспериментально и из чужого кода выяснил, что проблема в mode=0.
Где можно почитать об этих mode?
Поделитесь ссылочкой на мануал, пожалуйста. Есть что-либо более полезное и подробное, чем http://help.qlua.org ?
Спасибо!

TransInc = TransInc + 1
   t = {
       ["ACTION"] = "MOVE_ORDERS",
       ["CLASSCODE"] = clssS,
       ["SECCODE"] = localInstr,
       ["ACCOUNT"] = clntS,
       ["CLIENT_CODE"] = clntS,
       ["MODE"] = "0",
       ["FIRST_ORDER_NUMBER"] = tostring(id),
       ["FIRST_ORDER_NEW_PRICE"] = tostring(price),
       ["FIRST_ORDER_NEW_QUANTITY"] = tostring(val),
       ["TRANS_ID"] = tostring(TransInc)
   }
   res = sendTransaction(t)

По-моему, отличный пример.
Мне показалось, что вы с иронией о переборе.

Большое спасибо вам обоим!

тот самый, несколько смахивает на holy wars =)
Вы сами каким способом пользуетесь? Перебором все же или соглашаетесь на какие-то ограничения типа "только с целочисленными индексами"?

Эх! Очень неожиданно...
Большое спасибо!

А как люди выходят из положения? Разумно ли все индексы привести к строчному виду?

Добрый день

Искал у себя баг, не нашел. Очень похоже на то, что #table выдает разные значения. У кого-то случалось, что #table == 0, когда там точно что-то есть? Если это возможно, переформулирую: как надежно определить число элементов?

Спасибо!

Большое спасибо, Егор!

Добрый день

Не понятен механизм замены заявки на другую. Что именно не понятно:
1. почему там сразу для двух заявок цена, количество и номер? Их вообще две или больше? =)
2. нужен ли TRANS_ID или вместо него и используется один/два first/second_ORDER_NUMBER?
3. откуда брать номер заявок - из OnOrder(order_num) или OnTransReply (trans_id)?
4. что будет происходить, если одна из заявок уже исполнена?
5. вместо ответов можно одну ссылочку дать на исчерпывающее руководство... я такого пока просто не нашел, гуглю примеры, коих считанные штуки

Спасибо!