Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями: {year, month, day, week_day, hour, min, sec, ms, count} Где:
count – количество тиковых интервалов в секунду. Может принимать значения от «1» до «10000» включительно.
Нельзя ли чуточку поподробнее про параметр count? Неясен его смысл.
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 31.01.2015
03.02.2015 22:44:25
Кстати, у меня тоже вопрос на эту тему, к разработчикам. Насколько я понял, график за текущий день (любой, кроме тикового) строится по данным, поступающим в ТТП. А там время записей указывается с точностью до целой секунды, миллисекунд там нет (в отличие от записей из таблицы всех сделок, по которой строится исключительно тиковый график). В таком случае откуда берется значение ms для времени свечи?
Пользователь
Сообщений: Регистрация: 30.01.2015
04.02.2015 06:55:55
Цитата
s_mike@rambler.ru пишет: count – количество тиковых интервалов в секунду.
Раньше, когда наводишь на свечу тикового графика была приписка в поле со временем 001, 002, 003....Я посчитал это за мс., а оказалось номер тика в секундном интервале...если за секунду их было пять соответственно на последнем тике было 005. Думаю где-то здесь ответ и есть.
Пользователь
Сообщений: Регистрация: 30.01.2015
04.02.2015 06:58:09
Цитата
Дмитрий пишет: Кстати, у меня тоже вопрос на эту тему, к разработчикам. Насколько я понял, график за текущий день (любой, кроме тикового) строится по данным, поступающим в ТТП. А там время записей указывается с точностью до целой секунды, миллисекунд там нет (в отличие от записей из таблицы всех сделок, по которой строится исключительно тиковый график). В таком случае откуда берется значение ms для времени свечи?
Все графики строятся на основании тикового, т.к. ТТП поступает срезами и экстремумы могут быть пропущены.
Пользователь
Сообщений: Регистрация: 31.01.2015
04.02.2015 10:32:57
Цитата
сергей пишет: Все графики строятся на основании тикового, т.к. ТТП поступает срезами и экстремумы могут быть пропущены.
А если у меня отключен заказ всех сделок, то как они будут построены на основании тикового? Без заказа всех сделок тиковый график не построить. А в пользу того, что графики за текущий день строятся на основе данных из ТТП, свидетельствует тот факт, что если по окончании торгов перезапустить терминал в режиме оффлайн, предварительно удалив info.log, то за текущий день графики пропадут. В файле info.log хранятся данные из ТТП, а тиковые данные (все сделки) - в alltrade.dat.
Пользователь
Сообщений: Регистрация: 30.01.2015
04.02.2015 10:40:56
Графики шлёт сервер... не ищите чёрную кошку...она ведь не нужна Вам
сергей пишет: Все графики строятся на основании тикового, т.к. ТТП поступает срезами и экстремумы могут быть пропущены.
А если у меня отключен заказ всех сделок, то как они будут построены на основании тикового? Без заказа всех сделок тиковый график не построить. А в пользу того, что графики за текущий день строятся на основе данных из ТТП, свидетельствует тот факт, что если по окончании торгов перезапустить терминал в режиме оффлайн, предварительно удалив info.log, то за текущий день графики пропадут. В файле info.log хранятся данные из ТТП, а тиковые данные (все сделки) - в alltrade.dat.
Добрый день.
Дмитрий, графики строятся сервером на основании таблицы всех сделок. Сервер же и рассылает графики на клиентские места. Тиковые же графики строятся исключительно по таблице всех сделок из терминала (таблицы всех сделок)
Пользователь
Сообщений: Регистрация: 30.01.2015
04.02.2015 12:50:18
А можно ли вернуться к первому посту этой ветки?
Все-таки очень интересно, что такое count в функции Т()
s_mike@rambler.ru пишет: А можно ли вернуться к первому посту этой ветки?
Все-таки очень интересно, что такое count в функции Т()
Добрый день. Это сделано для того, чтобы различать тики пришедшие с одинаковой меткой времени. Нумеруются терминалом в порядке получения.
То есть тики с одинаковыми миллисекундами будут иметь возрастающий count.
Спасибо.
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 14.02.2015
23.02.2015 15:20:34
Коллеги, позвольте продолжить тему...
У разных источников данных (для разных параметров) в одну и туже секунду может быть разное кол-во тиков (count). Поэтому возникает проблема, как можно синхронизировать значения разных параметров?
Например: voltoday имеет всегда большее кол-во тиков в сек, нежели numcontracts. И определить какому значению voltoday на определенный тик соответствует какое значение numcontracts - ума не приложу как.
Может кто решал уже такую задачу?
Пользователь
Сообщений: Регистрация: 31.01.2015
23.02.2015 15:34:14
Вы далеко не первый, кто задумывался над этим вопросом:
К сожалению, на сегодняшний день средств для решения описанной Вами задачи не существует.
Пользователь
Сообщений: Регистрация: 14.02.2015
23.02.2015 15:47:25
Эх. Пичалька сплошная :) Будем надеяться, что разработчики Квика нас услышат, ибо доработка совсем простая нужна...
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.02.2015 17:27:35
Цитата
latrop1 пишет: У разных источников данных (для разных параметров) в одну и туже секунду может быть разное кол-во тиков (count). Поэтому возникает проблема, как можно синхронизировать значения разных параметров?
Например: voltoday имеет всегда большее кол-во тиков в сек, нежели numcontracts. И определить какому значению voltoday на определенный тик соответствует какое значение numcontracts - ума не приложу как.
Я не решал подобных задач, но полагаю, что для тех параметров, которые изменяются реже одного раза в мс (а это все параметры из ТТП), можно построить таблицу соответствий вида:
Код
{par1_i, par2_i},
где par1_i, par2_i - значение каждого параметра, синхронизированные по значению ms, как заполняется Таблица изменений параметров:
Цитата
Sergey Gorokhov пишет: Просто дизайн таблицы изменений заполняет пропуски копируя последнее изменение, в случае если в таблице несколько параметров.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 31.01.2015
23.02.2015 18:03:35
Цитата
Серж пишет: Я не решал подобных задач, но полагаю, что для тех параметров, которые изменяются реже одного раза в мс (а это все параметры из ТТП), можно построить таблицу соответствий вида:
Код
{par1_i, par2_i},
где par1_i, par2_i - значение каждого параметра, синхронизированные по значению ms
К сожалению, этого сделать не получится, так как в ТТП время записей приведено с точностью до целых секунд. Миллисекунд там нет. Кстати, видел, что разработчики не так давно писали (еще на старом форуме) о том, что биржа теперь может транслировать миллисекунды для ТТП по инструментам с рынка FORTS. Однако разработчики пока еще не решились добавить этот параметр в ТТП.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.02.2015 18:23:38
Цитата
Дмитрий пишет: К сожалению, этого сделать не получится, так как в ТТП время записей приведено с точностью до целых секунд. Миллисекунд там нет.
Вот, правда, не проверял, что там возвращается, но из документации к v.6.16.1.15:
Цитата
s_mike@rambler.ru пишет: Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями: {year, month, day, week_day, hour, min, sec, ms, count}
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 31.01.2015
23.02.2015 18:27:48
Для всех параметров ТТП ms всегда будет равно 0.
Пользователь
Сообщений: Регистрация: 31.01.2015
23.02.2015 19:29:22
Вообще интересно, как именно, то есть на основе каких данных разработчики строят в терминале Таблицу изменений параметров. Возможно, что в базе данных терминала все-таки хранится порядковый номер в пределах одной секунды того момента времени (временного среза), когда было получено изменение того или иного параметра, относящегося к любому инструменту (из числа тех, по которым в терминал поступают изменения параметров). Но тогда непонятно, почему нельзя было предоставить возможность получать значение этого номера с помощью QLua. Поэтому у меня даже возникли сомнения в том, можно ли полностью доверять той информации, которая отображается в Таблице изменений параметров. Хотя не исключено, что эта таблица строится как-то иначе, без использования подобных номеров. В связи с этим хотелось бы услышать от разработчиков, хотя бы вкратце, как же именно реализовано построение Таблицы изменений параметров в терминале.
Пользователь
Сообщений: Регистрация: 30.04.2015
30.04.2015 07:13:47
Никак. Подозреваю, что таблица приходит полными строками, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными. А басни про отсутствие "лишних" данных и настройки QUIK - это для понтов.
