T()

Страницы: 1
RSS
T()
 
T()

Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями:
{year, month, day, week_day, hour, min, sec, ms, count}
Где:
  • count – количество тиковых интервалов в секунду. Может принимать значения от «1» до «10000» включительно.
Нельзя ли чуточку поподробнее про параметр count? Неясен его смысл.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Кстати, у меня тоже вопрос на эту тему, к разработчикам.
Насколько я понял, график за текущий день (любой, кроме тикового) строится по данным, поступающим в ТТП.
А там время записей указывается с точностью до целой секунды, миллисекунд там нет (в отличие от записей из таблицы всех сделок, по которой строится исключительно тиковый график).
В таком случае откуда берется значение ms для времени свечи?
 
Цитата
s_mike@rambler.ru пишет:
count – количество тиковых интервалов в секунду.
Раньше, когда наводишь на свечу тикового графика была приписка в поле со временем 001, 002, 003....Я посчитал это за мс., а оказалось номер тика в секундном интервале...если за секунду их было пять соответственно на последнем тике было 005.
Думаю где-то здесь ответ и есть.
 
Цитата
Дмитрий пишет:
Кстати, у меня тоже вопрос на эту тему, к разработчикам.
Насколько я понял, график за текущий день (любой, кроме тикового) строится по данным, поступающим в ТТП.
А там время записей указывается с точностью до целой секунды, миллисекунд там нет (в отличие от записей из таблицы всех сделок, по которой строится исключительно тиковый график).
В таком случае откуда берется значение ms для времени свечи?
Все графики строятся на основании тикового, т.к. ТТП поступает срезами и экстремумы могут быть пропущены.
 
Цитата
сергей пишет:
Все графики строятся на основании тикового, т.к. ТТП поступает срезами и экстремумы могут быть пропущены.
А если у меня отключен заказ всех сделок, то как они будут построены на основании тикового? Без заказа всех сделок тиковый график не построить.
А в пользу того, что графики за текущий день строятся на основе данных из ТТП, свидетельствует тот факт, что если по окончании торгов перезапустить терминал в режиме оффлайн, предварительно удалив info.log, то за текущий день графики пропадут.
В файле info.log хранятся данные из ТТП, а тиковые данные (все сделки) - в alltrade.dat.
 
Графики шлёт сервер...
не ищите чёрную кошку...она ведь не нужна Вам
 
Цитата
Дмитрий пишет:
Цитата
сергей пишет:
Все графики строятся на основании тикового, т.к. ТТП поступает срезами и экстремумы могут быть пропущены.
А если у меня отключен заказ всех сделок, то как они будут построены на основании тикового? Без заказа всех сделок тиковый график не построить.
А в пользу того, что графики за текущий день строятся на основе данных из ТТП, свидетельствует тот факт, что если по окончании торгов перезапустить терминал в режиме оффлайн, предварительно удалив info.log, то за текущий день графики пропадут.
В файле info.log хранятся данные из ТТП, а тиковые данные (все сделки) - в alltrade.dat.
Добрый день.

Дмитрий, графики строятся сервером на основании таблицы всех сделок. Сервер же и рассылает графики на клиентские места. Тиковые же графики строятся исключительно по таблице всех сделок из терминала (таблицы всех сделок)
 
А можно ли вернуться к первому посту этой ветки?

Все-таки очень интересно, что такое count в функции Т()
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
s_mike@rambler.ru,

Поле count необходимо для корректного собирания истории изменений параметра на тиковом интервале.
 
Цитата
s_mike@rambler.ru пишет:
А можно ли вернуться к первому посту этой ветки?

Все-таки очень интересно, что такое count в функции Т()
Добрый день.
Это сделано для того, чтобы различать тики пришедшие с одинаковой меткой времени. Нумеруются терминалом в порядке получения.
 
Цитата
Michael Bulychev пишет:
Цитата
s_mike@rambler.ru пишет:
А можно ли вернуться к первому посту этой ветки?

Все-таки очень интересно, что такое count в функции Т()
Добрый день.
Это сделано для того, чтобы различать тики пришедшие с одинаковой меткой времени. Нумеруются терминалом в порядке получения.
То есть тики с одинаковыми миллисекундами будут иметь возрастающий count.

Спасибо.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Коллеги, позвольте продолжить тему...

У разных источников данных (для разных параметров) в одну и туже секунду может быть разное кол-во тиков (count).
Поэтому возникает проблема, как можно синхронизировать значения разных параметров?

Например: voltoday имеет всегда большее кол-во тиков в сек, нежели numcontracts.
И определить какому значению voltoday на определенный тик соответствует какое значение numcontracts - ума не приложу как.

Может кто решал уже такую задачу?
 
Вы далеко не первый, кто задумывался над этим вопросом:
http://forum-archive.quik.ru/forum/lua/113078
http://forum.quik.ru/forum10/topic110/
К сожалению, на сегодняшний день средств для решения описанной Вами задачи не существует.
 
Эх. Пичалька сплошная :)
Будем надеяться, что разработчики Квика нас услышат, ибо доработка совсем простая нужна...
 
Цитата
latrop1 пишет:
У разных источников данных (для разных параметров) в одну и туже секунду может быть разное кол-во тиков (count).
Поэтому возникает проблема, как можно синхронизировать значения разных параметров?

Например: voltoday имеет всегда большее кол-во тиков в сек, нежели numcontracts.
И определить какому значению voltoday на определенный тик соответствует какое значение numcontracts - ума не приложу как.
Я не решал подобных задач, но полагаю, что для тех параметров, которые изменяются реже одного раза в мс (а это все параметры из ТТП), можно построить таблицу соответствий вида:
Код
{par1_i, par2_i},
где par1_i, par2_i - значение каждого параметра, синхронизированные по значению ms, как заполняется Таблица изменений параметров:
Цитата
Sergey Gorokhov пишет:
Просто дизайн таблицы изменений заполняет пропуски копируя последнее изменение, в случае если в таблице несколько параметров.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Серж пишет:
Я не решал подобных задач, но полагаю, что для тех параметров, которые изменяются реже одного раза в мс (а это все параметры из ТТП), можно построить таблицу соответствий вида:
Код
 {par1_i, par2_i}, 
где par1_i, par2_i - значение каждого параметра, синхронизированные по значению ms
К сожалению, этого сделать не получится, так как в ТТП время записей приведено с точностью до целых секунд. Миллисекунд там нет.
Кстати, видел, что разработчики не так давно писали (еще на старом форуме) о том, что биржа теперь может транслировать миллисекунды для ТТП по инструментам с рынка FORTS. Однако разработчики пока еще не решились добавить этот параметр в ТТП.
 
Цитата
Дмитрий пишет:
К сожалению, этого сделать не получится, так как в ТТП время записей приведено с точностью до целых секунд. Миллисекунд там нет.
Вот, правда, не проверял, что там возвращается, но из документации к v.6.16.1.15:
Цитата
s_mike@rambler.ru пишет:
Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями:
{year, month, day, week_day, hour, min, sec, ms, count}
Надо делать так, как надо. А как не надо - делать не надо.
 
Для всех параметров ТТП ms всегда будет равно 0.
 
Вообще интересно, как именно, то есть на основе каких данных разработчики строят в терминале Таблицу изменений параметров.
Возможно, что в базе данных терминала все-таки хранится порядковый номер в пределах одной секунды того момента времени (временного среза), когда было получено изменение того или иного параметра, относящегося к любому инструменту (из числа тех, по которым в терминал поступают изменения параметров). Но тогда непонятно, почему нельзя было предоставить возможность получать значение этого номера с помощью QLua.
Поэтому у меня даже возникли сомнения в том, можно ли полностью доверять той информации, которая отображается в Таблице изменений параметров. Хотя не исключено, что эта таблица строится как-то иначе, без использования подобных номеров.
В связи с этим хотелось бы услышать от разработчиков, хотя бы вкратце, как же именно реализовано построение Таблицы изменений параметров в терминале.
 
Никак.
Подозреваю, что таблица приходит полными строками, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными.
А басни про отсутствие "лишних" данных и настройки QUIK - это для понтов.
 
PS. https://forum.quik.ru/messages/forum10/message4000/topic444/?result=reply#message4000
Страницы: 1
Читают тему
Наверх