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.
Станислав написал: В скриптах используются всего 2 потока , один для колбэков и один в main.
В main для каждого скрипта создается отдельный поток, а вот колбэки находятся в некой очереди и вызываются синхронно, т.е. каждый колбэк ждет возвращения управления перед вызовом следующего.
Из-за этого имеем 2 особенности: 1. Нет нужды синхронизировать колбэки. 2. Надолго блокировать или производить тяжелые расчеты в колбэках не стоит, это приводит к подвисанию всех скриптов и даже терминала.
Если я ошибаюсь, поправьте.
немного поправлю. Для колбеков не создается специально новый поток. Колбеки вызываются в VMLua, которая создается в основном потоке терминала QUIK. --------------------------- Функция main запускается в отдельном потоке, в котором создается VMLua, дочерняя к VMLua колбеков.
И еще... Нет смысла запускать скрипты с помощью dofile (особенно как в приведенном VPM примере) Так как это лишь замедляет исполнение. --------------- dofile имеет смысл применять для разделения большого скрипта на блоки, чтобы упростить чтение и отладку скрипта.
Станислав написал: Ну вы конечно очень глубоко копнули, а человек спросил просто можно ли одним скриптом в окне "доступные скрипты" перевести второй скрипт из состояния "остановлен" в состояние "запущен".
Штатными средствами сделать этого нельзя. Понятно что имея возможность запускать любой код в подключаемых библиотеках можно сделать вообще все что угодно , однако это не будет хорошим решением.
Задача решается с помощью механизма Event (ранее об этом говорил как альтернатива использования sleep в main).
Saturn написал: Возможно ли с помощью одного скрипта запустить другой ?
Полагаю, что вопрос не о запуске lua функций из файлов, а именно скриптов QUIK на основе библиотеки QLua так как это две большие разницы. ------------------------ Запуск функций из файлов с помощью dofile в вызывающем их потоке. Т е сколько бы функций не запустили будет основной поток с колбеками и поток main. ------------------------- При запуске скриптов QUIK будет создаваться новый поток main. Таким способом можно запустить столько потоков сколько хочется. ------------------------------ Сделать это можно.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
nikolz написал: еще проще сравнивать время свечи и текущее время компа.
Тоже не вариант, так как свечи могут приходить немного с опозданием и в итоге на границе времени интервала - эти свечи будут отбрасывается.
Вы ошибаетесь. В любом случае свечи истории - это свечи прошедших торговых дней. и как минимум не могут быть в предыдущем отсчете.
В чем же я ошибаюсь то :) Это факт - онлайн свечи могут приходить с примерно с 3 секундной задержкой. Вчерашний пример который я заметил на тестировании: 3 минутная свеча:
-время пришедшей свечи в callback 20:00, время сервера 20:01:34 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:02:47 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:03:02 (ТОЛЬКО ЧТО Пришедшая свеча все еще находится в 3 минутном диапазоне с 20:00:00 - 20:02:59 ,НО время сервера уже вышло из этого диапазона, то есть Квик или сервер брокера прислал запоздавшую сделку на несколько секунд, и если сравнивать это временем сервера, то получается, что эта сделка относится к исторической свече, хотя по факту - эта последняя онлайн сделка присланная с сервера)
Так что повторю без всяких ошибок: К сожалению Тоже не вариант, так как свечи могут приходить немного с опозданием и в итоге на границе времени интервала - эти свечи будут отбрасывается.
Поясняю. Запоздалыми свечи не бывают. сервер не может прислать Вам предыдущую свечу, если он Вам уже присылает текущую свечу. Запоздалыми бывают обезличенные сделки, когда Вы их либо начинаете принимать либо допринимаете после разрыва. И это происходит лишь тогда, когда этих сделок очень много. Относительно свечей такого быть не может в принципе. Сервер всего хранит 3000 свечей и он их Вам будет посылать, если Вы все стерли в архиве или подписались на совершенно новый инструмент или новый тайм, которого у вас не было раньше. ---------------------------- В остальных случаях. Все свечи истории уже есть в вашем архиве, либо их относительно мало и они догрузятся одним несколькими пакетами буквально за секунды. ------------------------ Перейдем к Вашим примерам: ---------------------- -время пришедшей свечи в callback 20:00, время сервера 20:01:34 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:02:47 (пока все нормально, треxминтная свеча укладывается в диапазон сервера с 20:00:00 - 20:02:59, поэтому эта свеча считается онлайн) -время пришедшей свечи в callback 20:00, время сервера 20:03:02 (ТОЛЬКО ЧТО Пришедшая свеча все еще находится в 3 минутном диапазоне с 20:00:00 - 20:02:59 ,НО время сервера уже вышло из этого диапазона, то есть Квик или сервер брокера прислал запоздавшую сделку на несколько секунд, и если сравнивать это временем сервера, то получается, что эта сделка относится к исторической свече, хотя по факту - эта последняя онлайн сделка присланная с сервера) ------------------ Вы ошибаетесь. Это не время пришедшей свечи. Это время пришедшей сделки. Если свеча в момент пришедшей сделки не закрыта, то это текущая свеча, вне зависимости от времени сервера. Но если Вы проверяете время сделки, а с временем текущей свечи. Собственно параметр Size и позволяет определить есть новая свеча или это текущая.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
не уверен, но у сбера цена имеет 2 знач десятич знака , должно быть 270.00 -------------- Но лучше покажите как это записано в скрипте. ------------- Кроме того должно быть сообщение уточняющее причину ошибки ( в колбеке OnTransReply )
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
Saturn написал: Подскажите пожалуйста, вот я вызываю SetUpdateCallback - предположим по Газпрому по дневному интервалу и в колбек начинают приходить данные, но сначала приходят исторические данные, а не реальные онлайн изменения цены сделки. И вот вопрос: а как мне тогда определить, что данные которые начали приходить в колбек - уже реальные изменения цены купли/продажи - чтобы я на них реагировал, а не исторические данные ?
Использовать счетчик свечей не предлагать - так как он естественно работать не будет: потому что ну пришел индекс последней Дневной свечи к примеру 100 датированная сегодняшним днем, начала пришли за половину дня исторические данные, а потом начали приходить онлайн изменения - НО индекс свечи все равно будет тот же - так как день еще не прошел.
используйте OnParam или OnAllTrade
Не хочу, у меня уже настроено все под SetUpdateCallback - вот только единственная проблема есть описанная. С OnParam или OnAllTrade - есть еще большая проблема - потому что там нужно самому формировать данные в интервалы, а это вообще капец неудобно, потому что нужно учитывать ночные переходы времени, выходные, праздники - геморрой короче один только.
Вы не поняли. OnParam или OnAllTrade использовать для определения, что приходят реальные данные, а не исторические.
SetUpdateCallback - как определить что начали приходить Не исторические данные., SetUpdateCallback - как определить что начали приходить Не исторические данные.
Saturn написал: Подскажите пожалуйста, вот я вызываю SetUpdateCallback - предположим по Газпрому по дневному интервалу и в колбек начинают приходить данные, но сначала приходят исторические данные, а не реальные онлайн изменения цены сделки. И вот вопрос: а как мне тогда определить, что данные которые начали приходить в колбек - уже реальные изменения цены купли/продажи - чтобы я на них реагировал, а не исторические данные ?
Использовать счетчик свечей не предлагать - так как он естественно работать не будет: потому что ну пришел индекс последней Дневной свечи к примеру 100 датированная сегодняшним днем, начала пришли за половину дня исторические данные, а потом начали приходить онлайн изменения - НО индекс свечи все равно будет тот же - так как день еще не прошел.
Nikolay написал: Да, оба терминала версии 11.4.0.54
ip адрес у Вас один. Очевидно приходит пакет в два терминала. Другой клиент не придет. Разработчики не учли, что у одного брокера можно открыть два счета и для каждого отдельный терминал. Я полагал, что два терминала на один IP не имеет смысла. По идее один терминал должен работать с несколькими счетами. А так прикол нормальный.
Михаил Понамаренко написал: Брокер ВТБ. Если QUIK был запущен ранее,то с началом утренней сессии, выставление заявок на срочном рынке недоступно. Проблема решается отключением/подключением сервера QUIK.
Данная проблема возникает примерно раз в неделю. Но. очень неудобна, т.к. QUIK работает круглосуточно на удалённом сервере. Роботы не могут совершать сделки на срочном рынке. Впервые была замечена после открытия ИИС. У других брокеров такой проблемы не наблюдаю.
Думаю, как временное решение, перезапускать или переподключать QUIK каждое утро через скрипт или планировщик. Но этот "костыль" применять не хочется.
Что делал? 1. Менял все доступные сервера ВТБ. 2. Экспериментировал с настройкой "Очищать данные при смене даты" на "Локальной машине", на "Сервере". 3. Проверял настройку счетов. Все счета добавлены (также при недоступности торгов на срочном рынке) 4. Переустанавливал QUIK, загрузив файл настроек .wnd. 5. Писал в поддержку ВТБ, обещали решить ещё месяц назад, но проблема не решена.
Просьба помочь с решением проблемы.
Идея такая: Можно разорвать соединение ПК с интернетом(не терминала) вместо перезапуска. Потом соединение ПК восстановить. КВИК автоматом должен восстановить соединение с сервером . При этом обычно не требуется повторная авторизация.
На сервере QUIK-Junior заявок с таким параметром нет.
Конкретный пример затруднимся привести, однако если параметр доступен для заявки, можно сформировать транзакцию ввода заявки с этим параметром в "Кармане транзакций" и сохранить ее описание в tri-файл.
А как узнать что параметр доступен? Где об этом написано? Какой инструмент или рынок допускает этот параметр? Кроме метода тыка в тысячи инструментов, есть еще какой-то способ?
Время окончания срока действия заявки может быть задано, если торговая система предоставляет такую возможность для данного типа заявок. В таком случае параметр может быть установлен на форме ввода заявки в терминале, либо передан в строке с описанием транзакции.
Можете показать конкретный пример как записать и указать для какого инструмента это можно сделать на демо или в реальных торгах?
Время окончания срока действия заявки может быть задано, если торговая система предоставляет такую возможность для данного типа заявок. В таком случае параметр может быть установлен на форме ввода заявки в терминале, либо передан в строке с описанием транзакции.
Нигде не нашел конкретное описание и установку данного параметра ------------------------ В документации по QUIK параметр указан на русском языке : Время истечения=124141 ------------------------ В документации по QLua аналогичный параметр есть лишь в описании таблицы заявок :
expiry_time
NUMBER
Время окончания срока действия заявки в формате <ЧЧММСС DESIGNTIMESP=19552>. Для GTT-заявок, используется вместе со сроком истечения заявки (Expiry)
---------------------- Просьба объяснить каким образом установить данный параметр на Lua и при ручном вводе заявки. Если это есть в документации, то дайте ссылку.
VPM написал: nikolz, Все я прекрасно понял. Смею предположить, Ваши торговые стратегии, видимо не выходят за пределы технологий "скальпинга", отсюда и кругозор. Выше Вы опубликовали участников заключивших договора, Вам наименования организаций не о чем не говорят? Именно они гоняются за тиками? Вы просто посмотрите на ликвидность в стаканах, и на финансовые возможности компаний обеспечивающих эту ликвидность. Что делать с остальными финансами? Могу предположить, что под скапинг выделяется не большая доля активного капитала на котором и крутятся HFT-алгоритмы, выдели 1% а что делать с 99% средств? Кстати, на эту же проблему эффективности, натолкнулся у себя в своих среднесрочных стратегиях, суть в следующем: есть 100% торговый капитал, по правилам риск менеджмента активный не более < 25%, что означает > 75% т. капитала лежит просто в обеспечении сделки, не плохо бы часть покрутить в скальперских стратегиях. Касаемо придумок все за долго до меня, стратегии опубликованы, на классику жанра указал выше. И никаких кличек, терминология применяется разная но это для упрощения в пониманиях, сегодня модная есть "смарт мани", там своя, у классиков своя, Суть одна. Касаемо следов не только на ценовых графиках отслеживаются, но часто в стакане, такой объем можно видеть, так как рассчитываемся по определенным правилам для данного эмитента то есть алгоритмический. Такие объемы определяются, и от них строятся разные стратегии. Платная услуга биржи, это не признак ММ, это один из источников дохода ММ. Даже мне раньше прилетало от биржи.
Не надо переходить на личности. Вы не угадаете , какими стратегиями я занимаюсь. смею заверить Вас, что все что Вы написали на форуме, как некоторое открытие для вас я изучил примерно 20 лет назад и все это уже применял в своих стратегиях. Я вам пытаюсь сказать что термин "маркет-мейкер" никак не связан ни со стратегиями ни с тиками ни с HFT Он связан лишь с оказанием услуг бирже. И ВСЕ --------------------- В той таблице, которую я вам привел с сайта биржи есть брокер БКС . Вы полагаете что БКС гоняется за тиками и поэтому Вы его называете ММ? ----------------
VPM написал: nikolz, Все это верно, это не предмет обсуждения. ММ это прежде всего коммерческий проект, целью которого является извлечение прибыли, как и любой другой коммерческой организации. Обладая значительными средствами, набирают большие позиции которые, оставляя следы на графике, а значить могут повести рынок за собой или держать его в диапазоне. Это интересует трейдера, отвечая на вопрос в какую сторону держать позицию, и уж совсем не интересно сколько заработал ММ. Именно это поведение как крупного игра их отличает. Вы можете даже конкретные алгоритмы найти в сети. Обладая дополнительной информацией они строят свои торговые стратегии, свой бизнес.
Вы не поняли. Я утверждаю, что понятие (кличка) "MM" связано лишь с оказанием платных услуг биржи. Это никак не связано ни со следами, ни с размером ни с чем другим . Если игрок не оказывает платные услуги бирже, то он не ММ. ---------------- Вы напридумывали кучу признаков для ММ, а реально существует лишь один - платная услуга бирже.
VPM написал: nikolz, На форуме существует некая путаница в понятиях, и Вы не первый кто рассуждая о Маркет - мейкерах, упрощает их деятельность или сравнивает их с некими злодеями Крупными игроками занимающихся манипуляциями рынков. На фондовых биржах это крупные инвестиционные банки (например, Goldman Sachs, Morgan Stanley) как Вы думаете их интересуют сделки в один тик? На разных рынках по разному, задачи и техники принципиально одни. Отслеживая сделки на рынке в целях выявления крупных сделок для лучшего понимания ситуации и реализации в системах принятия решений, делю игроков условно на 3 категории: 1) Крупный игрок 2) Маркет-мейкер 3) Ретейл. Различие в поведении в торгах! имелось в виду именно это, поэтому подробно подчернил технический аспект. Касаемо ММ, хотя это специализированная участник, компания или и.банк, обязанные соблюдать строгие регуляторные требования, они тоже совершают ошибки. Давайте представим ситуацию набрана огромная позиция, а рынок пошел против, что на весах, штраф если заметят, или манипуляция во спасение добра. И таких ситуаций множество. И это только моя точка зрения в основе которой, методологии Ричарда Вайкоффа (Wyckoff) с его композитным игроком, решения как считать каждый принимает сам.
Я лишь рассказал кто такие ММ на московской бирже. На сайте биржи есть все условия и тарифы сколько и за что биржа платит. не имеет значение какой ММ крупный или мелкий. ММ - это тот, кому платит биржа за игру на бирже. ММ оказывает платную услугу бирже - это главное. Всем остальным биржа оказывает платную услугу. Все остальные признаки игроков -большие маленькие банки не банки , никакого отношения к понятию ММ не имеют
Добрый день, В формате таблицы "Заявки" есть параметр
expiry_time
NUMBER
Время окончания срока действия заявки в формате <ЧЧММСС DESIGNTIMESP=19552>.
Нигде не смог найти как этот параметр установить. На демо сервере его установка никак не проявляется. При ручном вводе заявки не увидел данного параметра. Кто может пояснить, возможность его применения.
Acaw написал: А есть где почитать и главное увидеть элементарный пример постановки коллбека в очередь, в интернете именно такого примера не нашел. Могу только предположить, что в коллбеке поступившие данные пишутся в массив, который обрабатывается в main.
Куда же сохранять информацию о сделках, заявках, если не в файл. В терминале ее на следующий день нет, а мне важно понимать когда именно возникла позиция, от этой задачи все и пошло. Могу предположить, что в какую-нибудь базу данных, но это же тоже файл.
Можно ли обойтись перебором таблиц если предположить, что в реальной ситуации более 1000 сделок в день не будет.
И самое главное по поводу таблиц, запоминания и скорости. Пока я делаю так - в текстовый файл пишу номера ордеров сделок, затем когда перебираю таблицу сделок беру в рассмотрение те номера, которых нет в файле, но таблица сделок перебирается вся.
Я писал на форуме элементарные колбеки, которые использую сам. Использую лишь те колбеки, которые необходимы для данной задачи.
примеры:
Код
function OnClose() fconnect=nil end
function OnConnected(flag) fconnect=1; end
function OnDisconnected() fconnect=1 end
function OnStop(flag) fconnect=nil;return 2000 end
Код
function OnTransReply(t)
local stat=t.status; if stat<2 or stat==3 or sta==15 then return; end
local c,s=t.class_code,t.sec_code;
if c~=c_old or s_old~=s then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then -
local id=t.trans_id;
local tt=ts[1]; del_trans(tt,id,M);
tt=ts[2]; del_trans(tt,id,M);
end
end
Код
function OnTrade(t)
local c,s=t.class_code,t.sec_code; if c~=clas or sec~=s then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then tpr[Ntp]={Trade,t,tc,ts} EvSet(event); end
end
Код
function OnOrder(t)
local c,s=t.class_code,t.sec_code;
if c~=c_old or S~=s_old then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then
local tt=ts[1]; local num=t.order_num; local id=t.trans_id;
local M=tt[0]; if M<0 then M=-M; end
local i=0 while M>i do i=i+1; if tt[i]==id then break; end i=i+1 end
if t.flags&1==1 then if M==i then Nor=Nor+1; tt[i]=Nor; end
else tt[i]=nil; end
Ntp=Ntp+1; tpr[Ntp]={Order,t,tc,ts} EvSet(event);
end
end
Код
function OnQuote(c,s)
if c~=c_old or S~=s_old then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then local t={c,s}; Ntp=Ntp+1; tpr[Ntp]={Quote,t,tc,ts}
if 3>Ntp then EvSet(event); end
end
end
Вообще колбеки все могут быть одинаковые. Алгоритм такой: Получаемые в колбеке параметры упаковываем в таблицу с ключом и помещаем в очередь. вот пример:
Код
function OnTrade(t) tpr[#tpr+1]={"trade",t} EvSet(event); end
function OnOrder(t) tpr[#tpr+1]={"order",t} EvSet(event);end
function OnAllTrade(t) tpr[#tpr+1]={"AllTrade",t} EvSet(event);end
EvSet(event) - это функция установки события. Если используете sleep, то эту функцию убираете.
В main извлекаем из очереди и по ключу вызываем функцию для обработки параметров Вот и весь алгоритм. Хороший пример main и очереди есть в документации. Но очевидно мало кто читает документацию.
О мифах про маркет мейкеров (MM). ------------------ MM это любой проф участник рынка, с который заключил с биржей договор об оказании услуг ММ. Задача MM - создание ликвидности, что фактически сводится к обеспечению минимального спреда. Условия такого договора есть на бирже. -------------------------------- Кратко, условие следующее. Если сделка стукает в позицию ММ, то биржа платит ему за такую сделку. Вот и все "тайны" ММ. Остальное - "теория заговора" -------------- После ухода многих иностранных игроков, биржа изменила правила на фьючерсах. В итоге на фьючерсах все , кто ставит пассивную заявку выполняют фактически задачу ММ. -------------------- В итоге на рынке стало меньше сделок по рыночной цене мелких игроков. А на рынке их уже 70%. В итоге меньше шума от толпы .
Acaw написал: nikolz , Nikolay спасибо отцы! Буду грызть. Но как же не использовать sleep в main? Разве тогда квик не зависнет от постоянных действий? Какой sleep можно считать долгм? 200-300 не долгий? Т.е. если коллбек приходит во время sleep, то он может быть проигнорирован main и то, что должно быть сделано в этом коллбеке сделано не будет?
И еще простейший вопрос, который сложно проверить на практике. Если заявка исполняется частями, то у каждой сделки по этой заявке будет свой trade_num?
Что касается таблиц, то с одной стороны проще, но с другой надо запоминать какие сделки уже учтены в позиции, какие новые, хоть это и не сложно сделать. Допустим скрипт остановился и нужно восстановить позиции. У меня в файле записаны позиции, потом я их обновляю через разбор таблицы сделок. Но если в течении дня потребуется несколько раз их восстановить, то без отдельной записи сделок дня невозможно будет понять, какие из них уже учтены в позиции, а какие нет.
Если освоите Си, то можно использовать функции Event и Wait (я их использую) и очередь и еще пул потоков. На форуме уже рассказывал. В этом случае время реакции main на колбек составляет не более 0.1 ms. ------------------------------------------- Если используете sleep, то меньше 10 ms не получится. Работает нормально. Но без очереди Вы обязательно пропустите кучу колбеков, так как они приходят пакетами т е практически одновременно деcятками. ------------------------------ По номеру сделки - это же номер сделки, а не заявки. Каждая сделка - это договор и у него уникальный номер. ------------------------------ Если делаете по таблицам,то надо запоминать что уже обрабатывали. Тогда все будет быстро. Например, в тесте у меня размер таблицы заявок составил 200 тысяч. Если делать просты перебором то ждать придется до завтра. -----------------------------. Я не пишу ничего в файлы, кроме параметров настройки и логов. Не вижу смысла это делать. Прошлое не исправишь и оно еще никого ничему не научило. --------------------- Если требуется сохранить в файлах, то можно выгрузить все в конце дня. Но пока у меня такой надобности не было.
Acaw написал: Да, но я спрашивал несколько другой аспект. Что лучше обрабатывать для ведения позиции коллбеки или таблицы, учитывая ненадежность коллбеков? Если и то и то, то нужно это все постоянно приводить к одному, а если исходить, что первоисточник это таблица и сверяемся с ней, то зачем обрабатывать коллбек. Разве что коллбек может придти раньше обновления таблицы, но эта нано разница не играет роли.
Про колбеки Они надежны так же как таблицы. Так как они вызываются перед записью в таблицы. ----------------------- Проблема обычно бывает в том, что по рекомендации разработчиков в main используют sleep. Кроме того, начинающие писатели роботов не используют очередь событий. ---------------------------- Поэтому без очереди и c долгим sleep колбеки просто игнорируются main и не обрабатываются. ----------------------- Поэтому и возникают пропуски событий и не совпадает значение в таблице и по колбекам. --------------------- Если Вы не занимаетесь скальпингом то по таблицам работать проще --------------------- Но если колбеки не используете, То можно писать робота в индикаторе - это еще проще и также надежно. Выбор за вами
Несколько возможных причин, по которым уведомления на смартфоне приходят с задержкой после блокировки экрана, и способы их устранения:
Некорректный статус приложений. Узнать и изменить его можно в расширенных настройках через меню «Режим разработчика». Для этого нужно перейти в «Настройки» → «Сведения о телефоне» → «Сведения о ПО» и 7 раз подряд нажать на пункт «Номер сборки». После в меню главных настроек появится пункт «Режим разработчика». В нём нужно найти пункт «Приложения в режиме ожидания» и в списке найти приложения, уведомления от которых приходят с задержкой. Затем просмотреть их статус и при необходимости изменить на «Active».
Режим энергосбережения. Нужно проверить, что он отключён на смартфоне.
Добрый день, В своей таблице использую обработку нажатия правой и левой кнопки мыши. С левой все нормально, а справой такая проблема После обработки нажатия правой кнопки мыши в моем колбеке,терминал выдает предложение сортировки:
Как сделать так, чтобы это предложение не появлялось.
Lelikov написал: Спасибо за ответ. Можно ли даже в функции OnCalculate(i) вызвать время свечи? Как узнать, к примеру, время открытия 555 свечи на минутном графике газпрома?
можно:
просто прочитайте параметры свечи с номером 555:
Функции для доступа к источнику данных: Функции для доступа к источнику данных O,
H, L, C, V, T принимают в качестве параметра индекс свечи и возвращают соответствующее значение в формате:
NUMBER <названиефункции>(NUMBER index)
Функция Size возвращает текущее количество свечек в источнике данных. Формат функции: NUMBER Size()
Описание значений функций O, H, L, C, V, T , Size совпадает со значениями, приведенными в разделе Функции для работы с графиками.
-------------------------
если надо читать индикатор то эта функция: GetValue - Функция предназначена для определения значения, установленного на выбранной линии указанной свечи индикатора:
Формат вызова: NUMBER value GetValue(NUMBER index, NUMBER line_number)
Параметры:
index – индекс свечи;
line_number – номер линии.
-------------------- Т е цена закрытия 555 свечи -это C(555) , время свечи T(555) - это таблица см док.
Lelikov написал: Доброго дня. Наверное, данная тема обсуждалась, но найти ее не смог. Имеются расчеты индикатора (массив данных на определенное количество минутных свечей) и время в секундах откуда он должен начинаться. Каким образом можно в индикаторе (без использования идентификатора) определить к какой свечке относится данное время? Можно ли в индюке определять время открытия какой-то определенной свечи? К примеру: Время начала индикатора (Старт 1736477971). Как установить по данному времени индикатор на минутном или другом таймфрейме? Какая это свечка от начала графика? Можно ли ее определить в функции Init() индикатора или другом месте кода?
при запуске индикатора ,функция OnCalculate(i) будет исполнена для всех свечей истории на графике. В этой функции для каждого номера свечи (i) сравниваете ее время с заданным.