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

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

Страницы: Пред. 1 2 3 4 След.
Индикатор торговой сессии
 
Цитата
swerg написал:
Цитата
BlaZed написал:
У меня в квике, как оказалось, ограничения стояли на получение данных раз в 1 секунду.

Прикольно, это что за настройка такая?
Основные настройки/Программа/Получение данных/Запрашивать данные раз в ___ сек.
агрегировать значения из таблицы сделок по временному условию
 
Цитата
Nikolay написал:
Цитата
Игорь М написал:
Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
Кроме быстродействия и наглядности никаких.
Какого быстродействия? Что быстрее bit.test или bit.band?
агрегировать значения из таблицы сделок по временному условию
 
Цитата
Nikolay написал:
...
Николай, я предполагаю, что это вы мне написали, поэтому давайте объясню:

Цитата
А вот то, что функция аггрегирования вызывается несколько раз - это не очень.
Почему не произвести расчет разово, перебрав сделки в одном цикле.
Если вы про вызовы в message, то это просто для демонстрации, чтобы человеку нагляднее было. Задачи что-то несколько раз перебирать и не стояло. Ему, вообще, только для лонга нужно было и, возможно, он один раз в конце дня этот скрипт запускает. Понятно, что одно и тоже несколько раз не нужно пересчитывать. Я также надеюсь, что он догадается при частом подсчете не обсчитывать  строки таблицы каждый раз от 0 по новой при поступлении новой записи в таблицу.
Цитата
Что касается направления сделки, то если это обычная таблица trades (а  не обезличенные сделки), то направление это 2-ой бит флага.
И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.
Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
агрегировать значения из таблицы сделок по временному условию
 

Чуть подкорректировал (после 12 часов это ">="):

Код
local SecCode = "RIH1"

function aggrF(direction)
    local value=0                                                                         -- здесь рассчитываю кумулятивное значение из столбца объем таблицы сделок
    for i = 0, getNumberOf("trades") - 1 do
       local trade = getItem ("trades", i)                                                                              -- получение таблицы данных из i-ой строки ТС
       if bit.band(trade.flags, 4) == direction and trade.sec_code == SecCode and trade.datetime.hour >= 12 then        -- сделка на продажу по конкр. инструменту
          value = trade.value+value
       end
    end
    return value
end

  message ("Buy: " .. tostring (aggrF(0)))
  message ("Sell: " .. tostring (aggrF(4)))
  message ("Total: " .. tostring (aggrF(0)+aggrF(4)))
Данный инструмент запрещен для операции шорт
 
 Владимир, пишите/звоните своему брокеру. Разработчики тут ни при чем.
Создание авто ввода текста в Lua, Как создать скрипт который при нажатии клавиши мышки вводил бы текст автоматически.
 
Цитата
Антон написал:
Есть такая приложуха GHUB для мышек фирмы логитеч и хотелось бы привязать к клавиши как то это
Там есть возможность без скрипта но тогда не будет работать клавиша как то иначе как кроме ввода значений
Антон, это форум про другую игру.  :smile:  
Выскакивает ворнинг "Compare string with number", А его не должно быть, по идее!
 
Цитата
Александр Волфовиц написал:
 На малоликвидных инструментах OnQuote может и по 10 секунд не срабатывать - а время желательно чтоб было актуальное.
Вроде бы проблема решилась с помощью локальных переменных перед проверкой, спасибо всем за советы!
Я, когда вам отвечал, торопился и поэтому что-то невнятное написал. Хорошо, что есть Антон, который все верно порекомендовал. В вашей ситуации проблема не только со строками/числами, но и со временем. Если вы хотите получать актуальное время, то делайте, как Антон написал, чтобы не было последовательных присвоений, а только разом. Очень маловероятна, но реальна ситуация, что в момент присвоения local hour, min, sec = hcc, mcc, scc вы получите час из старого определения времени в main, а минуту из нового. Подзавис основной поток в начале часа и у вас в OnQuote смещение на 59 минут.
Выскакивает ворнинг "Compare string with number", А его не должно быть, по идее!
 
Лучше перед if объявит локальную hcc, а в конце поставить hcc = hcc или что-то типа этого. Тогда для аварийной строки в OnQuote () hcc всегда будет number.
Выскакивает ворнинг "Compare string with number", А его не должно быть, по идее!
 
Предположение: В строке if type(hcc) == 'number' and type(mcc) == 'number' then значение глобальной hcc ещё number, а дальше при сравнении в строке "if hcc <= 10 and hcc >= 9 and mcc < 5 then" оно уже string.
Попробуйте перед первым if поставить что-то типа local hcc = hcc (или как вам по коду лучше будет)
Выскакивает ворнинг "Compare string with number", А его не должно быть, по идее!
 
Цитата
Александр Волфовиц написал:
Константин Рейм, мне нужно, чтобы в числах были отдельно часы и минуты.

BlaZed, первый фрагмент кода находится в main(), второй - в OnQuote() , ворнинг возникает в рабочее время биржи.
А сама аварийная строка "if hcc <= 10 and hcc >= 9 and mcc < 5 then" где находится?
Как понять, что скрипт загружен через require?
 
Цитата
Незнайка написал:
В Lua 5.1 можно было заглянуть в package.loaded[modname].
Если там userdata, то скрипт загружен через require, иначе - запущен сам.
А теперь как?
Незнайка, вы в скрипте, который может запускать рассматриваемый модуль, поставьте флаг и проверяйте его в модуле. Если модуль флаг не видит, значит он сам запущен, а если видит, то снаружи.
Утечка памяти, Происходит утечка памяти
 
Цитата
Виталий написал:
Вопрос к знающим и к поддержке: почему происходит утечка памяти? Версия Quik 8.10.1.1
Для информации: Проверил первый скрипт у себя на 8.7 и 8.8 - всё в порядке. Растет незначительными темпами, а затем сбрасывается. Если вставить collectgarbage ("step"), то совсем незначительные колебания (отклонение в 10% от 40КБ до 44КБ), а если collectgarbage () - не изменяется вообще.
Отладка QUIK 8.11
 
Цитата
Максим написал:
Добрый день!
Столкнулся с проблемой:
на lua 5.3 пользовался такой конструкцией в модулях: module(..., package.seeall)
на lua 5.4.1  - убрали module и package.seeall
как проще выйти из ситуации?
module(..., package.seeall) - это старый способ. Ссылка.
Неприятность таблицы "Клиентский портфель", Вопрос "совсем новичка":
 
Цитата
Павел написал:
 Так я получу количество лот газпрома в портфеле?
Код
       -- Задаем параметры запроса 

    firm_id  =   "          " 
    client_code  =   "        " 
    class_code  =   "TQBR" 
    sec_code  =   "GAZP" 


     -- Запрашиваем данные 
    result  =   getBuySellInfo (firm_id, client_code, class_code, sec_code,  0 )

    lots  =  result.balance
  
Вы поменьше выкладывайте персональных данных. По поводу выведется что-то или нет проверяйте на практике самостоятельно, вопросов у вас и без мелочей ещё ворох останется. В "Интерпретаторе языка Lua" описаны функции, таблицы и пр. - пользуйтесь, и поиском по форуму тоже, здесь уже многие вещи обмусолены.
Неприятность таблицы "Клиентский портфель", Вопрос "совсем новичка":
 
Цитата
Павел написал:
Коллеги, прошу подскажите, что я не так делаю?
Не возвращает прочитанные количества лотов:

-- функция возвращает количество лотов в клиентском портфеле по заданному инструменту
function get_lots(arg_Sec_Code)
   local lots = 0                
   for i = 0, getNumberOf("FUTURES_CLIENT_HOLDING") - 1 do            
      if getItem("FUTURES_CLIENT_HOLDING",i).sec_code == arg_Sec_Code then
         lots = getItem("FUTURES_CLIENT_HOLDING",i).totalnet
      end
   end      
   return lots
end
Буквы высокие.
Код
local function get_lots (arg_Sec_Code)
   for i = 0, getNumberOf ("FUTURES_CLIENT_HOLDING") - 1 do
       local fch = getItem ("futures_client_holding", i)   
       if fch and fch.sec_code == arg_Sec_Code then
           return fch.totalnet     -- or 0
       end
   end      
   return 0
end
FAQ: Оптимизация производительности клиентского места QUIK, Обсуждение
 
Цитата
Александр Кашников написал:
Склейка инструментов  на срочке - подтверждаю - это бред, который никому не нужен.
Свечки это совсем не актуальная информация, их перерисовывают при каждом клиринге - скрывают сделки крупных ММ.
А тут еще вы со своей склейкой и  главное выбора никакого нет , а я не просил склейку и никто не просил, даже Вася не просил, я у него спрашивал.
Склейка по умолчанию стоит включенной (было бы правильнее сделать её выключенной по умолчанию), но она отключается. Я при замене инструмента с истекающем сроком обращения отключаю склейку вручную.
Форматирование таблицы сделок
 
Цитата
Evgeniy Karnaukhov написал:
Цитата
Игорь М написал:
Я хочу привести данную таблицу к состоянию, которое изображено на первом скрине этой темы. Да, вы правильно понимаете: ячейки цены должны быть выделены жирным и быть такого же цвета, что и остальные ячейки соответствующей строки. Раньше все было как и должно быть (этот первый скрин был сделан специально в 7-й версии предварительно перед обновлением на 8-ю, так как на другом терминале при обновлении я заметил это нововведение).  Сейчас же ячейки цены выделяются серым цветом.  
Как можем видеть на Вашем скриншоте, для параметра "Цена" у Вас установлено форматирование - стоит галочка для "Форматирование включено" в левом верхнем углу. Отключите форматирование, сняв галочку с этой опции.
Хорошая шутка! Еще можно посоветовать выключить Квик и компьютер. Евгений, вы спрашивали: "Уточните, пожалуйста, к какому состоянию Вы хотите привести данную таблицу?"  Я ответил, что хочу привести данную таблицу к состоянию, которое изображено на первом скрине этой темы". Думал, что ответил понятно, но попробую объяснить еще раз:  
Я сам включил это форматирование, а не оно само как-то включилось. Включил я его для того, чтобы значение цены всегда выделялось жирным шрифтом. Одновременно с этим надо, чтобы строки таблицы форматировались целиком по цвету, включая ячейки со значениями цены.  Это работало. Раньше. Что я и продемонстрировал в первом скрине. Вы можете сделать также, как у меня на первом скрине, какими-то пользовательскими настройками или это баг?
FAQ: Оптимизация производительности клиентского места QUIK, Обсуждение
 
Цитата
Roman Azarov написал:
Старатель, добрый день!
если в терминале используется таблица обезличенных сделок, экспорт тиков во внешние системы или же построение тикового графика, то с сервера QUIK будут заказаны  все  сделки по  всем  инструментам, на получение информации по которым у терминала (пользователя) есть права независимо от того, какие фильтры настроены в таблице обезличенных сделок или по какому конкретному инструменту открыт тиковый график.
Как-то это нерационально. Зачем получать то, что не нужно? У МБ 80-90% мало кому интересный неликвид. Зачем его транслировать, если человек работает только с RI и Si? Где в такой логике минимизация трафика и улучшение производительности?
Форматирование таблицы сделок
 
Цитата
Evgeniy Karnaukhov написал:
Игорь М, уточните, пожалуйста, к какому состоянию Вы хотите привести данную таблицу? Правильно понимаем, что Вы хотите, чтобы ячейки Цены НЕ подсвечивались отдельным синим цветом? Если так, то нужно проверить именно настройки форматирования по Цене. Пришлите, пожалуйста, скриншот окна форматирования по параметру "Цена".
Я хочу привести данную таблицу к состоянию, которое изображено на первом скрине этой темы. Да, вы правильно понимаете: ячейки цены должны быть выделены жирным и быть такого же цвета, что и остальные ячейки соответствующей строки. Раньше все было как и должно быть (этот первый скрин был сделан специально в 7-й версии предварительно перед обновлением на 8-ю, так как на другом терминале при обновлении я заметил это нововведение).  Сейчас же ячейки цены выделяются серым цветом.  
пс. Сделайте ограничение по размеру для уменьшения картинки, чтобы скрины меньше определенного размера уже не уменьшались (87 КБ уменьшает до 29, а потом не ясно, что изображено)
Форматирование таблицы сделок
 
Цитата
Evgeniy Karnaukhov написал:
Игорь М, здравствуйте.

Вероятно, нужно проверить форматирование таблицы сделок по Цене. Для этого правой кнопкой мыши щелкните по столбцу "Цена" и выберите "Форматирование "Цена"". В открывшемся окне должны быть заданы условия и цветовые настройки. Вы можете их как изменить, так и вовсе убрать, нажав на значок крестика справа от условий или сняв галочку с "Форматирование включено" в левом верхнем углу окна (так форматирование не удаляется, а просто отключается).
Евгений, так не получается что-то, потыкал я как раньше, но так, чтобы выделялся жирным столбец и при этом менялись по цветам строки без появления серого фона, не выходит. Может у вас получится? Спасибо.
Форматирование таблицы сделок
 
 Здравствуйте! До смены версии Квика у меня было так:



Теперь получилось так:



Как-то можно сделать как раньше? Спасибо.
пс. Качество плохое, так как у вас обрезает. Вставляется ли нормально?
Неверная дата и время, Стандартные функции Lua возвращают неверное время сервера
 
Цитата
MrLex написал:
Подскажите как получить текущие дату/время сервера в формате "20201023_2345"?
Если секунды не нужны - закомментируйте их

Код
local function serverTime ()                               -- функция расчета времени сервера

   local ser_time = getInfoParam ("SERVERTIME")

   if ser_time and #ser_time == 8 then
       return string.sub (ser_time, 1, 2) .. string.sub (ser_time, 4, 5) .. string.sub (ser_time, 7, 8) 
     else
       return false 
   end

end

local function serverDate ()                               -- функция расчета даты сервера

   local ser_date = getInfoParam ("TRADEDATE")
   return string.sub (ser_date, 7, 10) .. string.sub (ser_date, 4, 5) .. string.sub (ser_date, 1, 2)

end

message (tostring (serverDate ()) .. "_" .. tostring (serverTime ()))
Таблица "Доступные скрипты", lua-скрипты и их эксплуатация. За что пользователи не любят QUIK
 
Поддерживаю, уже писали похожие пожелания. Хотя бы пункты 4, 5, 6 для начала. Слишком много бесполезной площади. Остальные пункты тоже дельные.
Как убрать нуль после точки?, .0
 
Цитата
Алексей написал:
Допустим получаю значение цены через OnAllTrade. Далее пишу это значение в файл или таблицу - получается 77934.0
Как сделать, что бы была обычная запись 77934, без .0 ? Только недавно перешел с 32б QUIK, в 64b. В старом такого не было.
Кажется, это уже было: ответ на 10 вопрос
Выделять объём на тиковом графике цветом в зависимости от направления сделки
 
Цитата
Старатель написал:
 Сравнение в скорости линейного поиска с SearchItems:
Цитата
Искомый элемент в начале таблицы:
linSearch: 0.660
SearchItems: 0.495
 
Цитата
Искомый элемент в конце таблицы:
linSearch: 18.437
SearchItems: 4.919
Да, у меня такие же пропорции по результатам. То, что линейный быстрее SearchItems, я писал для случая вызова SearchItems без параметров, а с параметром он быстрее, да. И сжирается всё  вызовом getItem. Арковцы писали, что в 8-й версии была исправлена "Медленная работа функции getItem в QLUA", я сравнил, но что-то разницы с 7-й не заметил.
Выделять объём на тиковом графике цветом в зависимости от направления сделки
 
Согласен со всеми. Про спот я, вообще, забыл  :what: . Тогда, действительно, лучше строить копии ТОС отдельно по каждому инструменту.
Выделять объём на тиковом графике цветом в зависимости от направления сделки
 
Цитата
Старатель написал:
 не лазить в таблицу "all_trades" в поисках нужной сделки - очень сильно затормаживает расчёт: сам только вызов SearchItems увеличивает время расчёта в 10 и более раз.
Старатель, здравствуйте. Увидел это ваше сообщение по поводу использования SearchItems в ТОС, а так как я раньше об этой функции не знал (как-то ускользнула от моего внимания, другие использовал), то решил её проверить и написать, что получил. Может кому-то ещё эта инфа пригодится.
Сравнил её только с двумя методами поиска: линейным и бинарным. Если искать по идентификатору сделки порядковый номер в таблице, то даже линейный поиск быстрее на 30%. Бинарный быстрее в 7000 раз. Если вызывать SearchItems с параметром "trade_num", то он быстрее вызова без параметра в 10 раз (в 700 раз медленнее, чем бинарный). Не понял я замысла сей функции и области её применения. Может что-то ускользнуло от моего внимания, какой-то смысл в неё заложенный, поэтому вы у себя проверьте, вот функции, которыми проверял:
Код
local function linSearch (t, id, num_1, num_2)             -- функция линейного поиска

   while num_1 <= num_2 do

       local t_trade_num = getItem (t, num_1).trade_num            -- номер сделки в таблице

       if id == t_trade_num then                                   -- сравнение идентификационных номеров
           return num_1
         else
           num_1 = num_1 + 1
       end

   end

end

local function binSearch (t, id, num_1, num_2)             -- функция бинарного поиска

   while num_1 <= num_2 do

       local middle = num_1 + math.floor ((num_2 - num_1) * 0.5)       -- середина диапазона

       local t_trade_num = getItem (t, middle).trade_num               -- номер сделки в таблице

       if id < t_trade_num then                                        -- сравнение идентификационных номеров
           num_2 = middle
         elseif id > t_trade_num then
           num_1 = middle
         else
           return middle
       end

   end

end

local res =  linSearch ("all_trades", 26139171939000, 0, getNumberOf ("all_trades") - 1)           -- вызов
Функция SetLabelParams. Зачем она нужна?
 
Цитата
Imersio Arrigo написал:
Вероятно обновить значение в метке тупо быстрее чем удалить-создать.
Просто заметно это когда их много.
По скорости разницы нет, проверял. Думается, что функция SetLabelParams это DelLabel + AddLabel.
Функция SetLabelParams. Зачем она нужна?
 
Всем привет! Задался вопросом: Зачем нужна функция SetLabelParams? Для вывода обновляемой метки пользовался кодом, типа:
Код
   local label = {}

    label.TEXT = difference
    ......
    label.FONT_HEIGHT = 10

   DelLabel (CHART_TAG_PRICE_1, result)
   result = AddLabel (CHART_TAG_PRICE_1, label)

По скорости сравнивал - нет разницы. В чем смысл SetLabelParams? Есть какие-то нюансы?
Строки вместо чисел в таблицах Quik 7.27.2.1
 
Здравствуйте, Андрей. Да, я знаю и пользуюсь выводом DDE и ещё у меня скрипт написан на вывод определенной информации в файл, так что с возможностями вывода я знаком. Мне хотелось бы, чтобы те вещи, которые в программе были изначально и очень давно сделаны нормально и удобно, не переделывались в угоду непонятно кому. Вот кому вдруг  понадобился вывод объемов, цен, маржи и пр. в строковом формате при копировании правой кнопкой? Такие вещи для любителей лишних движений нужно делать опционально. А многие люди, вообще, не врубаются в эти выводы всякие разные, а просто копируют таблицу ctrl+C и вставляют в Excel. Таких людей много, о них не нужно забывать.  Регистрировать ли пожелание на восстановление функционала? Зачем его регистрировать, его просто восстановить нужно. Кому он мешал и чем руководствовались люди, которые его ломали? Вы почаще спрашивайте практикующих трейдеров что им нужно, что менять, а что нет. Мне пришлось вернуться к старой версии из старой сохранённой перед обновлением папки (да, опыт сын ошибок трудных, научили). Чего ради такие "улучшения"? Появляется одна нормальная вещь: увеличение количества условий в пользовательском фильтре и одновременно - на, получай косячину в довесок. По поводу приоритета копирования ячейки сочетанием ctrl+C, а не всей таблицы - тоже вопрос. Неужели люди чаще ячейками копируют? Пользователи много лет при копировании таблицы целиком нажимали ctrl+C, а теперь, вводя возможность копирования ячейки, вы перекидываете комбинацию клавиш, которая уже у всех на автомате наработана, на другой функционал. Новый функционал нужно вешать на новые комбинации клавиш, старый оставлять на старых.
Строки вместо чисел в таблицах Quik 7.27.2.1
 
Обновил Квик до указанной версии. Копирую содержание таблиц (сделки, клиентский портфель, таблица ограничений по клиентским счетам) в Excel и вижу, что что-то имеет строковый формат, а что-то числовой (например: "Премия по опционам" - строка, а следующий столбец "Биржевые сборы" - число). Нельзя ли этот ужас исправить и сделать как было раньше на старых версиях (в числах). Зачем такое было сделано? Или если существуют какие-то люди, которым такое понадобилось, то сделайте опцию: вывод строк. Всё было просто и удобно: взял и скопировал без всяких бубнов. По уму и Ctrl + C в таблице на ячейку тоже на выбор опционально лучше сделать, приоритет на ячейку вместо таблицы целиком непонятен, я, например, ячейки по отдельности не копирую.
Отображение сделок на тиковом графике
 
Цитата
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)
 
Видео отослал на указанный адрес.
Страницы: Пред. 1 2 3 4 След.
Наверх