Счётчик числа сделок в секунду по одному тикеру

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: 1 2 3 4 След.
RSS
Счётчик числа сделок в секунду по одному тикеру
 
#1
28.05.2015 14:41:54
Решил выделить из другой темы: https://forum.quik.ru/forum10/topic536/

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

У кого есть какие идеи?
 
 
#2
28.05.2015 15:01:36
хорошо бы увидеть код(алгоритм), а то с нуля как-то лень начинать.
А вот покритиковать  чужой код ( то бишь дать идею) -это пожалуйста.
 
 
#3
28.05.2015 15:02:23
Цитата
Николай Камынин пишет:
хорошо бы увидеть код(алгоритм), а то с нуля как-то лень начинать.
а вы разве не заметили спойлер?
 
 
#4
28.05.2015 15:12:38
в общем, пока приходит на ум, что одно из: "время" или "число сделок" - уже изменилось, а другое - соответственно - нет. В таком случае, как задать правильно условие (с учётом специфики OnParam)?
 
 
#5
28.05.2015 15:58:18
"Программа / Сохранение данных / Получать пропущенные данные" - галочка включена?
 
 
#6
28.05.2015 16:09:12
давайте сразу договоримся: "Без галочек".

Я являюсь последовательным сторонником того, что скрипт должен сам решать и управлять потоком нужных ему данных, а не так как щас - непонятно в какой последовательности и в каком количестве понаставлено куча галок, да ещё и забыта половина. Это не работа.
 
 
#7
28.05.2015 16:11:45
Чтобы устранить проблему нужно сначала понять причину ее возникновения.
 
 
#8
28.05.2015 16:12:08
если уж "арка" с галками ничего не хочет делать по этому поводу: https://forum.quik.ru/messages/forum10/message4992/topic536/#message4992

в таком случае, моя задача обеспечить в своём скрипте, как говорится полны иммунитет от всех этих галочек. -> т.е. добится стабильности, вопреки.
 
 
#9
28.05.2015 16:13:44
если бы задача была такой просецкой - я бы наверно её здесь не приводил.
 
 
#10
28.05.2015 16:15:01
Цитата
Дмитрий пишет:
"Программа / Сохранение данных / Получать пропущенные данные" - галочка включена?
конкретно по этой "галке" - она у меня всегда включена.
 
 
#11
28.05.2015 16:17:16
 
 
#12
28.05.2015 16:18:05
 
 
#13
28.05.2015 16:18:35
Скорей всего изредка приходят опоздавшие обновления ТТП, в которых время или количество сделок отстали от текущих значений.
Попробуйте сделать проверку - если число сделок стало меньше, чем было в предыдущий раз, и время меньше предыдущего или равно ему - то просто не учитывайте пришедшие значения.
 
 
#14
28.05.2015 16:19:10
но мы отклонились:
Цитата
sam063rus пишет:
в общем, пока приходит на ум, что одно и з: "время" или "число сделок" - уже изменилось, а другое - соответственно - нет. В таком случае, как задать правильно условие (с учётом специфики OnParam)?
 
 
#15
28.05.2015 16:20:26
Цитата
Дмитрий пишет:
Скорей всего изредка приходят опоздавшие обновления ТТП, в которых время или количество сделок отстали от текущих значений.
Попробуйте сделать проверку - если число сделок стало меньше, чем было в предыдущий раз, и время меньше предыдущего или равно ему - то просто не учитывайте пришедшие значения.
ну в принципе и я о том же
 
 
#16
28.05.2015 16:22:08
Просто если бы та галка не была включена, то причина проблема скорей всего была бы в чем-то другом.
 
 
#17
28.05.2015 16:33:22
Цитата
sam063rus пишет:
но потом - "всё портится"
А в чём, собственно, выражается это "всё портится"?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#18
28.05.2015 16:38:08
пояявляются совершенно непонятые взятые "с потолка" отсчёты. Потом, вроде нормализуется, потом - опять.
 
 
#19
28.05.2015 16:40:03
загрузите скрипт - посмотрите. просто листинг здесь приводить - он получится длинным.
 
 
#20
28.05.2015 16:48:35
Приведите часть листинга с
Цитата
sam063rus пишет:
совершенно непонятые взятые "с потолка" отсчёты
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#21
28.05.2015 16:53:17
он выводится у меня в комбобоксе квика функцией: message

поэтому это малось проблематично.
 
 
#22
28.05.2015 16:56:19
"Сообщения / системные сообщения / таблица сообщений", которую можно сохранить в файл или вывести через ДДЕ в эксель
 
 
#23
28.05.2015 17:14:08
сами напросились:
Скрытый текст

Скрытый текст
 
 
#24
28.05.2015 17:15:24
Таблицу Всех Сделок - не привожу - она у вас и так есть. У себя - я её отфильтровал условным форматированием по: Бумага = SiM5
 
 
#25
28.05.2015 17:16:17
последняя редакция скрипта:
Скрытый текст
 
 
#26
28.05.2015 17:23:49
Надо найти отличия?
Цитата
sam063rus пишет:
сами напросились
sam063rus, вы одолжение нам делаете или что? Вы просили помощи. Так извольте привести необходимые данные.
Пока вопрос ваш не понятен.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#27
28.05.2015 17:24:20
как уже писал ранее - это всего лишь "винтик". никаким "граалем" тут и не пахнет.
Впоследствии, как удастся наладить стабильную реализацию с помощью коллбека - буду пытаться реализовать тоже самое без коллбеков. Что-нибудь на основе CreateDataSource etc.
 
 
#28
28.05.2015 17:26:05
Цитата
Старатель пишет:
Надо найти отличия?
Цитата
sam063rus пишет:
сами напросились
sam063rus , вы одолжение нам делаете или что? Вы просили помощи. Так извольте привести необходимые данные.
Пока вопрос ваш не понятен.
имелось ввиду, что проще было это всё смотреть и анализировать у себя в квике - на то скрипт и дан, а не через форум.
 
 
#29
28.05.2015 17:41:17
Цитата
sam063rus пишет:
имелось ввиду, что проще было это всё смотреть и анализировать у себя в квике - на то скрипт и дан, а не через форум.
Что анализировать-то? Вы можете привести листинг со строками, где "всё портится"?
Сидеть с запущенным скриптом перед терминалом и часами ждать неизвестно чего, как-то не хочется.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#30
28.05.2015 17:49:36
Что значит портится? Число сделок уменьшается? Или еще какие-то несоответствия, которые можно описать формально?
Тогда выведя в эксель таблицу, которую вы поместили тут в виде картинки, легко можно найти с помощью простой формулы среди множества строк именно те, где видна такая ситуация.
 
 
#31
28.05.2015 17:57:19
в разные промежутки времени, число сделок в ТВС и число сделок в скрипте - не соответствует по времени времени (ни на инкремент по времени ни на декремент)
 
 
#32
28.05.2015 18:04:31
Это нормально, т.к. в скрипте берутся данные из ТТП, а они представляют всего лишь временные срезы информации о числе сделок и прочих параметрах, которые формируются через определенные промежутки времени.
А сделки в ТВС поступают в отдельном потоке, никак не синхронизированном с потоком данных ТТП.
 
 
#33
28.05.2015 18:08:50
остаётся тогда вопрос: Как быть? :))
 
 
#34
28.05.2015 18:09:54
Цитата
Дмитрий пишет:
Это нормально, т.к. в скрипте берутся данные из ТТП, а они представляют всего лишь временные срезы информации о числе сделок и прочих параметрах, которые формируются через определенные промежутки времени.
А сделки в ТВС поступают в отдельном потоке, никак не синхронизированном с потоком данных ТТП.
с другой стороны, тут можно не согласиться - бо как за основу взято именно серверное время
 
 
#35
28.05.2015 18:11:50
Брать информацию либо из ТТП в OnParam, либо из ТВС в OnAllTrade
И не пытаться сопоставлять данные из этих двух источников, тем более на лету.
А если и сопоставлять, то сравнивать их с учетом какой-то заранее заданной допустимой погрешности.
 
 
#36
28.05.2015 18:14:00
чувствуется. что из всего форума к данной теме, интерес ограничивается только тремя людьми, - что печально. Хотя, анализ таких тонкостей позволил бы на порядок повысить понимание QLUA.
 
 
#37
28.05.2015 18:15:32
Цитата
Дмитрий пишет:
А если и сопоставлять, то сравнивать их с учетом какой-то заранее заданной допустимой погрешности.
пробовал и так и так (в предыдущих топиках).
насчётпогрешности - в корне не согласен - это живые деньги и они, как известно: любят счёт.
 
 
#38
28.05.2015 18:16:38
к тому же, интересует - именно "на лету", а не на истории.
 
 
#39
28.05.2015 18:18:18
Цитата
sam063rus пишет:
с другой стороны, тут можно не согласиться - бо как за основу взято именно серверное время
Данные для ТВС и для ТТП с одним и тем же серверным временем могут фактически прийти в терминал в разное время (думаю, рассогласование в секунду, а то и больше, тут не будет редкостью).
Можно пытаться сопоставлять эти данные уже потом, анализируя историю из ТВС и Таблицы изменений параметров, но все равно синхронизировать их будет весьма проблематично, т.к. время записей в Таблице изменений параметров приводится лишь с точностью до целой секунды.
С учетом этого, стоило бы наверное выразить пожелание, чтобы разработчики добавили ко времени записей в Таблице изменений параметров еще и милли- или даже микросекунды.
 
 
#40
28.05.2015 18:19:33
задам провокационный тогда вопрос: серверное время (время в поле "TIME" в ТТП) == биржевое (время заключения сделки)?
 
 
#41
28.05.2015 18:20:55
если "Да" - то, должна быть полная синхронизация по этому параметру между ТТП иТВС (бо как на самом деле - источник один - биржевой шлюз)
 
 
#42
28.05.2015 18:20:56
sam063rus, как я помню, в OnAllTrade вы считаете количество сделок за 1 секунду.
Здесь же вы считаете разницу между двумя неизвестными величинами
Код
act_numTrades - last_numTrades
где единственным условием является то, что, возможно, эти величины относятся к "временным срезам" на разных секундах.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#43
28.05.2015 18:24:33
Другими словами, между этими величинами не обязательно будеn разница ровно в 1 сек. И не обязательно они будут принадлежать к началу этих секунд, как вы делаете в OnAllTrade
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#44
28.05.2015 18:24:58
Цитата
Старатель пишет:
sam063rus , как я помню, в OnAllTrade вы считаете количество сделок за 1 секунду.
Здесь же вы считаете разницу между двумя неизвестными величинами
Код
 act_numTrades - last_numTrades
где единственным условием является то, что, возможно, эти величины относятся к "временным срезам" на разных секундах.
просто именно благодаря данной особенности ТТП - я нашёл решение, как попытаться уйти от тех проблем, которые у меня были с OnAllTrade (в ТТП - уже есть счётчик сделок - оставалось только воспользоваться предоставленной возможностью его опроса через фиксированный интервал)
 
 
#45
28.05.2015 18:26:57
Цитата
Старатель пишет:
Другими словами, между этими величинами не обязательно будеn разница ровно в 1 сек. И не обязательно они будут принадлежать к началу этих секунд, как вы делаете в OnAllTrade
будет ровно одна секунда - т.к. в рамках одного тикера - последовательность сохраняется (что ранее было уже проверено в другой теме)
 
 
#46
28.05.2015 18:29:51
скажу по другому, думаю, у меня бы вообще не возникло проблем, используй я и дальше OnAllTrade, если бы сделки на фортс были с микросекундной точностью
 
 
#47
28.05.2015 18:31:30
В любом случае, если у Вас (обращение ко всем пользователям) есть свои примеры кода, как можно сделать счётчик - буду искренне рад.
 
 
#48
28.05.2015 18:32:16
Цитата
sam063rus пишет:
задам провокационный тогда вопрос: серверное время (время в поле "TIME" в ТТП) == биржевое (время заключения сделки)?
Это время последней сделки. Наверняка, это время биржи.
 
 
#49
28.05.2015 18:33:33
Цитата
Дмитрий пишет:
Цитата
sam063rus пишет:
задам провокационный тогда вопрос: серверное время (время в поле "TIME" в ТТП) == биржевое (время заключения сделки)?
Это время последней сделки. Наверняка, это время биржи.
стало быть, сравнение ТВС иТТП по этому параметру имеет место быть.
 
 
#50
28.05.2015 18:34:42
код увидел.
Мне читать все топики лень, поэтому я выскажусь, возможно что кто-то уже это сказал.
1) Работа через onParam - самый плохой вариант. Там и хранилище очень тяжелое и данный колбек на каждый чих срабатывает
при этом если срез не пришел и не актуальный то он вообще потеряется.
Т е через этот колбек Вы обязательно недосчитаетесь сделок когда-нибудь
---------------------------------
2) Поэтому данную задачу полагаю надо решать через onAllTrade
По крайней мере решение через onAllTrade будет полным, но возможно что есть и более быстрое но не полное.
Поэтому  решение через onAllTrade должно быть базовым а остальные,
если они будут быстрее надо сравнивать с базовым.

--------------------------------
Поэтому предлагаю написать вариант через onAllTrade
и изложить претензии к такому решению (желательно с примерами)
 
 
Страницы: 1 2 3 4 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2025,
ARQA Technologies
Наверх