Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п. - страница 8

Новый комментарий
 
GaryKa:

И тогда придется вводить обратную связь между "исполнителем" и "анализатором", и более того как-то встраивать параметры этого неидеального исполнения в мат.модель анализатора

А на что влияет в данном случае обратная связь? Допустим Вы хотели купить по 1.00 рублю, а неидеально исполнено было по 1.02

Этого уже не изменить - анализатор вынужден работать с новым значением. Если Вы имеете ввиду, что допустим у Вас при выставлении был SL 0.98, а теперь нужно переставить его на разницу. т.е. на 1.00. Думаю чем вводить обратную связь - проще логику изменить - сначала купить, а потом поставить SL на фиксированную дистанцию от цены исполнения.

 
A100:

А на что влияет в данном случае обратная связь? Допустим Вы хотели купить по 1.00 рублю, а исполнено было по 1.02

В случае реджекта. Или в случае, когда надо выравнять портфель после срабатывания лимитки.

 
TheXpert:

В случае реджекта. Или в случае, когда надо выравнять портфель после срабатывания лимитки.

При выранивании портфеля - затрудняюсь сказать. А вопрос реджекта на мой взгляд должен был разрешен в блоке исполнения - повторный запрос в заданных пределах - допустим 10 запросов с паузой пока цена не ушла дальше 50 пунктов от желаемой

Анализатор может заранее сказать Исполнителю как поступить в случае неудачи - повторить или "забить"

 

Не подумайте, что умничаю, но еще раз посмотрите на эту архитектуру написания боевой ТС. Там нет обратной связи.

Есть виртуальные позиции и есть реальное торговое окружение, которое подгоняется под виртуальность.

В таком случае даже плевать, неттинг в платформе или другая система учета. 

 
TheXpert:
Вот как раз пример того, о чем я говорил -- торговая часть зависит от стратегии.
Не должна зависеть. Если разработать грамотное представление позиции и организовать правильную работу с ними, тип исполнения ни как не повлияет на логику самого эксперта. В моем движке например тип исполнения задается простым enum'ом. Хотите лимитники - пожалуйста, хотите стоп ордера - пожалуйста. Возьмем к примеру стоп ордер с указанием максимального проскальзывания по нему. Ведь фактически это лимитный ордер, цена которого хуже текущей на величину этого самого проскальзывания. Значит во всех случаях можно обойтись лимитными ордерами. Проблема с недобором объема тоже легко решается. Если эксперт решает, что требуемый объем  не набран, то он открывает вторую позицию в том же направлении. На уровне базового класса хеджинг поддерживается прозрачно и с этим нет ни каких проблем. Более того, решение открывать или не открывать вторую позицию в случае недобора объема может быть делегировано на уровень базового класса. Тогда можно просто описать режим, при включении которого базовый класс будет принудительно включать в список позиций для обработки новые позиции. Модуль стратегии как ни в чем не бывало будет подхватывать их и обрабатывать по своим правилам.
 
hrenfx:

Не подумайте, что умничаю, но еще раз посмотрите на эту архитектуру написания боевой ТС. Там нет обратной связи.

Есть, на более низком уровне, ее не может не быть.

C-4:

Не должна зависеть.

Ок, не должна так не должна. А картинки вам еще учиться и учиться рисовать. А картинки это и есть абстракции.
 
hrenfx:

Не подумайте, что умничаю, но еще раз посмотрите на эту архитектуру написания боевой ТС. Там нет обратной связи.

Та нормальная архитектура.  По крайней мере в моём вкусе вполне.


Есть виртуальные позиции и есть реальное торговое окружение, которое подгоняется под виртуальность.

Вот они как раз и спорят тут про сложности-ненадёжности синхронизатора (моего, в данном случае).


В таком случае даже плевать, неттинг в платформе или другая система учета. 

Абсолютно в дырочку.  У меня аналогичный драйвер под четвёрку написан ещё когда пятёрку не выпустили.  Там на вход неттинговые позиции подаются, а драйвер их транслирует в четвёрочные ордера "сокращая" все локи по ходу пьесы.
 
TheXpert:

Есть, на более низком уровне, ее не может не быть.

Ок, не должна так не должна. А картинки вам еще учиться и учиться рисовать. А картинки это и есть абстракции.
Мы мухинских академиев не кончали!
 
TheXpert:

Есть, на более низком уровне, ее не может не быть.

Ок, не должна так не должна. А картинки вам еще учиться и учиться рисовать. А картинки это и есть абстракции.
Важное исключение: логика HFT алгоритмов действительно фактически описывается способом исполнения.
 
Вот тут подумалось, что если бы MQL5 поддерживал множественное наследование, а также класс мог бы объявлять абстрактные методы - это открыло бы путь к использованию интерфейсов что было бы очень здорово для больших проектов.
123456789101112131415...20
Новый комментарий
Причина обращения: