Saturn, Второй способ На смартфоне ставите приложение отправки SMS на URL На ПК делаете сервер-приложение (на Autoit или любом другом языке), который будет запускать КВИК и передавать в него код. ---------------------- Третий способ На смартфоне ставите приложение отправки SMS в telegram На ПК делаете сервер-приложение (на Autoit или любом другом языке), который будет запускать КВИК и передавать в него код. В telegram ставите бот, который запускает приложение на ПК --------------------- Успехов
Igor_User написал: Возникла такая проблема. Может кто подскажет. Мой скрипт стал эпизодически останавливаться с ошибкой "attempt to perform arithmetic on a nil value". Сама ошибка понятна, но проблема заключается в том, что в этом сообщении не указывается номер строки, в которой эта ошибка произошла. Обычно при появлении таких ошибок в сообщении указывается и номер строки, благодаря чему можно найти ошибку и устранить. Я первый раз с таким сталкиваюсь. Есть ли какие-нибудь ещё способы определить строку, из-за которой эта ошибка произошла?
VPM написал: nikolz, Учебник мало прочитать, его еще необходимо понять. В моем "опусе", лишь краткие выдержки и не только из этого учебника, на что бы следовало обратить внимание по моему скромному мнению, начиная собирать торговую программу.
Цитата
VPM написал: Этот небольшой опус — попытка поделиться своим опытом и, возможно, помочь другим избежать ошибок или оптимизировать свой подход.
Если бы мне, еще пару - тройку лет назад сказали, обрати внимание на Метатаблицы и объектно-ориентированное программирование, я бы наверно "пальцем у виска покрутил" :: , сегодня это мой основной подход, леплю туда где можно и без него обойтись. А если бы прислушался к совету, сегодня бы не переписывал код, а использовал годами проверенный модуль. За ссылку спасибо, но лично у меня книга сохранена на компе, возможно кому понадобиться. Я лишь сделал пролог, к обсуждению универсальных модулей торговой системы, способной щелкать любые стратегии без изменений, ну или с минимальными изменениями в модулях.
Не в обиду будет сказано, но сначала изучают учебник. А Вы как я понял сначала начали писать что-то, а потом спустя 3 года начали читать. и о чудо, Вы наконец-то поняли то, что в учебниках про луа написано уже лет тридцать назад.
Александр Васильев написал: Доброго ! Пользуюсь скриптом QPILE , вывод по DDE в эксель , после расчётов выставляется и исполняется заявка . После 10.00.00 мск проблем нет . А до 10 . 00 учитывая раннее пробуждение ммвб ( 07.00 ) скрипт выдаёт не корректное время . Пример : 4 заявки в 09.55.11. и далее . 4 заявки после 10.00 мск всё поехало норм .В скрипте ошибок нет . Буду очень благодарен за мысли !!!
Вы неправильно преобразуете время число позиций до 10 часов на 1 меньше. Вы это не учитываете поэтому у вас выделяются не только цифры но и ":"
nikolz написал: При этом транслируется стакан, но не цена аукциона. Цена аукциона появляется когда ее сформируют. --------------------- Мое мнение: Цены аукциона в период аукциона еще нет, поэтому ноль. Когда она сформируется, тогда и появится в этом поле. Все верно? -------------------- Никакой ошибки в трансляции данного параметра нет.
Всё верно, только для акций и валют всё совсем не так. Почему-то именно для фьючерсов сделали иную трансляцию параметров, например, дисбаланс аукциона, объём аукциона, кол-во аукциона и пр. связанные параметры для валют и акций транслируются, а для фьючерсов их НЕТ, совсем нет - ни по итогам аукциона, ни во время, ни после. Почему так - мне никто не может ответить ни здесь ни на бирже.
Для акций аукцион давно, а для фьючерсов с этого года. Нигде не указано, что это должно быть. Возможно и для фьючерсов сделают. Но это не ошибка.
Анекдот: Вечер. Чел ищет что-то под фонарем. Прохожий - потеряли что-то? Чел - да, зажигалку потерял в подъезде дома. Прохожий - а почему ищите под столбом , а не в подъезде? Чел- там- темно, а здесь-светло. -------------------- Вы какой ответ хотите здесь получить? Брокер не хочет давать бесплатно - это его право. Вы не хотите платить - это ваше право. -------------
VPM написал: Собирая новую автоматическую систему, я поднимаю старые наработки, и довожу их до современного уровня понимания написания скриптов на Lua. Этот небольшой опус — попытка поделиться своим опытом и, возможно, помочь другим избежать ошибок или оптимизировать свой подход.
1) Основы Lua: таблицы как основа всего. Основная структура Lua — это таблицы. Именно из таблиц строятся все остальные конструкции языка. Таблицы в Lua — это не просто массивы или словари, а универсальный инструмент, который можно использовать для создания сложных структур данных. Если представить таблицу как отдельный модуль, то система становится четко структурированной. Например, можно создать таблицу, которая будет содержать данные и методы для работы с ними. Это позволяет разделять логику и данные, что делает код более читаемым и поддерживаемым.
2) Универсальные модули. Написав универсальный функциональный модуль, его можно использовать в разных скриптах. Например, модуль для работы с математическими расчетами или модуль для обработки данных можно легко интегрировать в различные проекты. Это экономит время и уменьшает количество ошибок, так как модуль уже протестирован и отлажен.
Код
Пример простого модуля: Модуль для математических расчетов
local MathUtils = {}
function MathUtils.add (a, b)
return a + b
end
function MathUtils.multiply (a, b)
return a * b
end
return MathUtils
Как можно использовать в других скриптах:
local MathUtils = require "MathUtils"
local result = MathUtils.add ( 5 , 3 )
print (result) -- Вывод: 8
3) Метатаблицы и объектно-ориентированное программирование. В Lua нет классов в классическом понимании, но есть метатаблицы, которые творят чудеса, позволяют создавать объектно-ориентированные структуры. Метатаблицы — это мощный инструмент, который позволяет определять поведение таблиц, например, перегрузку операторов или наследование. С помощью метатаблиц можно создавать объекты с методами и свойствами. Такой класс инкапсулирует всю логику, связанную с определенной задачей. Это позволяет изолировать код, упрощает его тестирование и повторное использование. Например, в торговой системе, можно выделить логику управления позициями, расчетов и генерации сигналов в отдельные классы.
Код
Пример класса для торговой системы:
local TradingSystem = {}
TradingSystem.__index = TradingSystem
function TradingSystem.new (params)
local self = setmetatable({}, TradingSystem)
self.length = params.length or 20
self.frac = params.frac or 5
self.pt_stop = params.pt_stop or 3
self.price = {}
self.smooth = {}
self.coef = {}
self.distance2 = {}
self.market_position = 0
self.entry_price = 0
return self
end
function TradingSystem:process_bar (index, high, low, open_price)
-- Логика обработки бара
end
-- Использование
local params = { length = 20 , frac = 5 , pt_stop = 3 }
local system = TradingSystem.new (params)
Делаем выводы по написанию скриптов на Lua. Lua — это мощный и гибкий язык, который отлично подходит для создания автоматических систем: 1. Используйте модули. Разделяйте код на модули по функциональности, чтобы упростить его повторное использование и тестирование. 2. Применяйте метатаблицы. Создавайте объектно-ориентированные структуры для инкапсуляции логики. 3. Документируйте код. Добавляйте комментарии и описание функций, чтобы код был понятен не только вам но и другим разработчикам. 4. Тестируйте. Проверяйте каждый модуль и класс отдельно, чтобы убедиться в их корректности. 5. Оптимизируйте. Убедитесь, что ваш код эффективен и не содержит лишних вычислений. Используя таблицы, модули и метатаблицы, можно создавать четко структурированные и легко поддерживаемые решения.
Надеюсь, этот небольшой опус поможет при создании новых проектов. Удачи!
Не в обиду будет сказано, но зачем рассказывать то, что лучше уже рассказано в учебниках. ------------------- Вот ссылка на хороший учебник по Луа. В нем на 400 страницах излагается подробно, что такое Lua и как на нем программировать. -------------------- https://eligovision.ru/media/upload/lua.pdf
При этом транслируется стакан, но не цена аукциона. Цена аукциона появляется когда ее сформируют. --------------------- Мое мнение: Цены аукциона в период аукциона еще нет, поэтому ноль. Когда она сформируется, тогда и появится в этом поле. Все верно? -------------------- Никакой ошибки в трансляции данного параметра нет.
Подскажите, кто, как решает или решил - "проблему" с авторизаций через СМС ? Ну то есть торговый день закончился, произошёл дисконнект, бот в работе, и ожидает данные, наступило утро и чтобы опять подключить Квик нужно проснутся получить СМС на телефон и ввести его ручками в КВИК.
Как то это не очень :)
Подключаем GSM модуль и вводим скриптом. Проще всего на Atoit, но можно на любом другом языке программирования.
В таблице текущих торгов имеется такой параметр как "Цена аукц.". Для акций и валют этот параметр во время проведения соответствующего аукциона (перед утренней сессией, перед/после дневной или перед вечерней) показывает расчётную цену сведения заявок, выставленных на аукционе, т.е. во время проведения аукциона при наличии на аукционе заявок эта цена всё время отображает какое-то значение (в большинстве случаев постоянно меняющееся до момента сведения). Для фьючерсов же почему-то цена эта во время проведения аукционов не отображается (в таблице она равна нулю) и начинает отображаться только после сведения, что не правильно. Я не знаю чья это недоработка - брокера или биржи или ваша - но очень хотелось бы исправить данную ситуацию. Подскажите возможно ли это и в чьей это зоне ответственности? Если это биржа так транслирует, то есть ли у вас возможность запросить изменение трансляции данного параметра? Сомневаюсь, что дело в брокере, поскольку у меня счета у нескольких брокеров и ситуация одинаковая.
Для фьючерса нет аукциона. Поэтому там и нули.
Вы не правы. Для фьючерсов есть аукцион - он проводится с 8-50 до 9-00 мск.
Дайте ссылку, где указано это. ----------------------- Мое мнение такое. Аукцион проводится для акций и Пифов и валют. Для фьючерса аукционов на московской бирже нет, так как цена фьючерса определяется ценой базового актива.
В таблице текущих торгов имеется такой параметр как "Цена аукц.". Для акций и валют этот параметр во время проведения соответствующего аукциона (перед утренней сессией, перед/после дневной или перед вечерней) показывает расчётную цену сведения заявок, выставленных на аукционе, т.е. во время проведения аукциона при наличии на аукционе заявок эта цена всё время отображает какое-то значение (в большинстве случаев постоянно меняющееся до момента сведения). Для фьючерсов же почему-то цена эта во время проведения аукционов не отображается (в таблице она равна нулю) и начинает отображаться только после сведения, что не правильно. Я не знаю чья это недоработка - брокера или биржи или ваша - но очень хотелось бы исправить данную ситуацию. Подскажите возможно ли это и в чьей это зоне ответственности? Если это биржа так транслирует, то есть ли у вас возможность запросить изменение трансляции данного параметра? Сомневаюсь, что дело в брокере, поскольку у меня счета у нескольких брокеров и ситуация одинаковая.
sandyman написал: Связался с биржей по этому вопросу, но одному человеку, простому клиенту брокера сложно продавить что-то на бирже. Обещали рассмотреть в качестве доработки, но надежды мало. Если найдётся кто-то, кому также важен формат трансляции данного параметра - напишите, пожалуйста, обращение на биржу help@moex.com
Можете дать ссылку, где указано, что для фьючерсов проводится премаркет и алгоритм вычисления цены аукциона фьючерса на Московской бирже.
Сергей написал: Всем спасибо. Avtoit скачал. Правда еще неизвестно много ли лучше будет просыпаться в двенадцать ночи от шума включившихся вентиляторов, а потом в пять утра вставать, считывать и обрабатывать информацию, чтобы успеть к утренней сессии, но сейчас хроническое недосыпание достало. Обиднее всего, что проблема возникла на пустом месте из-за того, что кто-то из программистов Quik доработал программу, возможно даже мимоходом, и сразу у разных брокеров данные таблицы "Торговля" перестали сохранять информацию предыдущего дня до начала следующей сессии. При этом они упорно не хотят исправить эту очевидную ошибку.
проще всего взять Excel и выключать QUIK по окончанию сессии. Для этого не надо ничего писать.
nmn написал: Anton Belonogov, сейчас в 19:40 настройки сохраняются в файл моментально, никаких замедлений, зависаний и прочее - вообще незаметно. Вы что-то предприняли, изменили? Версия 11.4.1.3, ещё днём настройки сохранялись с зависанием терминала на 20-30 сек...
Предположу, что потому-что дневная сессия завершилась. Потока данных нет.
еще можно использовать excel. Можно сделать экспорт таблиц в Excel, а в 23-50 закрывать либо Excel, либо QUIK. Закрывать можно либо планировщиком либо скриптом на луа.
Не в обиду будет сказано, но хотелось бы услышать не пересказ ликбеза их интернета , а конкретные данные из Вашего опыта. -------------- Начну со своего. ----------------- В настоящее время у меня есть вклад на 6 месяцев под 24.2%, есть вклад на 3 месяца под 23.2%, есть вклад накопительный под 19.2%, с которого можно снимать и класть любую сумму, а процент начисляется на остаток на конец дня . Вклады в разных банках (это как разные облигации) --------------- относительно налога. Ставка ЦБ сейчас 21%, т е налог равен нулю. ---------------- Относительно облигаций. Да, доходность по ним должна быть больше, чем по вкладу, за риск потерять деньги, который на рынке всегда больше, чем в банке. ----------------- Пример про доходность по облигациям Самолета не катит. Эта доходность не длительная, а краткосрочная с очень большим риском. ----------------- Для большего риска у меня есть торговля вечным фьючерсом, у которого плечо 5. Например вчера. Доходность за день, которую я смог забрать с рынка составила 4.5% в день. ========= Интересно было бы почитать про реальный результат торговли облигациями.
VPM написал: nikolz, Ну здесь то логика простая, Вы посмотрите на да ты погашения, то есть инвестиционный горизонт огромный. То есть фиксируем доход. Ну дело тут не в текущей доходности даже, а в чувствительности облигации к снижению ставки. То есть сегодняшние 16%, завтра 70% дадут, именно эту оценку я пытаюсь провести. Например, у меня получается, если дюрация облигации составляет 5 лет, то при снижении ставки на 1% цена облигации вырастет примерно на 5%.
Идея понятна. Но Вы не пробовали посчитать в сравнении с депозитом в банке и учетом сложного процента. Недавно читал статью в инете где говорится что высокие проценты по облигациям на длительный срок реально дают более низкий процент чем депозит если разложить эти процента по годам с учетом сложного процента.
VPM написал: На рынке сложилась уникальная ситуация! Акции как сжатая пружина, того и смотри, разожмётся и обгонит "биток" , за 2 месяца отыграна прошлогодняя просадка. Но мой взгляд прикован к облигациям, как "кролик на удава", я смотрю на них. Задача сводится зафиксировать часть доходности в инвестиционном портфеле.
Для анализа отобрал 4 длинных облигаций ОФЗ-ПД (облигации федерального займа с постоянным купонным доходом)
Код
Инструмент Номинал Доходность Размер купона Длит. купона НКД Дата выпл. куп. Дюрация До погашения Погашение Ср. взв. цена Оборот Коэфф. Выплат в год раз Годовой доход Купонный поток % От погашения к дюрации Кол. Шт. приобрести Инвестиция в одинаковое количество %
ОФЗ - ПД 26233 18 / 07 / 35 SUR 1000 15.76 30.42 182 4.35 30.07 . 2025 2437 3799 18.07 . 2035 53.148 967 , 621 , 780 1.9 2 61 р. 36 , 504 р. 11.45 % 1362 600 318 , 888 р. 1.50 900 54 , 753 р. 11.45 %
ОФЗ - ПД 26238 15 / 05 / 41 SUR 1000 15.27 35.4 182 15.95 04.06 . 2025 2658 5927 15.05 . 2041 53.254 1 , 751 , 734 , 568 1.9 2 71 р. 42 , 480 р. 13.29 % 3269 600 319 , 524 р. 1.50 898 63 , 590 р. 13.29 %
ОФЗ - ПД 26243 19 / 05 / 38 SUR 1000 15.78 48.87 182 22.02 04.06 . 2025 2330 4835 19.05 . 2038 69.341 1 , 084 , 655 , 642 1.4 2 98 р. 58 , 644 р. 14.10 % 2505 600 416 , 046 р. 1.15 690 67 , 420 р. 14.10 %
ОФЗ - ПД 26248 16 / 05 / 40 SUR 1000 16.42 61.08 182 27.52 04.06 . 2025 2264 5563 16.05 . 2040 79.718 1 , 820 , 239 , 989 1.3 2 122 р. 73 , 296 р. 15.32 % 3299 600 478 , 308 р. 1.00 600 73 , 296 р. 15.32 %
Наиболее доходная облигация: ОФЗ-ПД 26248 16/05/40 с доходностью 16.42% и годовым доходом 122 рубля. Наименее доходная облигация: ОФЗ-ПД 26238 15/05/41 с доходностью 15.27% и годовым доходом 71 рубль. Наибольший купонный поток: ОФЗ-ПД 26248 16/05/40 с купонным потоком 73,296 рублей. Наименьший купонный поток: ОФЗ-ПД 26233 18/07/35 с купонным потоком 36,504 рублей.
Вывод: В целях — максимизация дохода, то ОФЗ-ПД 26248 16/05/40 является наиболее привлекательной. Если важна меньшая дюрация и меньший срок до погашения, то ОФЗ-ПД 26233 18/07/2035 может быть предпочтительнее.
Но в штопор вводит, ожидаете понижения ключевой ставки ЦБ РФ, то есть облигации с большей дюрацией и более длительным сроком до погашения будут более выгодны, так как они сильнее реагируют на изменение ставок. То есть наиболее выгодной становится облигация ОФЗ-ПД 26238, так как имеет более высокий потенциал роста благодаря большей дюрации. Ну и как тут быть? Как в штопор не впадать?
В банке вклад с доходностью 24%. В чем фишка брать облигации с доходностью 16%?
Кирилл написал: Могут ли программисты пояснить, для чего нужен ОТРИЦАТЕЛЬНЫЙ объем торгов? ( -500 000; - 1 000 000, доводилось видеть и -2 000 000) См. скриншот:
Также, пару лет назад была указана еще одна проблема отображения таблиц:
Округлялась дробная часть. Это касалось только графиков ФосАгро и Норникеля. Наконец-то, Норникель починили. А с Фосагро надо, наверное, еще несколько лет подождать.
alex24 написал: Я так понимаю что половина всех валяющихся платных скриптов для терминала - дело рук самих разработчиков QUIKа иной причины, кроме подобного рода конфликта интересов, я и представить себе не могу. Рассчитывал что буду пользоваться софтом, но почитал форум, посмотрел программу (юзерфрендли интерфейс прямиком из 96-го года намекает что софт пишется одним человеком на коленке в выходные дни). Это все конечно шутки и ирония. Пользоваться не стану и никому не посоветую просто из-за отношения разрабов к потребностям и просьбам пользователей. Очень грустно что комьюнити такое терпеливое. Могли бы проголосовать ногами (уйти в другие торговые системы оставив разрабов думать, что не так и как следует выстраивать взаимодействие с пользователем, а то видите ли больно умные эти пользователи и базовый функционал требуют!)
Приведите пример других торговых терминалов для российского рынка.
Anton Belonogov, Вы читали сообщение биржи, что на рынке более 30 млн частных инвесторов. --------------------------- Вместо того, чтобы сделать подробную инструкцию к вашей поделке для разных систем, Вы решили издеваться над ними, заставляя делать миллионы человек одни и те же действия по копированию строк из вашего творения? --------------------------------- Вам не совестно это предлагать? ------------------- Cделали поделку -сделайте подробную документацию, а не предлагайте костыли. -------------------- Экономьте электроэнергию и берегите природу.
Это как через зад смотреть гланды. Очень увлекательно для разработчиков, но непонятно для пользователей. -------------------- У Вас в приложении в документации QUIK приведены названия параметров на русском языке (зачем эти названия на русском?), а на англ написать эти названия никто не догадался за 25 лет существования QUIK?
unikum33 написал: update: залогинился в субботу, торгуется только LQDT от ВТБ брокера. Даже при отсутствии торгов загрузка ЦП 5%. Получается, что именно открытые графики дают нагрузку ЦП? Или может быть то, что они выведены на отдельный монитор(с зажатым ctrl)?
__spb13__ написал: Добрый день, Скрипт вызывается из окна "Доступные скрипты". В скрипте все как обычно: получаю цену, открываю заявку. Но, и цена и заявка срабатывают только если в таблице "Текущая таблица параметров" выбран инструмент соответствующий инструменту заданному в скрипте. Что это, такое запрограммированное поведение Quik? Или все-же существует метод как получить цену и открыть заявку без какой-либо связки скрипта с окнами инструментов?
Можно использовать колбек Onparam. этот колбек вызывается , когда приходят какие-либо изменения в ТТП Например, совершилась сделка или изменились лучшая цена в стакане. При этом Вы получаете код инструмента и можно прочитать текущую цену этого инструмента и решить выставлять или нет заявку или изменить положение стоп-заявки
VPM, Возможно Вы это знаете, но я просто напомню. Данные в терминал приходят блоками. Если Вы используете высокоточный счетчик ПК для измерения времени (дискретность 0.1 мкс) то обнаружите, что одновременно могут прийти десятки сделок между которыми сотни миллисекунд. ----------------------- Есть данные, которые рассылаются биржей в широковещательном режиме. Они рассылаются с интервалом сотни миллисекунд. ========================== Кроме того, если вы не в дата центре и не в Москве, то задержка получения данных с биржи будет примерно 50 ms. ---------------------------- Все это создает запаздывание данных с биржи и на биржу порядки сотен миллисекунд. ======================= Меня интересует быстродействие скриптов не для того, чтобы посылать 1000 заявок по одному инструменту, а для того, чтобы максимально быстро прогнозировать изменение цены по 1000 инструментам, чтобы отправить заявку по каждому из них не более, чем за 1 секунду.
Alexander, Не стремлюсь Вас в чем-то убедить или спорить с Вами. ------------------------- Рассказал Вам свой опыт, так как Вы задали вопрос на форуме. ------------------------------------ Делайте как хотите.
nikolz написал: Возможно не понял, но полагаю что Вы ошибаетесь.---------------------------Синхронизировать потоки надо при обращении их общим данным. -------------------------Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать.--------------------------DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду.-----------------------Не надо синхронизировать потоки при обращении к константам.--------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
Да не поняли. Теорию знаю. По DLL тоже, и что и как там и в каком контексте работает, и переменные общие и т.п. Мне синхронизировать нужно работу вывода в консоль. Функции принтов есть в DLL и есть варианты, чтобы они разным цветом печатала в консоли есть функции и для скрипта - для захвата секции и много там ещё чего разного. Даже например внутри одного квика, допустим один поток колбэк выводит в консоль цветной текст - своим цветом последовательно по ходу работы функции принт за принтом. Далее этот поток прерывется и запускается другой поток, который тоже последовательно выводит в консоль своим цветом принт за принтом по ходу работы его функции. Что будет? Будет каша разноцветных принтов в перемешку, да ещё и цвета возможно сбиваться будут. Общие данные - захват консоли на время работы функций потока. Консоль и есть общий ресурс. Функции колбэка быстрые и захватывают консоль в начале функции и освобождают в конце, весь их вывод в консоль одним цветом получается, для каждого колбэка свой цвет, другой поток ждёт и не может ничего вывести пока колбэк не отработает полностью. Т.е. даже когда прерывается поток колбэка и запускается основной - это не страшно, основной кашу не сделает, ибо ждёт, потом возврат в колбэк и он продолжает свой цветной вывод своим тем же цветом. Отработал отпустил. Потом уже основной поток может продолжить и печатать своим цветом. У основного потока каждый принт - захват и освобождение консоли для своего цвета принта через захват секции(не в начале и в конце функции(как у колбэка) в которой принты основного потока - так можно бы было, но кое где логика не позволяет ибо ждёт результата колбэка и можно зависнуть, когда один захватит секцию и ждёт данных от колбэка, а колбэк не может захватить секцию, либо не логика, а просто нельзя тормозить надолго всю функцию основного потока по захвату консоли, ибо колбэки хрен тогда отработают, поэтому захват только на время работы одного принта основного потока). При таком построении каждый колбэк отписывает в консоль своим цветом даже если его прерывают, ну и основной поток спокойно себе печатает своими цветами и не пересекаются их выводы с выводами колбэка. Без этого такая каша, что даже выводы разных колбэков пересекаются, не что что с принтами основного потока и такое читать просто жопа.
Вы плохо изучали теорию. Повторю еще раз. Синхронизируют не код, а общие данные. Функция принт - это код. --------------------------- Зачем Вы выводите в консоль? Выводивыводите в лог файл и будет вам счастье. Лог файл позволяет анализировать ошибки и логику выполнения программы при длительном тестировании софта. Например , тестировал скрипт на QUIK 6 часов. При интенсивном потоке данных или длительном тестировании от консоли мало толку. ------------------------- Чтобы при выводе на консоль ничего не съедалось надо ставить задержку после оператора вывода. Обычно sleep(10) достаточно. -----------------------
nikolz написал: мьютексы излишне использовать, так как всего два потока.Ранее уже говорил, что это решается гораздо проще через Event.
Если рассматривать вариант использования только одного экземпляра квика, то да. Но вот у меня, например, на данный момент рабочих целых 4 варианта самостоятельных квиков. Все они используют в работе всегда одну и ту же DLL, которая обеспечивает мне консоль для вывода, ну и разные функции для работы с этой консолью, в том числе и цветной вывод. Для цветного вывода хош-не хош нужна синхронизация, иначе всё идёт в перемешку, хоть и разным цветом, что очень неудобно воспринимать, хотя и можно смириться с этим, но я решил не мириться. Так вот, коли 4 квика, то по сути это уже и 4 разных процесса. И поэтому либо мьютекс нужен, либо быстрая критическая секция. Но секция одна на разные процессы не пойдёт. Я выбрал для себя в реализации именно секции, но приходится хранить массив из секций (для каждого потока своя секция), которые инициализируются при подключении процесса в DLL. Сейчас всё работает как положено. Ну пришлось чуток добавить кода, но оно того стоит думаю.
Возможно не понял, но полагаю что Вы ошибаетесь. --------------------------- Синхронизировать потоки надо при обращении их общим данным. ------------------------- Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать. -------------------------- DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду. ----------------------- Не надо синхронизировать потоки при обращении к константам. --------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
АлексейМ написал: Попытался подключить самодельный индикатор. Индикатор не запускается, выдается сообщение об отсутствии lua-модуля. Посмотрел в папке Квика как указано было в пути ошибки - там нет таких файлов и папок с именем lua. Где их брать непонятно и как их устанавливать тоже. И почему их нет тоже непонятно.
VPM написал: nikolz, Да Вы совершено правы, я лишь хотел подчеркнуть особенность подключения
Цитата
VPM написал: Функция dofile выполнит Lua-скрипт, и все переменные и функции, определённые в нём, будут доступны в текущем окружении. И смысл здесь в подключении новой задачи!
Ведь есть еще способ local Utility = require("Utility").
require - это способ подключения готовых (не собственных) библиотек в том числе на С. Но при этом вы не можете передать в из них данные через глобальный стек. ------------------- Повторю свое мнение. dofile -не для подключения новой задачи, а для разделения длинного скрипта на отдельные куски, чтобы было проще читать и отлаживать. --------------------- Аналогия на книжках примерно такая: подключение библиотек с помощью require - это как сборка коллекции различных книг. а применение dofile - это как сборка книжки их листов.
VPM написал: nikolz, Не совсем понял Ваш вопрос? Применяя Вашу аллегорию, можно пояснить смысл. Если выпитый стакан вчера был с алкоголем, сев сегодня за руль, и подышав в трубочку представителю закона, результат выявлен. Так и в нашем случае, данные какие получили такие и есть. А задача подхода оценить кто заправляет в стакане, деля резултат алгоритма на 3 категории покупатель, продавец или нейтрально. Могу добавить что этот модуль, только часть большей задачи. Стакан это настроения, выставляя лимитки мы подменяем ММ и говорим о намерениях, рынок двигают рыночными ордерами это и оцениваем. В большой задаче, примерно также оцениваю Спрос/Предложение, и Настроение на рынке. Сейчас задача объединить анализ настроений с анализом сделок, в сделках уже есть время сделки.
Попробую пояснить. Недавно написал по заявке робота для торговли в стакане. Алгоритм простой, но по уверению заказчика работает эффективно. ----------------------------- Кроме того, использую стакан для торговли вечными фьючерсами. Из своего опыта, который не противоречит публикациям различных гуру в интернете, стакан - это инструмент скальперов или HFT роботов, ----------------------------------- По стакану нельзя ничего прогнозировать на завтра. Вы же применяете правило Фишера (непонятно зачем) и еще пытаетесь делать какую-то обработку статистики. Статистика - это всегда накопление данных и их усреднение. --------------------------- Вот я и спросил Вас, а Вы уверены, что Ваша статистика актуальна. -------------------------- Стакан, выпитый вчера, с похмелья не поможет. -------------------------------- Я обычно любую идею или алгоритм торговли сначала исследую на исторических данных, а потом лишь решаю применять или нет. ---------------------------- Вы можете доказать, что написанное Вами имеет практический смысл?
VPM написал: В стратегии реального времени, для автоматической торговли, в системы принятия торговых решений внес изменения, добавил использование данных о ликвидности в стакане. Давно "руки чесались", алгоритм не сложный, но мест где наделать ошибки достаточно. Вкратце следующий, получаем данные о ликвидности из стакана, проводится нормировка для преобразования к нормальному распределению, выделяем пиковые значения с помощью преобразования Фишера, создаем правила на основе нечеткой логики . Думаю еще прикрутить правило 3 сигм для стабилизации результатов, но пока без сигм покручу нужно добиться стабильности. Пока хорошей торговли!
Не критики ради, а дискуссии для. Полагаю, что Вы это делаете для торговли в реальном времени. Данные в стакане меняются существенно быстрее чем совершение сделок. Можете доказать, что предлагаемые вами расчеты данных по стакану являются актуальными в момент принятия решения? Иначе получится так, что решения сегодня принимаются по выпитому стакану вчера. Не актуально.
nikolz написал: И еще...Нет смысла запускать скрипты с помощью dofile (особенно как в приведенном VPM примере)Так как это лишь замедляет исполнение.---------------dofile имеет смысл применять для разделения большого скрипта на блоки, чтобы упростить чтение и отладку скрипта.
nikolz, Пример выше это просто демонстрация возможностей, ни на что не претендующая. К примеру у себя использую следующий вариант (кусочек из рабочего код):
Код
-- Пытаемся загрузить библиотеку
local fuzzy;
local success, err = pcall(dofile, path .. '\\luafuzzy.lua')
if not success then
Log:error( "Ошибка при загрузке файла luafuzzy: " .. err)
else
-- Если библиотека успешно загружена, используем её
local fuzzy = luafuzzy()
Log:info( "Библиотека luafuzzy успешно загружена!" )
end
while WORKING_FLAG do
Перед основным циклом while WORKING_FLAG do 1 раз вызываем "Пан или пропал!" :: , ни чего не замедляем, просто Функция dofile выполнит Lua-скрипт, и все переменные и функции, определённые в нём, будут доступны в текущем окружении. И смысл здесь в подключении новой задачи!
Вообще-то загрузка библиотеки и запуск скрипта в вашем примере это две большие разницы. Поясняю. Загрузка библиотек делается как правило один раз при запуске скрипта. Это необходимая операция, так как библиотек много разных и разумно не изобретать велосипед, а использовать готовый. Так как загрузка изначально и однократно, то не имеет значение время загрузки. ----------------------- В вашем примере Вы грузите и запускаете скрипт не однократно, так как используете флаг загрузки. Но нет смысла грузить и запускать скрипт т. е. многократно его грузить. Я через dofile загружаю свои библиотеки функций с целью разделить большой скрипт на части и отлаживать эти части отдельно. Фактически это вариант создания библиотеки, с упрощением обмена данными через глобальный стек.
Станислав написал: В скриптах используются всего 2 потока , один для колбэков и один в main.
В main для каждого скрипта создается отдельный поток, а вот колбэки находятся в некой очереди и вызываются синхронно, т.е. каждый колбэк ждет возвращения управления перед вызовом следующего.
Из-за этого имеем 2 особенности: 1. Нет нужды синхронизировать колбэки. 2. Надолго блокировать или производить тяжелые расчеты в колбэках не стоит, это приводит к подвисанию всех скриптов и даже терминала.
Если я ошибаюсь, поправьте.
немного поправлю. Для колбеков не создается специально новый поток. Колбеки вызываются в VMLua, которая создается в основном потоке терминала QUIK. --------------------------- Функция main запускается в отдельном потоке, в котором создается VMLua, дочерняя к VMLua колбеков.
Да похоже как-то так и есть. Факт только один - надо синхронизировать поток main() с потоком колбэков, кто бы его не запускал. Можно конечно поюзать всякие процесс мониторы и т.п., посмотреть процессы и их потоки, но и так понятно по вызовам стало, что main() и колбэки живут в разных потоках и что колбэки вызываются последовательно. Всем спасибо за ответы.
мьютексы излишне использовать, так как всего два потока. Ранее уже говорил, что это решается гораздо проще через Event. ------------------ Прикольно, что недавно реализовал работу этих потоков без элементов ОС синхронизации. Работает существенно быстрее даже относительно Event.