Игорь М (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
Отображение сделок на тиковом графике
 
Цитата
Egor Zaytsev написал:
Игорь, не понимаем, что в итоге нужно править? График строится исключительно выставленным обезличенным сделкам.
Егор, здесь не нужно ничего править, классический тиковый график нормальный. Это раздел пожеланий и у меня пожелание. Можно сделать ещё один тип отображения сделок на тиковом графике, где сделки будут отображаться более наглядно для восприятия трейдером. По отображению будет напоминать профиль рынка.

 
Сделки №228000001-228000031 произошли в один момент времени, например в 16:10:23 785462 мкс. Порядок возрастания их биржевых номеров слева направо и сверху вниз. Сделка №228000032 уже имеет другое время. Мы понимаем, что сделка 1 произошла раньше сделки 31, но время у них одно и по идее они все должны лежать на одной вертикальной линии. Так отобразить можно только на трехмерном графике (цена, время, номер), но это сложно и не нужно. Приведенный мною пример отображения сделок более компактен и более нагляден для анализа, сразу видно в какие моменты кто сколько по рынку рубанул. Объемы можно отображать как у свечей, то есть в данный момент времени (левая вертикальная линия) кто-то 500 контрактов продал разом.
пс Вещь некритичная, сам я на более крупных таймах торгую, но такая мысль появилась. Можно, конечно, скрипт написать, который таблицу всех сделок будет обрабатывать и куда-нибудь выводить, но раз уж терминал классический тиковый график способен нарисовать, то может и такой осилит.
Отображение сделок на тиковом графике
 
Цитата
s_mike@rambler.ru написал:
 Человек ошибочно считает, что сделки, прошедшие одним временем на тиковом графике должны быть расположены в одном и том же времени, на одной и той же вертикали графика. Без сдвига по горизонтали.
Почему ошибочно?
Отображение сделок на тиковом графике
 
Цитата
Egor Zaytsev написал:
 Добрый день.
Не совсем понятна описанная проблема. На скриншоте сделок не видно. Можете сделать четкий скриншот, чтобы была видна сделка и что именно с ней не так.
Это не моя сделка. Кто-то по рынку продал 1250 контрактов в один момент времени (нисходящая большая линия). Продажи в верхней и нижней точках произошли одновременно, на графике же и них разные координаты по оси абсцисс.
Отображение сделок на тиковом графике
 
Добрый день. Обращение к разработчикам по поводу отображения сделок на тиковом графике, особенно отображению одномоментных сделок.
Пример: Проходит одномоментная сделка на достаточно крупном объеме (наглядно выделяется на тиковом графике). RIM9, 08-05-2019 19:06:48,  размер 1250 контрактов, все сделки прошли в один момент по времени  132719 мкс. Отображение данной сделки идет по наклону, хотя по идее она  должна отображаться строго вертикально и такое отображение было бы куда более наглядным, чем нынешнее, а на средних объемах даже более информативным, чем на больших (большие сразу выделяются). Будет сразу видно, что совершена одномоментная сделка разом, а не несколько разных сделок близких по времени.
левые котировки, getCandlesByIndex()
 
Цитата
sergei написал:
Наличие погрешности при простом запросе свечки в виде candles.low без необходимости каких-либо операций даже внутри функции
getCandlesByIndex все равно выглядит странно как-то. Эта функция же просто стат. данные выдает.
Так она просто стат. данные и выдает. У вас значения типа 73.940000000001 возникают при исполнении оператора for, где выполняется вычитание шага (Руководство 3.3.5).
Попробуйте сперва вычислять количество уровней свечи: local qty_levels = math.round ((candles[i].high - candles[i].low) / MinPriceStep), а затем уже выполняйте цикл for ii = 1, qty_levels  do block end.
Сравнение дат.
 
Цитата
SDL написал:
 Целые числа в формате Lua "number" (он же C "double"), равно как и результаты операций +/- с ними, согласно особенностям IEEE 754, представляются точно. Поэтому просто не надо допускать невязок округления, и с целыми числами можно работать спокойно. А если невязки неизбежны, делать round().
Это понятно, я с вами согласен. Резюмируя: универсального выбора, в каком виде лучше сравнивать, судя по всему нет. Я думал, что строковое сравнение должно быть всегда надежнее, но, оказалось, что не всегда.

Если сравнивать в лоб без преобразований с округлениями, разделениями строк и т.п., то значения переменных вида: 20190425.00000001 == 20190425 надежнее сравнивать в числах, а значения переменных вида: 201904251234567.1 == 201904251234567 - в строках. При этом сравнение 20190425123456.01 == 20190425123456 лучше опять делать в числах, а 20190425123456.001 == 20190425123456 лучше, вообще, не сравнивать - неправильный результат в обоих случаях.
Сравнение дат.
 
Цитата
SDL написал:
 Строки сравниваются в лексикографическом порядке, т.е. посимвольно слева направо. Так как "0" < "1" < ... < "9", то при использовании строкового формата даты "YYYYMMDD" сравнение будет корректным. Вывод: в данном случае использование как числового, так и символьного представления будет работать одинаково правильно. Такая теория интересовала?
В общем меня интересовал вопрос: для какого из двух сравнений string ==  string и number == number вероятность потенциальной ошибки результата  сравнения выше и почему?
Я склоняюсь к сравнению числовых представлений, потому что такой вот скрипт:
 
Скрытый текст
дает вот такой результат:

Скрытый текст
Но, возможно, что существуют контрпримеры.
Сравнение дат.
 
Цитата
новичок написал:
 - любые конверсии из типа в тип стоят немало, замерьте ваш случай численно.
- строки в принципе неприятная штука, лучше обходиться массивом символов по возможности.
В моем случае лишние конверсии не являются критичными, да и когда нужно сравнить две переменные разных типов одну из них в любом случае придется переводить в тип второй. Поэтому я и озадачился выбором в какой тип предпочтительнее переводить для сравнения. В общем-то вопрос более теоретический, чем прикладной, так как потенциальных косяков в программе и окружении на порядок больше, чем эта мелочь.
Сравнение дат.
 
Цитата
Sergey Gorokhov написал:
Игорь М,
При сравнении даты и времени, самый правильный и надежный способ, перевести дату в число дней (для времени секунд) и далее уже сравнивать.
А что это меняет и как таки их корректно сравнивать? Можно от дат и времени абстрагироваться, это был просто пример из практики.
Как правильнее и надежнее в Lua сравнивать оператором "==" переменные, которые могут быть и string и number?  Переводить обе (или одну из них) в string и затем сравнивать строки или переводить в number и сравнивать числа? Я склоняюсь на сравнение чисел, но для меня это не очевидно, поэтому и спрашивал.
Сравнение дат.
 
Еще раз поясню попроще.  Есть две даты, которые изображены цифрами, а не словами. Например: 20190422. Эти даты можно преобразовать в string или number и сравнивать оператором "==".
То есть string == string и number  == number ("20190422" == "20190422" и 20190422 == 20190422)
Работают оба варианта.
Какой из этих двух вариантов правильнее, корректнее, надежнее?

пс Вопрос, конечно, не сильно критичный, но я подумал, что мало ли кто разбирался и знает.
Сравнение дат.
 
Цитата
s_mike@rambler.ru написал:
http://www.bot4sale.ru/blog-menu/qlua/368-lua-time.html
Я не нашёл там ответа на свой вопрос. Там описание работы со временем и датами. Вы ту ссылку дали?
Сравнение дат.
 
Всем добрый день. Как корректнее и надежнее сравнивать даты на Lua, как числа или как строки?
Пример: Получаем две даты:

os_date = os.date ("%Y%m%d")                                                                                                               -- текущая дата операционной системы (ОС)

local t = getCandlesByIndex (CHART_TAG_PRICE, 0, number - INT_QUANTITY, INT_QUANTITY)                   -- получение таблицы свечей заданного периода
local date_candle = dateCandle (t[j].datetime.year, t[j].datetime.month, t[j].datetime.day)                               -- получение даты свечи

function dateCandle (year, month, day)                                                                                                      -- функция формирования даты свечи (number)
  local candle_date = 10000 * year + 100 * month + day
  return candle_date
end

При сравнении: if date_candle == os_date then, переводить date_candle в string (изначально формировать в string)  или os_date переводить в number?
Процентное изменение
 
Это непосредственно график цены, не индикатор, хотя для индикатора это тоже неприемлемо. Помимо того, что это непригодно для использования, это даже визуально выглядит как патология. Этой проблемы раньше не было, были лишние ненужные для процентов разряды, типа 0,529712 %, но лучше так, чем просто 1%, когда фактически чуть больше половины процента.
Процентное изменение
 
Здравствуйте. В настройках графика при установлении галки "Процентное изменение" отображается только целая часть. Например, вместо 1.453 отображается только 1, то есть, как я понял, соответственно точности отображения цены инструмента. Где можно настроить количество знаков после запятой или отключить округление, так как такое округление бессмысленно (по сути это минус опция)?
Отличие localtime от os.time ()
 
Спасибо.
Отличие localtime от os.time ()
 
Спасибо. А с getInfoParam ("SERVERTIME") всё в порядке (на всякий случай интересуюсь)?
Отличие localtime от os.time ()
 
Добрый день. Чем отличается время getInfoParam ("LOCALTIME") от os.date ("%H%M%S") или os.time ()? У меня localtime отстает на 200-500 мс.

function main ()

  while is_run do

       os_time_1 = os.date ("%H%M%S")
       os_time_2 = os.time ()
       localtime = getInfoParam ("LOCALTIME")

       message ("Localtime: " .. tostring (localtime)  .. ", os_time_1: " .. tostring (os_time_1) .. ", os_time_2: " .. tostring (os_time_2))

       sleep (100)

  end

end
Время сервера (SERVERTIME)
 
Для интересующихся: При физическом разрыве соединения время сервера будет продолжать отсчет. По факту это будет уже не время сервера, а время локального таймера.
При использовании функции isConnected () (на Qpile или Lua) для целей контроля установленного соединения задержка срабатывания может быть 40-60 секунд от фактического разрыва связи.
Кому критично фиксировать разрыв раньше  используйте GET_INFO_PARAM ("BYTESPERSECRECV") + 0 != 0 (можно с задержкой в секунду). Во время торговой сессии ложных срабатываний не даёт, а разрыв фиксирует сразу.
Всем удачи!
 
Время сервера (SERVERTIME)
 
Видео отослал на указанный адрес.
Время сервера (SERVERTIME)
 
Егор, куда вам переслать видео?
Еще раз уточню: 1) При отключении нажатием на кнопку "Разорвать соединение с информационным сервером" все происходит корректно: поступление данных останавливается, время сервера исчезает из портфеля и информационного окна, появляется сообщение "Соединение разорвано".
2) При выдергивании интернет-кабеля из блока компьютера происходит следующее: поступление данных останавливается, время сервера в портфеле и в информационном окне продолжает идти, примерно через 20 секунд появляется надпись "Connection reset by peer" и время сервера исчезает.  
Время сервера (SERVERTIME)
 
В информационном окне время также  преспокойненько продолжает течь. Если нажать на кнопку ключа в верхнем левом углу (разорвать соединение с информационным сервером), то время сервера (и в моем портфеле и в информационном окне) сразу отключается (исчезает). Два брокера, два Квика (7.14.1.7 и 6.17.1.17)  - одинаковое поведение.
Время сервера (SERVERTIME)
 
Здравствуйте.
Вопрос в следующем: Почему при отключении интернета (выдергивании шнура из блока) время сервера продолжает транслироваться в таблице портфеля? Длится это может до 20 секунд до появления надписи "Connection reset by peer". Всё остальное (стаканы, графики) при этом останавливается.

Простой код для проверки:

PORTFOLIO_EX TIME_SERVER;
DESCRIPTION Время сервера;
CLIENTS_LIST  ALL_CLIENTS;
FIRMS_LIST ALL_FIRMS;
USE_CASE_SENSITIVE_CONSTANTS;

PROGRAM

OUTPUT = CREATE_MAP()                        

SERVERTIME = GET_INFO_PARAM ("SERVERTIME")      ' время сервера в формате ЧЧ:ММ:СС

DELETE_ALL_ITEMS ()  

OUTPUT = SET_VALUE (OUTPUT,"SERVERTIME" , SERVERTIME)
ADD_ITEM (1,OUTPUT)

END_PROGRAM

PARAMETER SERVERTIME;
PARAMETER_TITLE Time;
PARAMETER_DESCRIPTION Текущее время сервера;
PARAMETER_TYPE STRING(10);
END

END_PORTFOLIO_EX
Таблица сделок, Данные из таблицы сделок (TRADES)
 
Сергей, спасибо, я разобрался. В Lua написал аналогичный код и все данные увидел. В коде на qpile была элементарная ошибка, а в отладчике строка с данными TRADE целиком не выводится и я не увидел там QUANTITY и пр. Из-за ошибки кода QUANTITY не определялось и я решил, что часть данных просто не пришло. Спасибо ещё раз.
Таблица сделок, Данные из таблицы сделок (TRADES)
 
Здравствуйте. Не могу получить некоторые данные из "Таблицы сделок" (не путать с "Таблицей всех сделок"), например Количество в лотах (QUANTITY).

TRADE = GET_ITEM ("TRADES", I)                     - в строке достаточно много информации, но нет QUANTITY
OPER = GET_VALUE (TRADE, "OPERATION")     -  получаем SELL/BUY без проблем
QUAN = GET_VALUE (TRADE, "QUANTITY")       - не получаем

В описании параметров Таблицы сделок, возвращаемых функцией GET_ITEM, параметр QUANTITY есть.
Кто виноват и что делать?
Шрифты., Вернуть в Quik возможность использования всех доступных шрифтов, как это было в версии 6.17
 
Anastasia  Gordienko написала: "Дело в том, что старый шрифт "MS Sans Serif" имеет более размытое начертания".  Это не так. Я привёл скрины в качества примера.
"Попробуйте установить шрифт "Microsoft Sans Serif" его начертание более четкое".  У него тоже формат .ttf. Он такой же размытый как и все остальные шрифты указанного формата. Ещё раз привожу пример. Здесь Microsoft Sans Serif, MS Sans Serif и Arial.  Какой из них не размытый?




пс. Указанная мной проблема не является ошибкой в Квике. Это особенность ClearType. Пока у всех не появятся 4K мониторы проблема останется. Простейшим решением будет просто вернуть убранные шрифты .fon. В версии 6.17 всё было и есть хорошо. Это не прихоть, это заметно и без увеличения.
Шрифты., Вернуть в Quik возможность использования всех доступных шрифтов, как это было в версии 6.17
 
Здравствуйте. Начиная с 7-ой версии стало невозможно выбрать в настройках шрифты .fon, в частности MS Sans Serif. Доступны только шрифты формата .ttf. В таблицах шрифты .ttf выглядят замыленными и размытыми (особенно при выделении жирным). При отключении ClearType в Windows проблема снимается для обычных шрифтов, но для жирных остаётся. К тому же отключение ClearType вносит размытость и необходимость замены шрифтов в самой Windows (дефолтный Segoe UI заточен под ClearType), а также в других программах, что не всегда в принципе возможно. В 6-ой версии такой проблемы нет. Пока у всех не будет мониторов 4K разумным будет шрифты .fon вернуть. Примеры в приложенных скринах. Скрины сделаны в версии Quik 7.14.1.7 (Windows 7/64) в красном и черном цветах с включенным и выключенным ClearType. Для сравнения 1 строка - Arial 8, 3-я строка - Arial 8 жирный, 2-я и 4-я строки - обычный MS Sans Serif 8. Жирный MS Sans Serif 8 виден в заголовках столбцов.
пс.
Шрифт MS Sans Serif можно поставить в терминал по умолчанию, прописав его в параметрах конфигурации (файл INFO) и только. Выделить его полужирным в таблице не выйдет.
Страницы: 1
Наверх