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

 К сожалению, реальные процессы фондового рынка очень далеки от формальных вероятностных моделей стохастистичеких процессов. Те метрики (средние, и многие другие), используемые пользователями для обеспечения прибыли на фондовом рынке, берутся за основу по причине отсутствия моделей неопределенных социальных процессов. На самом деле, то, что происходит на фондовом рынке это поведение толпы, жаждующей прибыли. При этом существенными факторами являются:

1)    пирамидальная архитектура фондового рынка (растет – закупаются; падает – продаются);

2)    его виртуальность – это представления у участников рынка о том, что надо учитывать (иногда очень далекие от действительности);

3)    инсайдерская составляющая (знание того, что скорее всего произойдет, отдельными участниками фондового рынка с существенными ресурсами), особенно значимая для России;

4)    малипуляционная составляющая, присутствующая на всех рынках (в виде различных «вбросов» в СМИ и т.д.);

5)    полная зависимость фондового рынка от поведения его участников (в том числе от использования новых информационных технологий);

6)    паническое поведения толпы участников фондового рынка при его значительных колебаниях.

    Все выше перечисленное выше существенно зависит от меняющегося текущего политико – экономической состояния локальных фондовых рынков. Поэтому иллюзии использования истории поведения фондового рынка (особенно в далеком прошлом) для получения прибыли, во многом, несостоятельны.

Александр написал:
  Разработчики написали в письме:

Могли бы разработчики более подробно описать грядущие изменения?

Поддержка:

Добрый день,
Пока подробностей нет. Как выйдет новая версия это будет указано в списках изменений.

--------------------------------------------------------------------------------------------------

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

-------------

  Я не знаю точно, какие изменения будут, но попытаюсь дать прогноз (интересно, насколько промахнусь). А если промахнулся, то это мои предложения.

   Видимо это будут изменения, которые надо было внести в схему обработки коллбеков QLua, как мне кажется, давно, а именно:

   1)    вместо регистрации функций обратного вызова, регистрация соответствующих очередей событий (возможно, с теми же именами);  я бы сделал эти очереди циклическими, с указанием их длины при регистрации, но не более некоторого значения;

   2)    вместо sleep, служебная функция ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);

   3)    добавление функции чтения очередей событий (их параметров).

   Эта схема реализует рекомендованную ARQU обработку параметров событий в main.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться переработка в Qlua нативного управления автоматической ее памятью с целью реализации потокобезопасной уборки мусора, требуемой в старой схеме (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua (в том числе и 5.3.5) станет в описанной выше схеме рутинной задачей.

При этом проблема сбоев автоматической памяти QLua 5.3, о которой я писал не раз в ветке «Грядущие
изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и
сделок» должна исчезнуть.

----

Добавление.

   Если будет реализована описанная выше схема обработки коллбеков, то, так как реализация QLua станет однопотоковой, мой многопотоковый тест памяти QLua для этого случая не применим.

    Видимо это будут изменения, которые надо было внести в схему обработки коллбеков QLua, как мне кажется, давно, а именно:

    1)    вместо регистрации функций обратного вызова, регистрация соответствующих очередей событий (возможно, с теми же именами);  я бы сделал эти очереди циклическими, с указанием их длины при регистрации, но не более некоторого значения;

    2)    вместо sleep, служебная функция ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);

    3)    добавление функции чтения очередей событий (их параметров).

    Эта схема реализует рекомендованную ARQU обработку параметров событий в main.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться переработка в Qlua нативного управления автоматической ее памятью с целью реализации потокобезопасной уборки мусора, требуемой в старой схеме (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua (в том числе и 5.3.5) станет в описанной выше схеме рутинной задачей.

  В защиту удачного выбора ARQU пользовательского языка программирования Lua можно сказать следующее.

1.    Фактически Lua является двухуровневым языком благодаря архитектурной (изначально) тесной его интеграции с C/C++. Это обеспечивает два уровня его использования:

   1)    начальный, достаточный для многих пользователей (базовый синтаксис Lua может быть описан на нескольких страницах);

   2)    расширенный с выходом в системный язык программирования C/C++ (и для этого в Lua есть C-API), на котором можно написать все что угодно.

  Все проблемы, не решаемые в собственно Lua, могут решаться в C/C++. Нужна высокая производительность, переходим в C/C++. Нужен типизированный язык переходим туда же. Не хватает каких-то функций, переходим туда же.

2.    Зачем вносить какие-то изменения в Lua с тем, чтобы из него сделать плохой C, когда и так можно писать на C?

3.    Интересно то, что Владимир и сам не хочет писать ни на каком языке, кроме Lua.

За начальную фразу своего предыдущего комментария извиняюсь. В момент его написания мне было не до юмора.

--------

Ответ поддержки.

Добрый день.
 
   Проблемой занимаемся, если будут дополнительно вопросы, то мы     сообщим.
   Извиняемся за долгий разбор, постараемся ответить, как можно скорее.