Зачем писать такое простое используя структуры?
Типа чтобы посложнее было?
p.s. Возможно 130 изза того что например для байев одна цена это
для одного ТП,а для другого СЛ
Имеется необходимость выставления общего усреднённого ТП для всех открытых позиций. Я так понимаю, нужно помножить цену открытия каждого ордера на его лот пройдя по всем открытым позициям.
Я так и сделал, но получаю ошибку 130. Может что-то ещё нужно?
Забыли разделить на сумму объемов. Посмотрите внимательно, чему равно averagePrice на выходе. Там достаточно большое для цены число.
Имеется необходимость выставления общего усреднённого ТП для всех открытых позиций. ***
Посчитать суммарный ЛОТ и выставить ОДИН ордер в противоположном направлениию.
В этом случае геморрой с модификациями ТП и СЛ просто не нужен.
Когда ОРДЕР сработает, можно спокойно, не торопясь, разобраться со всеми входящими ордерами с помощью функции OrderCloseBy().
Не теряя, при этом, ни одного пункта профита.
Зачем писать такое простое используя структуры?
Типа чтобы посложнее было?
Структуры ничего не усложняют, а наоборот упрощают. Стоит лишь к ним привыкнуть...
Забыли разделить на сумму объемов. Посмотрите внимательно, чему равно averagePrice на выходе. Там достаточно большое для цены число.
Действительно, в этом и был косяк.
Есть второй способ.
Посчитать суммарный ЛОТ и выставить ОДИН ордер в противоположном направлениию.
В этом случае геморрой с модификациями ТП и СЛ просто не нужен.
Когда ОРДЕР сработает, можно спокойно, не торопясь, разобраться со всеми входящими ордерами с помощью функции OrderCloseBy().
Не теряя, при этом, ни одного пункта профита.
Это способ больше годится для лока, а не для выставления среднего ТП для позиции.
Структуры ничего не усложняют, а наоборот упрощают. Стоит лишь к ним привыкнуть...
...
Больше символов с тем же количеством логических операций это усложнение.
Больше символов с тем же количеством логических операций это усложнение.
Наоборот - проще читать программу. Так, если функция названа f(), то для определения задачи, которую она решает, потребуется прочитать и осмыслить весь ее код. А вот если это будет не функция, а метод класса - CalculateTradeSignal::GetMAValue, то, просто прочитав название, мы уже понимаем - в методе производится вычисление значения МАшки, которое необходимо для решения более "крупной" задачи - генерации торгового сигнала.
А то с подобной логикой (чем меньше символов - тем проще) Ассемблер - самый удобный язык программирования, т. к. там символов на одну операцию совсем мало.
Наоборот - проще читать программу. Так, если функция названа f(), то для определения задачи, которую она решает, потребуется прочитать и осмыслить весь ее код. А вот если это будет не функция, а метод класса - CalculateTradeSignal::GetMAValue, то, просто прочитав название, мы уже понимаем - в методе производится вычисление значения МАшки, которое необходимо для решения более "крупной" задачи - генерации торгового сигнала.
А то с подобной логикой (чем меньше символов - тем проще) Ассемблер - самый удобный язык программирования, т. к. там символов на одну операцию совсем мало.
Дык. Так и функцию можно назвать 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[];
А к чему она логически будет относиться, как это определить? Кроме того, у метода класса есть много удобных плюшек: его можно сделать константным (не сможет изменять данные, относящиеся к классу), у него нет доступа к данным других классов. Хотя все это, конечно же, частные случаи и мелочи. Парадигма ООП намного более масштабна и удобна при разработке больших проектов. С мелкими проектами вполне можно обойтись и без него.
А по структурам - им нет адекватной замены. Так, если нужно описать несколько ордеров, то придется заводить столько массивов, сколько характеристик одного ордера требуется сохранить:
При работе со структурой это всего один массив выходит:
Если так,то да.
Ну а как же иначе? Любой адекватный проект переростает в достаточно большой по размеру, и дорабатывать проекты, которые написано без структур сложнее, т.к. кода больше.
Хотя в млк это и не особо удобно реализовано, но... тем не менее, можно и так пока что обойтись.
А то с подобной логикой (чем меньше символов - тем проще) Ассемблер - самый удобный язык программирования, т. к. там символов на одну операцию совсем мало.
Согласен, тогда самое место Ассемблер :)

- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Имеется необходимость выставления общего усреднённого ТП для всех открытых позиций. Я так понимаю, нужно помножить цену открытия каждого ордера на его лот пройдя по всем открытым позициям.
Я так и сделал, но получаю ошибку 130. Может что-то ещё нужно?
Вот мой код: