Усреднённый ТП для всех открытых позиций

 

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

Я так и сделал, но получаю ошибку 130. Может что-то ещё нужно?

Вот мой код:

//+---------------------------------------------------------------------------------------------------------------------------------------+
//|                                                Функция выполняет модификацию позиций                                                  |
//+---------------------------------------------------------------------------------------------------------------------------------------+
double CalcAveragePrice (Position_Properties& Pos[],    // Структура свойств позиции
                         int fi_Type)                   // Тип позиции
{
   double averagePrice = 0.0;
   
   for (int ord = OrdersTotal() - 1; ord >= 0; ord--)
   {
      if (!CPos.CheckMyOrdersBased (ord, fi_Type)) continue;
      
      CPos.FillDataOfPositions (Pos[ord]);
      
      averagePrice += Pos[ord].dOpenPrice * Pos[ord].dLots;
   }
   return ( ND (averagePrice) );
}
//+---------------------------------------------------------------------------------------------------------------------------------------+
//|                                                Функция выполняет модификацию позиций                                                  |
//+---------------------------------------------------------------------------------------------------------------------------------------+
void ModifyOrder (Symbol_Properties& Sym,        // Структура данных рыночного окружения выбранного инструмента
                  Position_Properties& Pos[],    // Структура свойств позиции
                  int fi_Type)                   // Тип позиции
{
   double averagePrice = 0.0;
   
   averagePrice = CalcAveragePrice (Pos, fi_Type);
   
   for (int ord = OrdersTotal() - 1; ord >= 0; ord--)
   {
      if (!CPos.CheckMyOrdersBased (ord, fi_Type)) continue;
      
      CPos.FillDataOfPositions (Pos[ord]);
      
      if (Pos[ord].iType % 2 == OP_BUY)
      {
         Pos[ord].dNewSL = 0.0;
         Pos[ord].dNewTP = ND (averagePrice + i_iTP * Sym.dPt);
         
         if (!CPosMan.fOrderModify (Sym, Pos[ord]))
            return;
      }
      else
      {
         Pos[ord].dNewSL = 0.0;
         Pos[ord].dNewTP = ND (averagePrice - i_iTP * Sym.dPt);
         
         if (CPosMan.fOrderModify (Sym, Pos[ord]))
            return;
      }
   }
}
 

Зачем писать такое простое используя структуры?

Типа чтобы посложнее было? 

 

p.s. Возможно 130 изза того что например для байев одна цена это

для одного ТП,а для другого СЛ 

 
shanty:

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

Я так и сделал, но получаю ошибку 130. Может что-то ещё нужно?

Забыли разделить на сумму объемов. Посмотрите внимательно, чему равно averagePrice на выходе. Там достаточно большое для цены число.

 
shanty:

 Имеется необходимость выставления общего усреднённого ТП для всех открытых позиций.  ***

 Есть второй способ.

Посчитать суммарный ЛОТ и выставить ОДИН ордер в противоположном направлениию.
В этом случае геморрой с модификациями ТП и СЛ просто не нужен.

Когда ОРДЕР сработает, можно спокойно, не торопясь, разобраться со всеми входящими ордерами с помощью функции OrderCloseBy().
Не теряя, при этом, ни одного пункта профита.
 
eevviill:

Зачем писать такое простое используя структуры?

Типа чтобы посложнее было? 

Структуры ничего не усложняют, а наоборот упрощают. Стоит лишь к ним привыкнуть...

Scriptong:

Забыли разделить на сумму объемов. Посмотрите внимательно, чему равно averagePrice на выходе. Там достаточно большое для цены число.

Действительно, в этом и был косяк.

prorab:

 Есть второй способ.

Посчитать суммарный ЛОТ и выставить ОДИН ордер в противоположном направлениию.
В этом случае геморрой с модификациями ТП и СЛ просто не нужен.

Когда ОРДЕР сработает, можно спокойно, не торопясь, разобраться со всеми входящими ордерами с помощью функции OrderCloseBy().
Не теряя, при этом, ни одного пункта профита.

 Это способ больше годится для лока, а не для выставления среднего ТП для позиции.

 
shanty:

Структуры ничего не усложняют, а наоборот упрощают. Стоит лишь к ним привыкнуть...

...

Больше символов с тем же количеством логических операций это усложнение.

 
eevviill:

Больше символов с тем же количеством логических операций это усложнение.

Наоборот - проще читать программу. Так, если функция названа f(), то для определения задачи, которую она решает, потребуется прочитать и осмыслить весь ее код. А вот если это будет не функция, а метод класса - CalculateTradeSignal::GetMAValue, то, просто прочитав  название, мы уже понимаем - в методе производится вычисление значения МАшки, которое необходимо для решения более "крупной" задачи - генерации торгового сигнала.

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

 
Scriptong:

Наоборот - проще читать программу. Так, если функция названа f(), то для определения задачи, которую она решает, потребуется прочитать и осмыслить весь ее код. А вот если это будет не функция, а метод класса - CalculateTradeSignal::GetMAValue, то, просто прочитав  название, мы уже понимаем - в методе производится вычисление значения МАшки, которое необходимо для решения более "крупной" задачи - генерации торгового сигнала.

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

Дык. Так и функцию можно назвать MA_data_f()
 
eevviill:
Дык. Так и функцию можно назвать MA_data_f()

А к чему она логически будет относиться, как это определить? Кроме того, у метода класса есть много удобных плюшек: его можно сделать константным (не сможет изменять данные, относящиеся к классу), у него нет доступа к данным других классов. Хотя все это, конечно же, частные случаи и мелочи. Парадигма ООП намного более масштабна и удобна при разработке больших проектов. С мелкими проектами вполне можно обойтись и без него.

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

double orderOpenPrice[], orderLots[], orderClosePrice[], orderStopLoss[], orderTakeProfit[];
datetime orderOpenTime[];
string orderSymbol[];

При работе со структурой это всего один массив выходит:

struct OrderInfo
{
   double openPrice;
   double lots;
   double stopLoss;
   double takeProfit;
   double closPrice;
   datetime openTime;
   string symbol;
};

OrderInfo orderInfo[];
 
Scriptong:

А к чему она логически будет относиться, как это определить? Кроме того, у метода класса есть много удобных плюшек: его можно сделать константным (не сможет изменять данные, относящиеся к классу), у него нет доступа к данным других классов. Хотя все это, конечно же, частные случаи и мелочи. Парадигма ООП намного более масштабна и удобна при разработке больших проектов. С мелкими проектами вполне можно обойтись и без него.

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

При работе со структурой это всего один массив выходит:

 

Если так,то да.
 
eevviill:
Если так,то да.

Ну а как же иначе? Любой адекватный проект переростает в достаточно большой по размеру, и дорабатывать проекты, которые написано без структур сложнее, т.к. кода больше.

Хотя в млк это и не особо удобно реализовано, но... тем не менее, можно и так пока что обойтись.

 

Scriptong:

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

 Согласен, тогда самое место Ассемблер :)

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