Alexander (Все сообщения пользователя)

Такой прокси вызов функций из основной DLL, как описал выше так же можно организовать и по другому, т.е. не возвращая адрес нужной функции в скрипт с последующим вызовом функции через переменную, получившую адрес этой функции. А можно вызывать функции как обычно через имя модуля.имя функции, но эти функции надо сделать прокси-функциями, т.е они должны принимать все нужные параметры для вызова, а потом через переменную указатель вызывать нужную функцию из основной DLL, передавая ей эти параметры обычной функции C. Но это просто к слову. Так не стал, хотя разницы нет. Всё равно же результат никакой.

Добавлю ещё. Попробовал такой вариант. Написана ещё одна DLL для загрузки основной. Скрипт через require грузит её, та в DLL_PROCESS_ATTACH через LoadLibrary загружает основную DLL. Есть функция в DLL, которая загрузила основную, которая возвращает мне адрес любой функции из основной DLL по имени функции, этот адрес она передаёт через lua_pushcfunction, а скрипт сохраняет в переменную и потом я через эту переменную вызываю функцию из основной DLL. Всё работает. Проверено. Точно так же как если бы я вызывал функции напрямую из первой. Далее вызываю из скрипта функцию, которая выгружает основную через FreeLibrary. Вот тут самое интересное. Выгрузка происходит нормально, ошибок нет, НО... результат такой же как в п.3, что пару постов выше - файл DLL так и не удалить!!! Удалить можно только после выхода из QUIK-а. Получается, что так, что выгружать DLL из самой себя - результат одинаковый - положительный, но на самом деле нихрена не положительный раз файл удалить нельзя.

Постом выше я описал, что уже было предпринято. В п.2 я как раз делал тоже самое. Отдельная DLL написана, там одна функция на выгрузку. Хэндл DLL есть - получаю запросом из первой. Не выгружается. По поводу - выгрузить столько раз, сколько её вызывали до этого. Библиотека загружается один раз и висит не выгружается. Наверное имелось ввиду столько раз сколько запускался скрипт, который её грузит в начале через require? По п.3 - как отключить оповещение о вызове этой DLL?
И ещё. Вспомнил, что ранее как только первый раз написал свою DLL для QUIK, она ВРОДЕ как сама выгружалась после отработки скрипта. Но потом выгрузок не было, когда писал DLL, где запускались потоки.  Точно ответить не мог точно выгружалась или нет. Но вот когда писал DLL, которая выгружает основную DLL, то при завершении скрипта, я мог удалить файл этой  DLL, а вот удалить файл основной DLL, которую надо удалить так и не получалось. Сделал выводы, что какие-то ресурсы не освобожены, поэтому DLL и висит. Но я уже всё предусмотрел, выгружаю и закрываю всё что открывал и использовал. У меня запускаются потоки, они выделяют память, потоки перед завершением память освобождают, сами завершаются, так же использовал TLS, тоже освобождаю, дескрипторы потоков закрываю. Инициализацию делал критической секции, - удаляется. Что ещё может быть не знаю. Короче что использовал, то освободил или закрыл. Что мешает Lua выгрузить не пойму пока.

Сегодня сделал несколько попыток выгрузить мою DLL загруженную моим скриптом.
1) Написал отдельную программу(скомпилял с hModule = const, - взял из отладочного вывода, где DLL выводит свой hModule при загрузке), которая делает FreeLibrary DLL, результат не успешный, GetlastError = 126 (Не удалось найти указанный модуль), из другого пространства процесса видимо не катит.
2) Написал отдельную DLL для выгрузки DLL, в которой скрипт вызывает так же FreeLibrary(hModule скрипт получает вызовом функции из удаляемой DLL и передаёт его DLL, которая должна удалить удаляемую DLL), -  результат не успешный, GetlastError = 126 (Не удалось найти указанный модуль). Тут DLL вроде в пространстве того же процесса, но видимо нельзя удалить не свой модуль.
3) Вызов скриптом функции, которая  в самой DLL и она вызывает FreeLibrary(т.е. по сути DLL выгружает сама себя), результат выполнения функции как ни странно - Успешное выполнение( ! = 0), но удалить фай DLL из каталога так и не удаётся, только после выхода из QUIK.
4) То же самое, что и п.3, плюс вызов UnmapViewOfFile, результат - QUIK вылетает(слышно как шуршит hdd, идёт полная выгрузка), но вылет понятен - после UnmapViewOfFile по сути управление команде после UnmapViewOfFile уже не передать - кода в памяти уже нет.
5) То же самое, что и п.3, но вызов UnmapViewOfFile  вызовом функции из другой DLL(hModule скрипт получает вызовом функции из удаляемой DLL и передаёт его DLL, которая должна удалить удаляемую DLL), - результат GetlastError = 487 (Попытка обращения к неверному адресу).
7) То же самое, что и п.3, плюс collectgarbage(), результат такой же как у п.3
8) То же самое, что и п.3, плюс:
    package.loaded["luacdllopt"] = nil
   _G["luacdllopt"] = nil
 , результат такой же как у п.3
9) То же самое, что и п.8, плюс collectgarbage(), результат такой же как у п.3

На этом сделал вывод, что нужен только либо явный вызов FreeLibrary оттуда, откуда был LoadLibrary, а этого нет, либо UnmapViewOfFile нужна оттуда же, чего тоже не можем иметь(хотя если бы и имели, то просто воспользовались бы FreeLibrary). Либо должен быть какой-то способ заставить Lua всё нормально почистить - ведь п.3 имел таки успешный результат, поэтому я полагаю, что выгрузка произошла, но отвязка файла не сделана, что и не даёт нам его удалить. Есть у кого ещё какие мысли что ещё можно попробовать? Должен же быть какой-то выход - скрипт загрузил, скрипт отработал, по сути DLL никому не нужна. Решение должно быть.

PS. Пока писал ещё мысль такая пришла - пишем одну DLL, загружаем её в скрипте, эта DLL ничего не делает кроме как через LoadLibrary грузит основную DLL(раз сама загрузила, то сама должна и выгрузить), в которой все нужные нам функции. Но как вызывать функции из основной потом? Если найдётся решение, то может и получится потом выгружать основную. Главное выгружать основную, так как её постоянно надо перекомпилировать и менять файл на новый, а первая путь себе и не удаляется. Наспех что-то на ум ничего не идёт как вызывать, надо собраться с мыслями.

PSS. А не вроде можно вызывать. В первой DLL пишем ещё одну функцию через которую будем вызывать любую функцию из первой DLL, блин ну как это заморочено всё получается. Но придётся видимо и так попробовать.

PSSS. Или после загрузки основной DLL, адреса всех функций возвращать в скрипт и потом использовать адреса для вызова, но тоже заморочено.
Лучше бы конечно сам Lua заставить выполнить свою работу.

Вот что интересно, а разработчики могут что-нибудь по этому вопросу посоветовать? Понятное дело, что квик - это квик, а Lua - это Lua, но всё-таки.

Я вот за это зацепился. Раз человек такое писал, значит выгрузка автоматом была. На данный момент моё видение по этому вопросу следующее. При отладке я вижу, что после загрузки моей библиотеки помимо того, что я запускаю свои отдельные потоки, которые присоединяются к этой DLL, так же время от времени к моей библиотеки присоединяются потоки самого квика, которые он запускает. Я вижу как при завершении потока происходит его отсоединение от моей DLL, и как отсоединяются от неё потоки квика, которые ранее к ней присоединились. Но проблема в том, что свои потоки я могу завершить, а вот потоки квика я не контролирую. В любой момент времени постоянно есть какой-то из потоков квика, который присоединён к моей библиотеке. Это делает сама система. Таковы её правила видимо - все вновь созданные потоки из пространства процесса присоединять к DLL, работающей в пространстве этого процесса. Они постоянно подключаются, отключаются, я это контролирую по их ID, но всегда есть потоки присоединённые и никак не возникает ситуация когда все потоки отсоединились. Вот думаю можно ли програмно в самой DLL как-то не разрешать "чужим" подключаться к ней или как-то принудительно их отсоединять. Возможно, когда писалось это, то в тот момент не было ни одного потока присоединённого к DLL и по завершению скрипта квик выгружал DLL, но то было раньше и квик был другой версии и потоки были там по другому организованы чем сейчас. Вот если добиться отсоединения всех потоков, то возможно квик и выгрузит DLL. Но я же не могу запретить квику запускать потоки. А может это и не квика потоки, а Lua, - не понятно. И поэтому может даже сторонняя выгрузка явно не поможет пока есть хотя бы один поток, присоединённый к DLL. Может можно как-то права доступа организовать к воей DLL только своим потокам, но так глубоко я не вникал, да и не хотелось бы, но видимо придётся. Поэтому пока будем думать дальше, уж больно напрягает это всё - перезагрузки для каждой повторной компиляции.

А вот это интересно, надо с ним поэксперементировать.

Я это пробовал - никакого толку. Выгрузка не происходит. И способ действительно извращённый. Внаглую занулить таблицу. И что там когда какой сборщик вычистит - не понятно. Вызова самого сборщика я тут не вижу.

Ну в исходниках есть, а толку то? Я могу вызвать её из своего скрипта?

Как же я могу сделать явный вызов FreeLibrary для своей библиотеки из своего скрипта, который её загрузил? Я могу вызвать функцию из скрипта свою из этой своей библиотеки и там сделать вызов FreeLibrary этой библиотеки, но что это будет за абсурд? Из тела библиотеки вызывать выгрузку самой этой библиотеки? Библиотека в своём коде будет пытаться попросить систему выгрузить саму себя?

Ну в случае квика загрузка происходит явно через LoadLibrary. Поэтому могли бы и предусмотреть и аналог FreeLibrary. После его вызова там конечно как система соизволит, так и выгрузится. Библиотека же твоя - захотел загрузил, захотел  - выгрузил.

Да, я когда разбирался со всем этим, то как раз тоже на это пояснилово от Майкрософта наткнулся - этим и воспользовался потом.

Короче я разобрался. Оказывается все исходники у меня были на ANSI, а вот один файл был на UTF-8. Как так получилось, что я его сохранял специально  в ANSI и потом компилял весь проект и тоже не работала - не пойму. Что-то по запарке видимо не то сделал, поэтому и промучился долго. Раньше так и делал. Весь код в ANSI изначально и сто процентов выведет на русском, тем более QUIK в 1251 работает. А студия файлы по разному может сохранять. Вот этот почему-то по умолчанию в UTF-8 сделала, а другой проект отдельно делал - там студия сама ANSI сохранила. Но я не стал заморачиваться с перекодировками, я просто флаги компилятору указал, чтобы исходники все как UTF-8 сохранял, а кодировку выполнения делал во время компиляции как cp1251. При компиляции много сообщений, что не может некоторые символы из ANSI файлов в UTF-8 переделать(там русские комменты были), поэтому ANSI-шные так и остались как есть, а один файл он был в UTF-8 уже, тоже получается остался как есть, но зато русский код сразу мне во время компиляции сгенерил в cp1251 и всё сейчас работает. На будущее сразу надо не забывать проверять и желательно всё в ANSI, чтобы без проблем или компилятору указывать флаги на нужную кодировку выполнения - то есть то что будет в скомпилированной программе на выходе после компилятора и в какой кодировке.
Не выводил потому, что в UTF-8 был русский закодирован на время выполнения, поэтому ни MessageBoxA, ни MessageBoxW естественно не могли его раскодировать, так как у Microsoft MessageBoxW типа широкие символы, и типа это UTF кодировка, но не та, у них wide char это UTF-16LE двухбайтовый. А UNF-8 от только английские символы одним байтом кодирует и если всё на английском, то будет одинаково, что на ANSI, что на UTF-8. Эти юникоды разные варианты есть. UTF-8 он кодировать может 1-4 байт на символ, UTF-16 от 2-4 байт на символ, а ещё BE или LE, UTF-32 там строго 4 байта на символ и тоже BE или LE.

И у меня там цикл в main шибко многочисленный на вызова подряд функций, вызовов много, так что от начала цикла до конца проходит видимо очень много времени и это видимо тоже как-то влияет. При тыке мышкой по шапке окна видимо обработчик мыши срабатывает, и он заставляет перерисовать окно и WM_PAINT перерисовывает, а по другому нет - жди очереди, а очередь всё никак не приходит, потому, что постоянно квик пролетает мимо в цикле по причине всех этих слотов времени и задержек, которые никак не могут коррекектно работать между собой в теле цикла квика.

nikolz, если Тут всё видимо у всех по разному. И всё связано с тем как они обновляют содержимое таблиц. Ведь вся программа квика - это один огромный цикл где каждой операции выделяется слот времени и вот видимо если код скрипта по своей продолжительности успевает как-то вклиниться между слотами времени, то на следующей итерации квик обновит буфера таблицы, если нет - то постоянно квик проходит "мимо". Здесь надо знать сам алгоритм как у них там всё организовано.

Сюда что-то и не заходил давно. Да 5 параметров. Перепутал видимо. В общем обновляется хоть как-то когда когда SetCell с 5-ю параметрами, в конце просто ставлю 1-цу, иначе не обновляется и Highlight подсветка обязательно и строка с подсветкой должна быть внутри таблицы в видимой части. А вообще это или криво работает WM_PAINT в оконной процедуре таблицы, либо WM_PAINT отрабатывает по честному, но данные для отображения в буфере не обновляются как положено, без исходников не поймёшь.

Есть прямая ссылка на тему, как этот JIT прикрутить к квику?  

Если имелось ввиду заменить MessageBox  на MessageBoxA, так я так уже пробовал. По умолчанию да юникод в свойствах проекта и функция из макроса MessageBox подставляется MessageBoxW, я это знаю. Замена ничего не меняет абсолютно. MessageBox, что один, что другой вызываются из оконной процедуры у меня.

Ну так у меня и есть dll на основе API C for Lua, но только результат совсем не такой как хотелось бы.Что именно сделать? Перейти на аналог ffi? Если это имелось в виду, то это надо отдельно сейчас вникать в эту тему. Несомненно тема того стоит, изучить надо её. Но думаю, что всё что мне хотелось бы этот подход не решит. Мне напрмер нужно своё окно со своей callback оконной процедурой, потому, что в неё онлайн будут со скрипта QUIK-а поступать данные и она будет рисовать мне опционные стратегии в онлайн режиме. Трансляция цен на покупки-продажи опционов по бидам и офферам, смотря что надо - покупать или продавать и страйки и база и по этим данным график будет меняющийся на глазах в зависимости от этих данных.

Ошибочка в ссылке. Мой подход: https://quik2dde.ru/viewtopic.php?id=18

Тут я кажется кое-что пряснил для себя. Вы, видимо используете этот подход: https://forum.quik.ru/forum10/topic7971/, тем более сами писали. Я правильно понял? Я использую этот подход: https://forum.quik.ru/forum10/topic7971/
Хотелось бы решить задачу в своём подходе.

nikolz, у Вас что за функции nkcf.defF и rfs ? Какой их код, что они вызывают API винды? И Вы их вызываете прямо из скрипта, а я API прямо из DLL на C.

Да я по всякому уже перепробовал, пробовал я и W варант и A вариант MessageBox-а, и просто коды букв вставлял для cp1251 из таблицы символов. Ни так, ни как не выводят по русски. Скрины:

Попробую поднять данную тему вновь. Вобщем всё что выше написано - не работает Библиотека не выгружается!. Библиотека на C++. Выше писали, что типа если на чистом C++ то выгружается нормально. Не выгружается. Есть ли ещё какой способ выгрузить свою же DLL, которую Lua выгружать почему-то не хочет. Странное вообще какое-то поведение Lua. Скрипт отработал, библиотека - осталась. Функций в Lua для выгрузки не нашёл, что тоже довольно таки странно. Загружать значит можно, выгружать нет. Приходится постоянно перезагружать QUIK, чтобы удалить файл DLL, поскольку система не даёт его удалить, пока библиотека используется Lua. А удалять файл надо, чтобы после перекомпиляции DLL, новый DLL-файл записать на место  того, что надо удалить. Это сильно напрягает поскольку сам QUIK грузится не быстро. Сталкивался кто с таким? Как ещё можно решить пролему? Ведь библиотека же чисто моя, зачем она вообще удерживается Lua - не понятно. Закончился скрипт без ошибок - освободи, но нет. Уж не знаю как решить, думаю уже как-то искать ID библиотеки, ну или там хэндл какой и выгружать отдельно программой через API винды.

Аааа, я ещё что-то сразу то не приметил. nikolz, Вы  на скрине показываете окно сообщений самого квика. Мои скрипты в это окно пишут по-русски нормально. Я писал не про это окно. У меня DLL. Скрипт вызывает её функции. Эти функции например вызывают MessageBox виндовую для вызова окна сообщенй винды с русским текстом. И вот оно то пишет не по-русски. Вот в этом проблема. А с простым message в скрипте проблем нет - сохраняю с русскими сообщениями как ANSI и проблем нет. Вобщем сама винда перестаёт по-русски писать в своём же сообщении, хотя если вызывать  не из библиотеки DLL под QUIK, а просто из программы под винду, то пишет по-русски как положено. И ещё. Из DLL в этом окне только само сообщение абракадаброй выводится, а вот кнопки "Да", "Нет" - они нормально по-русски подписаны.

nikolz, вот я и не пойму толком ничего. Винда 10. У винды с 10-ой версии вроде что-то там как-то поменялось. Толи на юникод на какой-то другой перешли, толи ещё что. Наверное был до этого юникод 2-х байтовый(наверное u16), а сейчас полный u8(8 - это не биты) - так наверное. У Вас какая винда, что проблем нет? Блин, локаль показывает ru-Ru, что пользователя, что системы, в вызове из DLL - локаль C. Ну вроде же сменил локаль, потом вывел, нет всё равно на нерусском пишет. Думаю поди надо ещё в этой локали кодировку(чарактер сет) сменить. Буду пробовать. Но это потом, пока это не критично, надо главные функции писать.

За столько времени так никто и не ответил. Поддержка может хоть что-нибудь подсказать в решении проблемы? Мой вывод : в контексте толи потока QUIK, толь в Lua, локаль меняется с ru-Ru на локаль C, а в ней видимо русских букв вообще нету. Поэтому хоть что ты пиши, хоть кодируй текст - всё равно толку не будет, так как его попросту в чарактер сет(кодировке) нет как такового. Но почему не получается сначала  сохранить локаль C, потом установить родную локаль, вывести текст, потом локаь C вернуть обратно - не пойму.

Попробовал .cpp файл открыть в проводнике виновс и сохранить его в ANSI, как сохраняю скрипты под Lua, но при загрузке в Visual Studio C++ студия отображает русские символы как положено, т.е. перекодирует под себя. Раньше как то пользовался таким способом только в других ситуациях и помогало - при загрузке отображались иероглифы, но например в консоль шло то что надо.

Возникла проблема. Нас C написал библиотеку DLL. В ней функция для вызова из скрипта Lua. Библиотека подгружается, функция вызывается и нормально работает. Эта функция создаёт окна в отдельных потоках Windows, окна выводят cтроковую информацию API функциями Windоows(OutputDebugString, MessageBox), которые естественно корректно выводят русский текст при работе в простом приложении, но в DLL они выдают полную хрень из-за разных кодировок в среде Windows по умолчанию и в QUIK. Пробовал перед вызовом функций устанавливать локали по умолчанию через GetUserDefaultLocaleName и GetSystemDefaultLocaleName(обе возвращают "ru-Ru", а QUIK через _wsetlocale(LC_ALL, NULL) даёт локаль "C"), а потом вызывать функции вывода информации, после чего обратно возвращал локаль "C", чтобы QUIK работал не замечая временную смену локали. Не помогло!!! Как можно ещё выкрутиться? Изначально указать компилятору как-то(как?) закодить русский текст в кодировке QUIK-а? Писать строки через "\код" - не вариант, да и коды надо как-то генерить в кодировке QUIK-а. Пока что-то совсем на ум ничего не идёт.

О, здесь когда цитировал строки Владимира, видимо нажал Цитировать не в том месте и получилось, что я писал, а не Владимир, но по сути вопрос задан. А с потоками придётся позаниматься.

Как запускается скрипт? чем? И как понять в потоке из пула? Тут как то можно использовать функции lua для запуска функций в отдельном потоке?(если таковые есть в lua, просто lua глубоко не изучал).

В lua, и в частности в скриптах для квика можно реализовать потоки? Если можно, то это как раз вариант разбивки алгоритма, чтобы каждый поток контролировал свой условный уровень.

Ну а если курс сначала стоит, а потом пойдёт в противоположную сторону и довольно таки сильно, и будет там потом болтаться очень долго, месяцы например. Тогда что? На рынке же всякое может быть, и какой бы ни был робот, он идеальным быть не может. Для таких случаев я думаю использовать несколько уровней условных и если цена ушла не туда, то торговать алгоритм уже там, чем больше уровней можно себе позволить, тем конечно лучше, со временем глядишь и на старом уровне сделка закроется.

Вы немного не так поняли мой вопрос. Наверное я так написал неоднозначно. Я имел ввиду, что Ваш робот в процессе работы может попасть в такую ситуацию, когда он например сделает покупку, а потом (нужно соответственно сделать продажу) продажа ну никак не получается, потому что цена пошла не в сторону, которую предположил робот, т.е. робот никак не может закрыть сделку находясь в ожидании подходящего момента для продажи(ждёт нужную цену), а момент этот ну никак не наступает. Про это я написал типа "завис", не имея ввиду программное зависание как таковое. Хотя и Ваш ответ проинформировал об интересных моментах, что не лишне. А посему спросил, если бывают такие "зависы", то как робот их решает? Продаёт в убыток по стопу или ждёт таки момента неизвестное количество времени? Хорошо, когда отроботал и закрыл предыдущую сделку, например покупки, продажей, а если нет? Если цена всё никак не хочет "подстроиться" под алгоритм робота? Ждать или продавать в убыток? Если продавать в убыток, каково %-ное соотношение угадал-не угадал? Типа какой КПД прибыльных сделок? Если прибыльные все на 100%, то это достигается только ожиданиями, которые могут уйти в бесконечность.

Или условного стопа с лимитной заявкой или как-то так.?

Бывали ли такие ситуации в работе робота, чтобы он, например, сделал сделку на покупку и "завис", так как обратная сделка на продажу не прошла и цена ушла не вверх, а вниз? Как долго такое продолжается? Приходится ли вручную потом закрывать позиции или всё это в роботе закрывается по принципу лимитного стопа.

Меняться они могут и не медленно, а очень даже быстро и держаться потом на этом уровне какое-то время. Поэтому история тут не так важна как таковая, главное чтобы эта зародившаяся история продолжалась какое-то время нврастая и нарастая и как начнётся меняться в обратную сторону, так и о чём то можно судить, поэтому в  анализе не история, а текущее достигнутое состояние и есть ли его изменение в обратную сторону. По времени планирования это конечно согласен. Чем больше сделок, тем меньше горизонт и наоборот.

Не совсем так. Хотя и так конечно тоже. Я это не отрицаю, что так крупняк работает. Но он после этих манипуляций рыночную цену существенно двигает по итогу, я же стараюсь ловить зарождение любого тренда, в том числе и крупного игроке, не важно, и не держу позицию, как буратины, а быстро её сливаю, т.е. ловлю более менее не такие существенные разрывы в цене, а стараюсь словить более мелки колебания в течении дня. Если он показывает, что двигает рынок вверх для продажи, мне надо поймать его тренд на повышение, а потом по-любому будет отскок вниз(мини-коррекция), вот на ней мне и надо продать, и пусть этот рынок хоть куда потом идёт, хоть вверх его гонят, хоть вниз. В основном стараюсь работать на малой волатильности.

Да, сложный у Вас робот. Каа Вы пишите - единственный на все случаи жизни, его постоянно совершенствуете? Алгоритм меняется? Данные меняете? Не может же он быть универсальным.

Мне и не надо полного синхронизма. У меня диапазон времени в пределах минут как писал выше. Если робот, то просто ждёт когда появится нужный "большой" разрыв (если судить по графику) и чтобы были соответствующие минимальные объёмы. Если вручную, то визуально смотрю на графики и сам принимаю решения, что "пора" выставить заявку.

С учётом того, что написал выше, удостовериться просто. У меня всего несколько сделок в день, а не сотни. Заявку по тренду, обратная заявка выставлюяется с прибылью если робот, сработала - прибыль есть. Если вручную, то и так вижу что закрываю обратной заявкой.

Автоматический робот с сотнями заявок и сделок в день это может и хорошо, но я не маркет-мейкер, у меня нет такой ликвидности, не могу совершать сделки на миллисекундах и комиссии брокер берёт и биржа не как с маркет-мейкера с меня.

Может HFT так и работают. У меня нет тенденции словить что-то в малых диапазонах времени. Как и описал выше тенденция она нарастает со временем, длится не мс, а минуты, времени для принятия решения предостаточно. А игратся в пределах миллисекунд, так там такое изменение цены маленькое будет на купил-продал или наоборот, что и комиссии брокера не оправдает.

В части того, что прогноз будущего - да, без прогноза заявку вообще никто не делает, ни робот, ни человек, а вот в части того, что с горизонтом в мс - нет. Это так кажется, что стакан быстро и динамично меняется. Меняется то он меняется, быстро меняется в основном его часть, которая на стыке bid-offer, остальная часть стакана намного более статична и эти статичные части в bid и в offer просто скользят по стакану вверх-вниз. А вот следить надо не за быстроменяющейся частью стакана, а именно за более статичными. От того как они меняются и в каком направлении, от того и зависит тренд. Эта их бОльшая относительная статичность никакие не миллисекунды, она минуты длится, а то и в переделах пол часа - час. Когда сопротивляются повышению цены - в стакан прям начинают заваливать заявками на продажу с крупными объёмами, как натиск спадает, так и заявки такие резко уходят из стакана, тоже самое и в отношении поддержки, не дают цене уйти вниз своими крупными заявками. Но тут надо учитывать не только перевес одних над другими, но и общие объёмы и тех и тех, и объём торгов, и пару графиков сразу, а не только скажем фьючерса, нужно учитывать и изменение базы. Да и вообще интересно смотреть как меняются стаканы во времени того же фьючерс например относительно базы.

Нет. У меня абсолютно совершенно другое. К аллигатору никакого отношения и близко не имеет. Аллигатор, тот анализирует прошлое, т.е. прошлые свечи для построения 3-х скользящих на разных периодах, каждая из которых имеет свой сдвиг вперёд на своё количество. Я вообще свечи игнорирую и у меня 2-е кривых, данные из реального времени - построение кривых в момент прихода свечи без её анализа, в расчёте только данные из стакана, т.е. я за точку отсчёта просто беру приход свечи и считаю стакан в обоих направлениях.

На каком принципе основан Ваш робот если не секрет конечно? Я прошу написать без подробностей и нюансов, а просто на пальцах для понимания сути. Ведь на основании чего-то же он срабатывает? Чего? Понятное дело, что в 2-х словах весь алгоритм описать сложно, но всё же... Можно намекнуть без секретов? Хотя бы понять в чём идея алгоритма?

Рынок он динамичный и робот должен быть динамичным. Это самая сложная задача. Не знаю какие там нейронные сети что могут, но думаю, что сети эти пишет человек и по своему уму и всякое там обучение тоже основано на алгоритмах, которые пишет человек, универсального алгоритма обучения нет. Поэтому заморачиваться и писать самообучающийся робот - это какая-то неимоверная задача, и робот будет без конца расти в размере всё больше и больше и постоянно писать его как самообучающийся неимоверно сложно, запаришься такое писать. А доверять сторонним алгоритмам это так себе идея. Вот поэтому за обучение нужно отвечать самому, анализирую рынок, тесты скриптов, стаканы и прочее и всё это закладывать в разные алгоритмы, которые снабжать разными данными. Всё гениальное просто на самом деле, не надо шибко всё усложнять.

Чтобы оттестировать робот, надо пробовать менять входные параметры его и постараться добиться "оптимальных", а для этого написаны другие скрипты-тестеры и по стакану и по динамике изменения цены в реалии, "старые" данные вообще не использую. На тестах отрабатывает вроде не плохо, но в любом случае корректировки делаю в нём данных постоянно после анализа за тестами и за рынком в целом. На рынке всегда есть какие-то закономерности, вот их и надо пробовать ловить, они меняются, но они есть и задача их выявлять и корректировать входные параметры для робота, а всякий анализ "прошлого" как по мне - так это наобум. Любой робот написанный один раз без корректировки алгоритма и входных данных рано или поздно, но начнёт ошибаться. Да и алгоритмы желательно иметь разные и соответственно разные скрипты запускать в зависимости от той или иной ситуации, одному роботу охватить "всё" не практично.

Так что анализировать стакан вполне себе можно, и мне кажется даже нужно - работает лучше всяких там индикаторов по "старым" данным на графике и всякого ТА. Робот так же написал, тестирую, он и по стакану и по алгоритму работает в совокупности, чтобы меньше ошибок было.

Это взял просто то, что прям сейчас есть. После максимумов на зелёном графике идёт рост цены, но анализировать надо пару графиков иначе не точно и брать более максимальные значения по амплитуде и более продолжительные, чтобы на обоих графиках была одна и та же тенденция, что на покупку, что на продажу. И как правило движение цены начинается после пересечений графиков.

Вот;