Обсуждение статьи "Автоматное программирование как новый способ создания автоматических торговых систем" - страница 3

 
Rorschach:

"3. Мне было интересно и захотелось услышать белый шум реальных тиков, и это удалось сделать с помощью программы WaveLab 6.0."

Гыы. Я оказявается не один псих такой))) Вот, что у меня получилось. Через адоуп аудишен делал.

Как цену нормализовал? 

Как обычно, отсечением длинных хвостов, всё что выходит за 3*ско приводится к этому значению.
 

Вагон эмоций

1) Многа букаф ниачем...

2) Глядя на это начинаешь осознавать почему сейчас на Марсе американцы а не мы.

3) об остальном я лучше помолчу (ибо одни эмоции). 

 

Статья понравилась.  Особенно про современную практику разработки и документирования программ. Так оно и есть.

Конечно в статье должен был быть показан хотя бы самой простой советник построенный по методу автоматов. Или это запланировано на следующую статью?

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

Ну а поскольку текущее состояние советника толком не известно, приказы и запросы толком не выполняются, то и построить чёткую логику автоматов не получится. Реально получается вот такой алгоритм:

комп: А купи-ка мне, сервер, пару сотен евробаксов.

сервер: А хрен тебе, комп, у тебя стопы в запросе не правильные.

комп: а чо не правильные то?

сервер: так цена скакнула.

комп: ну тогда купи без стопов.

сервер молчит

комп: ну чё купил?

сервер молчит

комп: ну и хрен с тобой. Пока вздремнём минут восемь. 

комп через восемь минут: ну как там?

сервер: евробаксы купил, но пока покупал цена ушла куда-то совсем.

комп: ну и хрен с ней. Вздремнём ещё часик.

И так далее


 
эволюция идёт по кругу - настала пора вернуться к (бес)конечным автоматам, потом будем строить машины Тьюринга.
 
Virty:

...

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

Ну а поскольку текущее состояние советника толком не известно, приказы и запросы толком не выполняются, то и построить чёткую логику автоматов не получится.

...

Вот это уже что-то новое. Как раз ЛЮБАЯ (без исключения) ТС строится на анализе и чётком понимании состояний ТС. Простейшие состояния: отработка сигналов на открытие/закрытие/модификацию ордера и т.д. и т.п.

Если "текущее состояние советника толком не известно", то это однозначно не советник, и однозначно не программа, и однозначно надо вычеркнуть и забыть навсегда слово "алгоритм" применительно к советнику. 

 

Много эмоций.

О.к. предлагаю перевести обсуждение в практическое русло. Давайте разберем конкретный алгоритм построенный по теории конечных автоматов. Обсудим его сильные и слабые стороны. Сам я таким методом не пишу, но с вопросом и алгоритмикой немножко знаком, поэтому сейчас накидаю общий принцип этого управления:

//СХЕМА + ПСВЕДОКОД
enum eTradeState {NoTradeRegim, BuyRegim, SellRegim, WaitRegim};
eTradeState TradeState = eTradeState.NoTradeRegim;
int Trade()
{
   switch (TradeState)
   {
       case eTradeState.NoTradeRegim:
          NoTradeRegim();
          break;
       case eTradeState.WaitRegim:
          WaitRegim();
          break;
       case eTradeState.SellRegim:
          SellRegim();
          break;
       case eTradeState.BuyRegim:
          BuyRegim();
          break;
   }
}
//Здесь описываем условия, при которых советник начнет торговать. Например
void NoTradeRgim()
{
   //Дальше следует псевдокод. 
   if(CurrentDay == WorksDays && Market.Enable = true)
      TradeState = eTradeState.WaitRegim;
}
//Здесь ловим сигналы на вход в длинную либо короткую позицию.
void WaitRegim()
{
   if(CheckForNoTrade() == true)
   {
      TradeState = eTradeState.NoTradeRegim;
   }
   if(CheckForBuy() == true)
   {
      BuyAtStop(...)
      TradeState = eTradeState.BuyRegim;
   }
   if(CheckForSell() == true)
   {
      SellAtStop(...);
      TradeState = eTradeState.SellRegim;
   }
}
//В этой функции сопровождаем длинную сделку
void BuyRegim()
{
   //Здесь пишем условия при которых сделка закрывается, либо ее стоп-лосс или прочие параметры изменяются, и т.д.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}
//В этой функции сопровождаем короткую сделку
void SellRegim()
{
   //Здесь пишем условия при которых сделка закрывается, либо ее стоп-лосс перемещается, и т.д.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}

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

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

Что думают эксперты по этому поводу? 

 
C-4:
...

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

Что думают эксперты по этому поводу? 

А можно узнать что вы подразумеваете под формулировкой "классический подход".

А то ведь у каждого своё отражение реальности.

 
Urain:

А можно узнать что вы подразумеваете под формулировкой "классический подход".

А то ведь у каждого своё отражение реальности.

Наверное не так выразился. Конечно каждый пишет по-своему. Я имел в виду большинство подходов, когда состояние системы на каждом шаге четко не определено. Его требуется определять не посредственно во время исполнения советника. Самый простой пример код написанный в одном блоке OnTick(). Ни какие режимы не анализируются. Выбор решения производится на основе блочного ветвления if(...).
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
C-4:
 Я имел в виду большинство подходов, когда состояние системы на каждом шаге четко не определено. Его требуется определять не посредственно во время исполнения советника

Если состояние "четко не определено", то как можно определить то, что "чётко не определено"? В случае работы с ордерами/позицией, что советник с каждым тиком не должен понимать в каком состоянии он находится? Или советник на каждом тике находится в "неопределённом состоянии". Это что же советник такой, который не знает, что ему делать в каждом тике? 

 

В статье тема вообще не раскрыта, кроме того, что существует switch. Да и вообще не важно существует он или  нет, перключаться можно if'ом.

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

 

 

Причина обращения: