Система принятия решений и/или Нечеткая логика(FuzzyLogic)

Страницы: Пред. 1 ... 12 13 14 15 16
RSS
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
А если такой вариант рассмотреть, создать специальный модуль или глобальную таблицу, которая будет управлять всеми зависимостями. Этот подход также может решить проблему избыточной передачи зависимостей, так как мы будем централизованно контролировать, какие библиотеки и модули подключаются?
 
Цитата
VPM написал:
а) dofile:
* каждый вызов → заново читает файл
* заново выполняет код
* выполняется в глобальном окружении?
* нет кэширования?
* нет изоляции
"Пять копеек" от Роберту Иерузалимски:
Цитата
Для простых задач dofile удобна, поскольку выполняет всю работу
за один вызов. Однако loadfile более гибкая. В случае ошибки loadfile
возвращает nil и сообщение об ошибке, что позволяет нам обработать
ошибку  более  подходящими  для  нас  способами.  Более  того,  если  нам
нужно  выполнить  файл  несколько  раз,  то  мы  можем  один  раз  вызвать
loadfile  и  несколько  раз  вызвать  возвращенную  им  функцию.  Этот
подход гораздо дешевле, чем несколько раз вызывать dofile, поскольку
файл компилируется лишь один раз.
Всё пройдет. Но это не точно.
 
Ziveleos,  Роберту Иерузалимски сравнивает dofile / loadfile. Мы же обсуждаем архитектуру production-системы. Это разные уровни задачи.

* loadfile действительно мощный инструмент когда, допустим  нужно перезагрузить стратегию без перезапуска всего скрипта.
* require — все таки правильно для модульной архитектуры.

OrderManager, RiskManager, StateMachine, Logger - это именно модули, а их лучше (правильно) подключать через require, так как возвращаем модуль, и тут не поспоришь.

Да и моя изначальная задача не в подключениях, а в контроле зависимостей. Но в любом случае, Вы подсветили полную картину подключений.
 
Цитата
VPM написал:
Да, спасибо за вариант, про собственный флаг, даже не задумывался, взял на вооружение!
   Этот вариант наглядный, но не самый эффективный и гибкий. Сам я использую для управления, всего двумя нужными мне коллбеками: OnCleanUp и OnTransReply их переопределение, то есть присвоение переменным коллбеков тех функций, которые мне нужны для обработки соответствующих событий.
   Например, если я не хочу (по как то причине) обрабатывать события OnTransReply, то выполняется  OnTransRe ply = function()  end
   Для продолжения обработки значение переменной OnTransReply  заменяется на нужную мне функцию обработки (запись в очередь параметров событий).
 
TGB,  Мне вообще не понятно, зачем ими управлять, ведь это событие? Ну если первый способ, еще логичен включение как точки входа. То остальное зачем?
 
Цитата
VPM написал:
То остальное зачем?
   Согласен. В вашем конкретном случае достаточно первого варианта.
 
Цитата
VPM написал:
* loadfile действительно мощный инструмент когда, допустим  нужно перезагрузить стратегию без перезапуска всего скрипта.
* require — все таки правильно для модульной архитектуры.
Перезагрузить можно и модуль загруженный require, достаточно стереть запись о нем из package.loaded.
Цитата
VPM написал:
Но в любом случае, Вы подсветили полную картину подключений.
Да ничего я не подсвечивал.
Просто Вы сравнили dofile и require, а я напомнил про loadfile, тем более, что обе эти функции используют loadfile для загрузки и компиляции файла.
Всё пройдет. Но это не точно.
 
Да нет Ziveleos, . Вы подметили суть. Сравнивать dofile и require можно долго, но без loadfile картина была неполной. И это важное уточнение. Вы не просто "напомнили", а добавили критически важный слой в понимание темы.  

dofile и require — это высокоуровневые обёртки над мощным механизмом loadfile. По аналогии из механики: loadfile — это рычаг, а dofile и require — просто разные насадки на этот рычаг для разных задач.

Внесу пояснения, чтобы зафиксировать этот "полный цикл":

1.  Фундамент — loadfile - это базовая функция. Она делает самое главное (и самое тяжелое) — читает файл с диска, компилирует его в байт-код и возвращает результат в виде *функции*. Но она её не выполняет.

2.  Утилитарный уровень — dofile - это просто удобная обёртка. Она сделала всю работу за нас, но лишила нас контроля. Это "выстрелил и забыл".

3.  Архитектурный уровень — require - Это уже не просто утилита, а менеджер зависимостей. Он использует loadfile для загрузки, и добавляет поверх этого кэширование.

А вот механика про перезагрузку модуля, загруженного через require, — это вообще высший пилотаж. Встречается для горячей перезагрузки кода в сложных приложениях (играх). Этот подход позволяет обновлять логику стратегии, не теряя состояние всей программы, что критически важно для долгоиграющих процессов.

Если есть свой пример для торговых приложений приведите?
Страницы: Пред. 1 ... 12 13 14 15 16
Читают тему
Наверх