доступ к строкам таблицы изменений параметров

Страницы: 1 2 След.
RSS
доступ к строкам таблицы изменений параметров, почему его нет?
 
Здравствуйте!
Уважаемые разработчики, ответьте, пожалуйста, на вопрос:
Почему с помощью функции getItem невозможно делать выборку данных из таблицы изменений параметров?
В чем ее принципиальное отличие от других таблиц?
В том числе от таблицы обезличенных (всех) сделок, к которой можно обращаться с помощью данной функции.
 
Здравствуйте,
Именно для таблицы изменений параметров нет доступа через getItem по техническим причинам.
 
Тогда следующий вопрос:
Почему когда я строю в терминале график по значению некоторого параметра из ТТП или получаю данные с помощью скрипта посредством функции CreateDataSource, то выводятся не все полученные с сервера значения параметра, а только те, которые отличаются от предыдущего значения.

Поясню на примере, который наблюдаю прямо сейчас.
Вот данные, полученные в терминале копированием содержимого таблицы изменений параметров:
TIME bid offer
10:00:00      65,466      66,46
10:00:00      65,466 66,1
10:00:00 65,467 66,1
10:00:00 65,467 65,85
10:00:00 65,65  65,85

А вот что выдается на графиках:

TIME count bid
10:00:00 1 65.466
10:00:00 2 65.467
10:00:00 3 65.65

TIME count offer
10:00:00 1 66.46
10:00:00 2 66.1
10:00:00 3 65.85
 
На тиковых проверяете? Если да то должны отображаться все изменения. Может изменений просто не было?
 
Чтобы проверить, постройте таблицу изменений только по одному параметру. То есть чтобы был только offer
 
То есть, как я понимаю, из скрипта на QLua можно получить доступ к данным таблицы изменений параметров только путем использования функции CreateDataSource.
Но получается, что последовательное использование этой функции для каждого из нужных нам параметров (то есть колонок этой таблицы) все равно не позволит нам получить в итоге все ее строки, которые мы видим в терминале.
 
Да, по одному параметру все совпадает.
 
Цитата
Дмитрий пишет:
То есть, как я понимаю, из скрипта на QLua можно получить доступ к данным таблицы изменений параметров только путем использования функции CreateDataSource.
Да, и еще через графики функцией getCandlesByIndex
Цитата
Дмитрий пишет:
Но получается, что последовательное использование этой функции для каждого из нужных нам параметров (то есть колонок этой таблицы) все равно не позволит нам получить в итоге все ее строки, которые мы видим в терминале.
Нет это не так. Вы можете получить доступ ко всем имеющимся изменениям. Просто дизайн таблицы изменений заполняет пропуски копируя последнее изменение, в случае если в таблице несколько параметров.
Постройте две таблице. в одной bid и offer а во второй только offer и Вы сами это увидите. В этом смысле, можно говорить ,что функции getCandlesByIndex и CreateDataSource даже надежней использовать чем таблицу изменений, так как там нет несуществующих изменений а только фактические.
 
Тогда следующий вопрос - а если мне нужно получить такую же картину изменения спреда между Bid и Offer, которую я вижу в терминале в таблице с двумя колонками (где мы видели 5 строк), то как мне ее построить самому, если порознь по обоим параметрам мне выдается только 3 строки, имеющие одинаковое время и одинаковое же значение count?
 
Именно с помощью count и можно это реализовать. Даже более того мы его добавили специально для этого.
Но порозень должны быть разные count если это не так то баг или описание проблемы понято не правильно.
 
В предыдущих постах видим что count все же разный. Значит все в порядке.
сгруппировать значения нужно по такой схеме
1 1
1 2
2 2
2 3
3 3
3 4
4 4
4 5
и т.д пока не кончится секунда,
 
А где вы увидели значения count 4 и 5?
Они на графиках по каждому из параметров меняются только от 1 до 3.
О существовании еще двух сочетаний bid и offer, то есть еще двух значений спреда, я никак узнать не могу в данном случае.
 
Цитата
Дмитрий пишет:
А где вы увидели значения count 4 и 5?
нигде, я просто описал алгоритм. с таким же успехом я мог бы дописать до 10000 (макс значение count)
Цитата
Дмитрий пишет:
Они на графиках по каждому из параметров меняются только от 1 до 3.
значит за секунду было максимум три изменения. К стати ТТП обновляется срезами данных а не льет информацию сплошным потоком. И эта частота настраивается на стороне брокера.
 
Согласен, 3 изменения по каждому из параметров, но в разное время. В итоге спред между bid и offer менялся 5 раз (если верить тому, что мы видим в самой таблице изменений параметров).
 
хорошо хорошо, специально для Вас данные должны быть сгруппированы в следующем порядке
1 1
1 2
2 2
2 3
3 3
 
Это Вы написали, так как видели результат вывода в таблице изменений параметров, который я привел в начале.
А если бы Вы не видели эту таблицу, то как Вы догадались бы о том, что их нужно сопоставлять именно в таком порядке? И вообще о том, что изменений спреда было 5, а не 3 или 4?
 
Дмитрий,
Да Вы правы. Боюсь что имеющимися средствами построить таблицу истории из двух и более параметров никак не получится.
 
Добрый день!
А есть ли возможность в одном из следующих обновлений программы исправить эту ситуацию?
Например, сделать так чтобы значение count отражало не порядковый номер изменения отдельно взятого параметра в пределах секунды, а порядковый номер временного среза в пределах одной секунды, во время которого было получено изменение данного параметра?
Тогда в данном примере значения count были бы следующими (если таких временных срезов было всего 5):
TIME count bid
10:00:00 1 65.466
10:00:00 3 65.467
10:00:00 5     65.65
TIME count offer
10:00:00 1 66.46
10:00:00 2 66.1
10:00:00 4     65.85
В итоге задача построения таблицы изменений параметров по этим данным стала бы решаемой.
Под временным срезом имеется в виду порядковый номер в пределах одной секунды того момента времени, когда было получено изменение любого из параметров, относящихся к данному инструменту (или вообще к любому инструменту, по которым в терминал поступают изменения параметров).
 
А не проще данные брать из стакана? Тогда у вас всегда будет пара bid-offer
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Серж пишет:
А не проще данные брать из стакана? Тогда у вас всегда будет пара bid-offer
1) Я привел здесь пару bid-offer только в качестве примера. На самом деле проблема касается получения любого набора параметров.
2) История изменения стакана в терминале не сохраняется (поправьте меня, если я ошибаюсь).
3) Предлагаемый Вами вариант предполагает необходимость на протяжении всего торгового дня держать терминал работающим для ловли и сохранения данных в режиме онлайн, а это не всегда возможно.
 
Цитата
Sergey Gorokhov пишет:
Дмитрий ,
Да Вы правы. Боюсь что имеющимися средствами построить таблицу истории из двух и более параметров никак не получится.
Присоединяюсь к топик-стартеру.
Возможно ли доработать Квик для решения данной проблемы?
Примите заявку, пож-та, т.к. очевидно, что имеющимися средствами проблему сопоставления разных параметров качественно никак не решить.
 
Здравствуйте!

Ваше пожелание зарегистрировано, будет рассмотрено и, возможно, реализовано в одной из следующих версий нашего ПО.
 
Большое спасибо.

А как скоро можно ожидать результата рассмотрения?
 
Цитата
latrop1 пишет:
Большое спасибо.

А как скоро можно ожидать результата рассмотрения?
Сроки не определены
http://www.quik.ru/user/faq/wish-list/
 
Цитата
Дмитрий пишет:
... сделать так чтобы значение count отражало не порядковый номер изменения отдельно взятого параметра в пределах секунды, а порядковый номер временного среза в пределах одной секунды, во время которого было получено изменение данного параметра ...
В итоге задача построения таблицы изменений параметров по этим данным стала бы решаемой.
Под временным срезом имеется в виду порядковый номер в пределах одной секунды того момента времени, когда было получено изменение любого из параметров, относящихся к данному инструменту (или вообще к любому инструменту, по которым в терминал поступают изменения параметров).
Лучше реализовать вариант, выделенный жирным шрифтом, так как иначе не получится построить корректную таблицу изменений параметров, содержащую данные одновременно по нескольким инструментам.
 
Здравствуйте!

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
 
Здравствуйте!

Просьба переквалифицировать доработку в ошибку и исправить в приоритетном порядке.
Детали (простите за дубляж):
https://forum.quik.ru/forum10/topic444/

Сообщите, пож-та, о принятом решении.
 
Цитата
latrop1 пишет:
Здравствуйте!

Просьба переквалифицировать доработку в ошибку и исправить в приоритетном порядке.
Детали (простите за дубляж):
https://forum.quik.ru/forum10/topic444/

Сообщите, пож-та, о принятом решении.
Добрый день.

Можете выложить Ваш код на котором воспроизводится проблема.
 
Цитата
Egor Zaytsev пишет:
Можете выложить Ваш код на котором воспроизводится проблема.
Добрый день!
Неужели вы хотите поставить под сомнение факт существования данной проблемы?
Как видно из всего написанного выше в данной ветке, проблему легко обнаружить даже без использования какого-либо кода.
Причем описывалась подобная проблема еще раньше и другими пользователями (на старом форуме):
http://forum-archive.quik.ru/forum/iwr/111108/?pagelength=100
Выше (уже в этой ветке нового форума) ваш коллега подтвердил, что попытка решить проблему невозможности точного воссоздания истории изменений двух и более различных параметров путем введения дополнительного поля count оказалась неудачной:
Цитата
Sergey Gorokhov пишет:
Дмитрий ,
Да Вы правы. Боюсь что имеющимися средствами построить таблицу истории из двух и более параметров никак не получится.
 
Дмитрий,
Отсутствие функционала не является ошибкой.
Ошибкой, можно считать любое девиантное поведение софта.
А то, что поставленная Вами задача не решается из за отсутствия технической возможности, это не ошибка.
В связи с чем, переквалифицировать мы ничего в этом месте не будем.
 
Я немного ошибся при указании ссылки на предыдущее описание проблемы. По приведенной мною ссылке (http://forum-archive.quik.ru/forum/iwr/111108/?pagelength=100 , в третьем снизу сообщении), а также и по этой ссылке: http://forum-archive.quik.ru/forum/lua/121572/
пользователь PFelix лишь жаловался на то, что добавление поля Count не решило ту проблему, которую он описал вот здесь:
http://forum-archive.quik.ru/forum/lua/113078/
Ближе к концу обсуждения там есть сообщение Михаила Булычева с таким содержанием:
Цитата
Добрый день.
Насколько я понимаю, сейчас вся проблема в том, что время на тике указано с недостаточной точностью, чтобы строить таблицу истории с интервалом меньше секунды. Готовы зарегистрировать пожелание на доработку функции T() источника данных. Она будет возвращать кроме времени еще и номер "тика", который случился в эту секунду.
Там же чуть ниже есть Ваше, Сергей Горохов, сообщение:
Цитата
Будет добавлен порядковый номер тика. Как предложил Михаил.
Все это было заявлено вами как планируемая доработка вашего софта для решения проблемы невозможности построения таблицы истории значений двух и более параметров средствами QLua.
Заявленная доработка в итоге была реализована и было добавлено поле Count. Однако значения, которые в нем возвращаются, не позволяют решить описанную выше проблему.
Поэтому PFelix, я и latrop1 считаем, что данный факт является следствием ошибки в реализации заявленного вами функционала, приводящей к его фактической неработоспособности.
 
Цитата
Egor Zaytsev пишет:
Цитата
latrop1 пишет:
Здравствуйте!

Просьба переквалифицировать доработку в ошибку и исправить в приоритетном порядке.
Детали (простите за дубляж):
https://forum.quik.ru/forum10/topic444/

Сообщите, пож-та, о принятом решении.
Добрый день.

Можете выложить Ваш код на котором воспроизводится проблема.
Немного не понятно, код чего Вы просите.
Никакого кода не нужно, проблема проявляется в стандартном интерфейсе Квика.
Если на одно окно диаграммы бросить пару графиков параметров, напр, "кол-во сделок" и "цену последней", то при тиковом интервале графики окажутся не корректно синхронизированными.
Графики на меж-секундных интервалах будут синхронизированы по значению поля count, что в корне не верно для разных параметров, имеющих разное кол-во count в пределах секунды.
Вы можете попробовать сами повторить по такому описанию?  
 
Цитата
latrop1 пишет:
Никакого кода не нужно, проблема проявляется в стандартном интерфейсе Квика.
Если на одно окно диаграммы бросить пару графиков параметров, напр, "кол-во сделок" и "цену последней", то при тиковом интервале графики окажутся не корректно синхронизированными.
Согласен, эту ошибку в работе терминала я тоже заметил уже давно на графиках, а затем уже обнаружил подобную проблему и при попытке сопоставить данные по двум параметрам с помощью QLua.
 
Цитата
Дмитрий пишет:
Цитата
latrop1 пишет:
Никакого кода не нужно, проблема проявляется в стандартном интерфейсе Квика.
Если на одно окно диаграммы бросить пару графиков параметров, напр, "кол-во сделок" и "цену последней", то при тиковом интервале графики окажутся не корректно синхронизированными.
Согласен, эту ошибку в работе терминала я тоже заметил уже давно на графиках, а затем уже обнаружил подобную проблему и при попытке сопоставить данные по двум параметрам с помощью QLua.
Да, верно.
Только проблему невозможности сопоставить тики параметров через QLua - разработчики квалифицируют как доработку.
Я же прошу эту проблему зафиксировать и квалифицировать как ошибку синхронизации графиков с стандартном интерфейсе Квика, что подразумевает ее приоритетное исправление относительно прочих доработок.

При этом, конечно, очень рассчитываю, что разработчики проблему решат комплексно, и для графиков, и для работы с параметрами через QLua.
 
Цитата
latrop1 пишет:
Цитата
Дмитрий пишет:
Цитата
latrop1 пишет:
Никакого кода не нужно, проблема проявляется в стандартном интерфейсе Квика.
Если на одно окно диаграммы бросить пару графиков параметров, напр, "кол-во сделок" и "цену последней", то при тиковом интервале графики окажутся не корректно синхронизированными.
Согласен, эту ошибку в работе терминала я тоже заметил уже давно на графиках, а затем уже обнаружил подобную проблему и при попытке сопоставить данные по двум параметрам с помощью QLua.
Да, верно.
Только проблему невозможности сопоставить тики параметров через QLua - разработчики квалифицируют как доработку.
Я же прошу эту проблему зафиксировать и квалифицировать как ошибку синхронизации графиков с стандартном интерфейсе Квика, что подразумевает ее приоритетное исправление относительно прочих доработок.

При этом, конечно, очень рассчитываю, что разработчики проблему решат комплексно, и для графиков, и для работы с параметрами через QLua.
Обращаюсь к сотрудникам техподдержки.

Зафиксирована ли данная проблема, как ошибка?
Можно ли ожидать скорейшее ее исправление?
 
Добрый день.
Мы зафиксировали пожелание на доработку. Ошибкой это не считаем.
 
Здравствуйте Михаил,
Но теперь Вы дорабатываете доработку, которая ни к чему не привела. Вы даже не удосужились проверить, работает ли Ваш алгоритм.
Count мы получили. Но к чему он. Вы уверяете, что с его помощью можно составить таблицу изменения параметров, а в действительности - нельзя.
Если сервис QLUA не должен обеспечивать цельность данных, может, это и не ошибка. Но в доработке-то это именно так.
Ждали год - получили совершенно непотребную вещь.
В чем проблема-то? Ведь, сделать это проще простого.
 
Цитата
latrop1 пишет:
Присоединяюсь к топик-стартеру.
Возможно ли доработать Квик для решения данной проблемы?
Примите заявку, пож-та, т.к. очевидно, что имеющимися средствами проблему сопоставления разных параметров качественно никак не решить.
Добрый день,

Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
 
Цитата
Sergey Gorokhov пишет:
Дмитрий,
Отсутствие функционала не является ошибкой.
Ошибкой, можно считать любое девиантное поведение софта.
Вики пиет:
Девиа́нтное поведе́ние
(также социальная девиация) — это поведение, отклоняющееся от общепринятых, наиболее распространённых и устоявшихся норм в определённых сообществах в определённый период их развития
---------------------
вопрос: Если софт имеет поведение, то может это диагноз?
 
:D
 
Цитата
Stanislav Tvorogov пишет:
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
Не странно ли. Доработка уже была реализована, но ошибочно. Т.е. проверка "на непротиворечивость общей политики компании", как понимаю, пройдена давно.
Или фарс лояльности к пользователю продолжается.
 
Цитата
Дмитрий пишет:
Цитата
Дмитрий пишет:
... сделать так чтобы значение count отражало не порядковый номер изменения отдельно взятого параметра в пределах секунды, а порядковый номер временного среза в пределах одной секунды, во время которого было получено изменение данного параметра ...
В итоге задача построения таблицы изменений параметров по этим данным стала бы решаемой.
Под временным срезом имеется в виду порядковый номер в пределах одной секунды того момента времени, когда было получено изменение любого из параметров, относящихся к данному инструменту ( или вообще к любому инструменту, по которым в терминал поступают изменения параметров ).
Лучше реализовать вариант, выделенный жирным шрифтом, так как иначе не получится построить корректную таблицу изменений параметров, содержащую данные одновременно по нескольким инструментам.
Добрый день,

Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
 
Так я не понял будет в клуа Таблица Изменений Параметров (ТИП)? если нет срочно оформляйте заяфку!
и да можно как то чтоб ее не выводить на экран а клуа она была или делайте чтоб onparam работал на старые данные  
 
Цитата
Will Will пишет:
Так я не понял будет в клуа Таблица Изменений Параметров (ТИП)? если нет срочно оформляйте заяфку!
и да можно как то чтоб ее не выводить на экран а клуа она была или делайте чтоб onparam работал на старые данные
Сформулируйте пожалуйста обращение более понятным языком.
 
Цитата
Will Will пишет:
Так я не понял будет в клуа Таблица Изменений Параметров (ТИП)? если нет срочно оформляйте заяфку!
и да можно как то чтоб ее не выводить на экран а клуа она была или делайте чтоб onparam работал на старые данные
Все есть. CreateDataSource()
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
Sergey Gorokhov пишет:
Цитата
Will Will пишет:
Так я не понял будет в клуа Таблица Изменений Параметров (ТИП)? если нет срочно оформляйте заяфку!
и да можно как то чтоб ее не выводить на экран а клуа она была или делайте чтоб onparam работал на старые данные
Сформулируйте пожалуйста обращение более понятным языком.
Есть в квике табла Таблица Изменений Параметров. Я хочу чтоб она в клуа была, чо непонятного то? Для ТВС этот код  local L1 = getItem('all_trades', i1) а для ТИП какой?
 
Цитата
Will Will пишет:
Цитата
Sergey Gorokhov пишет:
Цитата
Will Will пишет:
Так я не понял будет в клуа Таблица Изменений Параметров (ТИП)? если нет срочно оформляйте заяфку!
и да можно как то чтоб ее не выводить на экран а клуа она была или делайте чтоб onparam работал на старые данные
Сформулируйте пожалуйста обращение более понятным языком.
Есть в квике табла Таблица Изменений Параметров. Я хочу чтоб она в клуа была, чо непонятного то? Для ТВС этот код local L1 = getItem('all_trades', i1) а для ТИП какой?
В текущей реализации доступа к этой таблице нет
 
А о чем говорит s_mike@rambler.ru ("Все есть. CreateDataSource()"?
 
Цитата
Will Will пишет:
А о чем говорит s_mike@rambler.ru ("Все есть. CreateDataSource()"?
Это доступ к данным в таблице.
Это совсем не тоже самое что и доступ к самой таблице.
Разница в сортировке значений, тема уже обсуждалась на форуме
 
Хорошо а как к данным (например  "BIDDEPTH") получить доступ которые были в 15:45?
Страницы: 1 2 След.
Читают тему
Наверх