sam063rus пишет: 200 - откуда взялась эта цифра-коэффициент?
Я так полагаю, это округленное в большую сторону число рабочих часов в месяце (на самом деле в среднем их 175, а если учесть отпуск и праздники - то и вовсе 150). Причем в этой формуле еще не учтены налоги, взносы в пенсионный фонд и т.д. и т.п., а также расходы на постоянные или разовые услуги прочего персонала (бухгалтер, веб-дизайнер, менеджер по работе с клиентами (по рекламе) и т.д., да и руководителя (собственника фирмы) не надо забывать). Если речь идет о более-менее нормальной фирме, пусть небольшой, но выплачивающей "белую" зарплату - то цену, посчитанную по приведенной Николаем Камыниным формуле, можно смело умножать на 2.
Это как в тарифах пишут: типа столько-то % от оборота, но не менее Х рублей. Отсюда делаем вывод: по оценке sam063rus робот стоит 10 000 руб. :) Наглядная иллюстрация широко распространенного психологического явления: когда платишь некую сумму кому-то за работу - цена кажется неоправданно большой, а когда тебе предлагают сделать эту работу самому за ту же цену - стимула работать нет.
Sergey77 пишет: Подскажите,пожалуйста, можно ли в Quik сформировать такую заявку: Если цена акции Газпрома упадет ниже цены Х, то выставляй заявку на продажу фьючерса Газпром по цене Y
Можно - стоп-заявка типа "стоп-цена по другой бумаге"
Дмитрий пишет: Заметил также еще одну особенность работы функций SetValue и SetRangeValue - если с их помощью установить значения индикатора (индикатор рисовал в отдельном окне), которые выходят за границы минимальных/максимальных значений индикатора, установленных ранее с помощью return в OnCalculate, то новые значения в итоге не видны, так как оказываются за границами окна (автомасштабирование на такую смену значений индикатора не реагирует).
Здравствуйте! Удалось ли воспроизвести проблему с помощью приведенного мною скрипта?
Viktor MMM пишет: Вопрос, как в указанном выше скрипте добавить исполнение chcp 861? Чтоб не новая "сессия" командной строки начиналась, а в составе той, что с пингом?
sam063rus пишет: Если дата последних торгов по инструменту не является датой последней сделки - то, что тогда является?
Совсем не обязательно должны быть сделки, если по инструменту были торги. На низколиквидных инструментах сделки могут совершаться далеко не каждый торговый день.
сергей пишет: Если речь про мамбу, то если мне не изменяет память - volume на графиках показывает лоты...отсюда эти параметры равны при лот=1 бумага. Могу ошибаться.
Но если у Вас есть большое желание получать на вялом рынке счетчик сделок без задержки, то OnParam в таком случае будет более полезен, благодаря тому, что он срабатывает не только на сделки, но и на изменение еще множества параметров. Однако, тогда встанет проблема с точностью вычислений.
sam063rus пишет: То есть, нужны мгновенные выборки (число сделок в секунду) с дискретностью 1 сек.
Это гораздо более сложная задача. С использованием только OnAllTrade или OnParam ее не решить, т.к. они срабатывают не по расписанию. Я бы не стал заморачиваться ее решением, так как на мой взгляд, нет ничего страшного, если при очень низкой активности на рынке мы получим с запозданием данные за последнюю секунду, в которой еще были сделки перед полным затишьем (мы можем просто их проигнорировать или усреднить).
Цитата
sam063rus пишет: задача бы значительно упростилась, имей мы коллбек: OnServerTime
Не думаю, так как время поступающих в терминал сделок отличается от времени сервера (они всегда запаздывают, больше или меньше). Да и время сервера может не полностью совпадать со временем биржи, которое содержится в информации о сделке.
Дмитрий пишет: Если не делить число сделок на число секунд и не выводить нули когда сделок не было, то индикатор будет запаздывать при низкой активности торгов.
То есть фактически выдавать недостоверные данные. К примеру за 1 секунду у нас было 10 сделок, а потом 5 секунд сделок не было вообще. Скрипт узнает о том, что 1-я секунда закончилась, только после прихода новой сделки (на 7-й секунде). Если выдать при этом просто число сделок, не поставив нули за последние 5 секунд (или не поделив число сделок на число секунд), то будет впечатление, будто 10 сделок пришли не 6 секунд назад, а буквально только что.
Проблема в том, что если сделки происходят редко, то интервал между срабатываниями OnAllTrade может превышать 1 секунду. В таком случае, если при очередном срабатывании OnAllTrade будет обнаружено, что с момента ее предыдущего вызова прошло больше секунды, то число сделок будет разделено на число секунд и получено среднее значение. Либо можете не делить это значение и не получать среднее, а считать, что в первую секунду прошли все сделки (как и есть на самом деле), а в остальные - 0
Впрочем, ТВС в файл выгружать не обязательно, можно сразу обработать ее своим скриптом. И потом Вы ведь как-то поняли, что Ваш скрипт выдавал неадекватные данные. Значит, есть возможность проверить.
Например, сохранить в файл данные, которые он вычисляет. В конце дня выгрузить таблицу всех сделок в другой файл, обработать его своим скриптом и сравнить результаты.
Вот пример простого скрипта, который будет считать количество сделок в секунду по заданному классу (точней, сумму сделок за секунду по всем инструментам этого класса, по которым в терминал поступают обезличенные сделки). При этом архивные сделки по какому-то дополнительно добавленному в ТВС (уже после начала торгов) инструменту из того же класса не исказят текущую статистику. В лог пишутся те сделки, которые могли бы нарушить нормальный ход подсчетов. Если таковые обнаружатся, то интересно посмотреть, что это за сделки...
Код
local file = io.open("C:\\TEST\\Log.txt", "w+t")
local cur_day = getTradeDate().day
local last_time = 0
local count = 0
function OnAllTrade(tr)
if tr.class_code == "SPBFUT" then
if tr.datetime.day == cur_day then
local time = tr.datetime.hour * 3600 + tr.datetime.min * 60 + tr.datetime.sec
if time == last_time then
count = count + 1
elseif time > last_time then
message(tostring(count/(time-last_time))) -- делим на число секунд (на случай, если сделки совершаются редко)
count = 1
last_time = time
else -- (time < last_time) - скорей всего закачка истории сделок по вновь добавленному в ТВС инструменту
file:write(tr.class_code," ",tr.sec_code," ",tr.trade_num," ",tr.datetime.hour,":",tr.datetime.min,":",tr.datetime.sec,".",tr.datetime.mcs,"\n")
end
else
file:write("Пришла вчерашняя сделка - ", tr.trade_num, "\n")
end
end
end
local not_stopped = true
function OnStop(stop_flag)
not_stopped = false
end
function main()
while not_stopped do
sleep(1000)
end
file:close()
end
sam063rus пишет: хотелось бы уже подытожить: то, считалось, что OnAllTrade даёт более быстрый и достоверный результат то, OnParam. На старом форуме - OnParam. На этом форуме - не менее "жарче" разгорелись мнения за OnAllTrade и в итоге - всё-равно OnParam. Так курица или яйцо???
Может, OnParam будет и быстрей немного, но однозначно OnAllTrade будет давать более точные результаты.
Цитата
sam063rus пишет: я так и не понял в таком случае, что такое "срез"
sam063rus пишет: в общем, задача сводится к тривиальной: отправка ICQ-сообщений по интернет с помощью соответствующего бесплатного API. Вот вам и аналог смс-оповещений))))
А если интернет на машине с терминалом отвалился? Как узнаете об этом прискорбном факте? Наверное, хотя бы на такие случаи стоит прицепить еще и телефон или модем для отправки смс.
Кстати, не только сделки, но и обновления ТТП и стаканов тоже пачками приходят, по-моему. А формируются такие пачки, возможно, потому что терминал получает с сервера только изменения параметров или только сделки или только обновления стаканов до тех пор, пока очередь с накопившимися данными одного типа на сервере не опустеет. Только после этого терминал, наверное, переходит к обработке данных другого типа.
Egor Zaytsev пишет: Приоритет получения данных выглядит следующим образом:
- таблица котировок, - далее таблица текущих параметров - таблица всех сделок, - графики.
А вот это, похоже, уже не соответствует сказанному техподдержкой:
Цитата
Старатель пишет: И в сравнении с OnQuote ТТП даёт информацию об изменении лучших спроса и предложения чаще и раньше.
Хотелось бы понять почему... Может неправильно тестировали? Или все же техподдержка ошиблась? А может получается раньше потому что чаще...? Хотя насчет подсчета частоты хочу отметить, что сравнивать частоту обновлений стакана и ТТП по перечисленным параметрам не совсем корректно, т.к. 'BIDDEPTHT' и 'OFFERDEPTHT' отражают общий спрос и предложение, изменение которых может происходить и при неизменном стакане (т.к. стакан нам показывает не все заявки).
Старатель пишет: Получается "пачки" OnAllTrade приходят даже реже, чем обновления в ТТП по параметру "NUMTRADES".
А может картину искажает слишком большое время, заданное для разделения колбэков между пачками? И в итоге за этот интервал времени успевают на самом деле прийти две пачки или даже больше. Думаю, колбэки OnAllTrade правильней делить на пачки не по времени между ними (или не только по времени), а еще проверяя, не срабатывали ли между ними колбэки другого типа (OnParam и OnQuote).
По-моему, задача вполне решаема, именно с использованием OnAllTrade. Округление до миллисекунд не критично - если и даст погрешность, то незначительную.
sam063rus пишет: по нормальному - должна при каждорй сделке - т.к. сделка - это уже существенный факт.
В свое время разработчики решили иначе :) Насколько я понимаю, обновление ТТП происходит через определенные интервалы времени, независимо от частоты изменения тех или иных параметров. Таков принцип работы квика с ТТП.
sam063rus пишет: я не спорю - осталось дождаться "официального подтверждения" и пусть укажут в документации (зарегистрируют очередное пожелание), что по факту полагаться на коллбеки OnParam однозначно нестоит бо как они не учитывают все изменения
Если поискать на форуме, то по-моему уже найдется немало указаний на это, в том числе и официальных.
Старатель пишет: Написал тестовый скрипт для подсчёта общего количества сделокпо колбекам OnAllTrade и OnParam Результаты на демо-сервере по SBER:
Даже на демо-сервере видно, что число коллбэков по изменению ТТП меньше, чем по приходу новой сделки (при том что там еще не все колбэки OnAllTrade посчитаны, т.е. не учтены идущие подряд с минимальным интервалом). Это иллюстрация к моему предыдущему сообщению. Думаю, на боевом сервере в самый разгар торгов разница будет еще больше.
sam063rus пишет: Так о каких тогда срезах можно говорить?
на бирже были три сделки подряд все три придут в ТВС а обновлений ТТП за это время может прийти, например, только два (а то и меньше), так как они происходят только с определенной периодичностью в первом обновлении ТТП будет указано число сделок 1 и время 1-й сделки во втором - число сделок 3 и время 3-й сделки
sam063rus пишет: повторюсь - мой скрипт вполне даже себе уверенно и правильно считает. местами... )) потом - хреново считает (такое ощущение, что идёт прогрузка данных)
Имеется в виду который считает по AllTrade, и только по одному инструменту?
Цитата
sam063rus пишет: что мне надо: количество сделок в секунду.
По одному инструменту или по классу или на одной секции биржи?
sam063rus пишет: тут мы опять имеем "галки" - для моей задачи - это неприемлемо.
Я описал, как сделать, чтобы наличие или отсутствие галки не влияло на работу скрипта:
Цитата
sam063rus пишет: При этом надо запоминать время самой последней сделки из этой секции биржи и если придет сделка с более ранним временем с той же секции, то просто игнорировать ее
Пример кода сейчас писать некогда, но для OnAllTrade могу сказать, что в пределах одной торговой площадки там сделки поступают строго в порядке увеличения времени, поэтому считать можно по ним. При этом надо запоминать время самой последней сделки из этой секции биржи и если придет сделка с более ранним временем с той же секции, то просто игнорировать ее (такое может быть если не включена галка "получать информацию по всем сделкам с текущего момента" и сделки по какому-то инструменту были заказаны спустя какое-то время после начала торгов - тогда сначала придут все сделки по этому инструменту, совершенные с начала торгов до текущего момента).