Применение функция OrderClosePrice() к открытым ордерам

Новый комментарий
 
Вопрос к разработчикам:
Корректно ли использование данной конструкции:
OrderClose(OrderTicket(),OrderLots(),OrderClosePrice(),0,CLR_NONE)


Проверка работы на демо счете показала, что функция возвращает текущие Bid для BUY и Ask для SELL, то есть все верно.
В документации не сказано о применении функции OrderClosePrice() к открытым ордерам.
 
Да, уважаемые разработчики, вопрос интересный! Ответьте, пожалуйста.
 
В общем случае нельзя. OrderClosePrice содержит закешированное значение на момент вызова OrderSelect и это значение может устареть к моменту вызова OrderClose.

А в частном случае, когда идет такая вот последовательность:
if(OrderSelect(...))
  {
    ... // что-то очень быстрое и незатратное
   if(OrderClose(..., OrderClosePrice()) ....
 
  }
то можно использовать. Но если будут появляться сообщения об частых реквотах или ошибках, то стоит серьезно подумать над более корректной реализацией.
 
Renat:
В общем случае нельзя. OrderClosePrice содержит закешированное значение на момент вызова OrderSelect и это значение может устареть к моменту вызова OrderClose.

А в частном случае, когда идет такая вот последовательность:
if(OrderSelect(...))
  {
    ... // что-то очень быстрое и незатратное
   if(OrderClose(..., OrderClosePrice()) ....
 
  }
то можно использовать. Но если будут появляться сообщения об частых реквотах или ошибках, то стоит серьезно подумать над более корректной реализацией.

Закешированное значение чего? Если текущей цены закрытия, т. е. Ask или Bid, то как это значение может устареть, если цена остается неизменной в обработчике тиков? По крайней мере, до вызова RefreshRates(). Почему последняя не обновляет значение OrderClosePrice()? Или обновляет?

Что-то здесь не сходится.

Вообще, идея иметь под рукой текущую цену закрытия для открытых ордеров не так уж и плоха. Еще лучше было бы и вовсе исключить этот параметр из OrderClose() ввиду его безальтернативности. Какой смысл каждый раз выбирать между Ask и Bid в зависимости от типа одрера, если этот выбор всегда один и тот же?

Кстати, пример в русской версии документации к OrderClosePrice() нерелевантен.
 
>> если цена остается неизменной в обработчике тиков

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

OrderClosePrice хранит закешированную текущую цену, по которой можно было бы закрыть ордер. OrderClosePrice обновляется (фиксируется) только после вызова OrderSelect и никак не меняется от вызовов RefreshRates. OrderClosePrice равен Ask для SELL ордеров и Bid для BUY.

С учетом Ваших вопросов я настоятельно рекомендую не использовать OrderClosePrice в операциях закрытия позиций.
 
А я так и непонял, зачем в OrderClose нужно указывать цену закрытия?
Это создает разные проблемы и усложняет код ...

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

Может быть есть смысл расширить функционал и разрешить указывать вместо цены 0,
что могло бы означать - закрыть по рынку?
 
Renat:
>> если цена остается неизменной в обработчике тиков

Это стандартная ошибка экспертописателей в восприятии рыночного окружения. Цена никак не является неизменной, а может (и делает это постоянно) измениться в любой момент. Не забывайте про асинхронные процессы - все рыночное окружение меняется, а трейдер может только успеть (или не успеть) сделать сделку по текущим ценам.
Ask и Bid, как известно, берут значения из копии рыночного окружения, которая без вызова RefreshRates() остается неизменной. Термин "текущая цена закрытия", так же как и обсуждаемое значение OrderClosePrice(), очевидно, был применен в контексте рыночного окружения обработчика тиков, а не в контексте реального времени. Так что, замечание по поводу экспертописателей с их ошибками и восприятием не имеет к сказанному мной никакого отношения.

Про асинхронные процессы я не забываю никогда с тех пор, как посвятил несколько лет программированию систем жесткого реального времени под QNX. Кстати, Metaquotes до сих пор не исправил ошибку с race condition при инициализации глобальных переменных, про которую я говорил год назад.

OrderClosePrice хранит закешированную текущую цену, по которой можно было бы закрыть ордер. OrderClosePrice обновляется (фиксируется) только после вызова OrderSelect и никак не меняется от вызовов RefreshRates. OrderClosePrice равен Ask для SELL ордеров и Bid для BUY.

С учетом Ваших вопросов я настоятельно рекомендую не использовать OrderClosePrice в операциях закрытия позиций.
Почему не рекомендуете? Наоборот, согласно Вашему разъяснению использование OrderClosePrice() в таких операциях выглядит удобной и безопасной альтернативой. То, что значение не обновляется вызовом RefreshRates(), было бы честнее считать небольшой недоработкой, которую, как я подозреваю, легко исправить. Было бы неплохо также добавить эту информацию в документацию.

В любом случае, OrderSelect() после RefreshRates() - очевидный workaround для OrderClosePrice(). Хотя, наверное, и медленный.
 
Mak:
А я так и непонял, зачем в OrderClose нужно указывать цену закрытия?
Это создает разные проблемы и усложняет код ...

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

Может быть есть смысл расширить функционал и разрешить указывать вместо цены 0,
что могло бы означать - закрыть по рынку?
Дело в том, что трейдер точно должен знать цену, по которой он хочет закрыться. Мало кто захочет, чтобы его закрывали по рынку - у трейдеров будут постоянные подозрения о слиппажах. В принципе, нулевая цена могла бы быть выходом, но не думаю, что мы на это пойдем.

Мы специально жестко проверяем цены, чтобы не дать писать очень плохих экспертов. Ошибки с выбором цен указывают на серьезные проблемы в эксперте. Если разрешим писать все что угодно в торговых заявках, то качество экспертов будет абсолютно неприемлемым. И в этом обязательно обвинят разработчиков, которые допускают такие глупости в торговых заявках.
 
Irtron:
С учетом Ваших вопросов я настоятельно рекомендую не использовать OrderClosePrice в операциях закрытия позиций.
Почему не рекомендуете? Наоборот, согласно Вашему разъяснению использование OrderClosePrice() в таких операциях выглядит удобной и безопасной альтернативой. То, что значение не обновляется вызовом RefreshRates(), было бы честнее считать небольшой недоработкой, которую, как я подозреваю, легко исправить. Было бы неплохо также добавить эту информацию в документацию.

В любом случае, OrderSelect() после RefreshRates() - очевидный workaround для OrderClosePrice(). Хотя, наверное, и медленный.
Не рекомендую из-за сомнений в правильности его использования на фоне задаваемых вопросов. OrderClosePrice не имеет права изменяться после RefreshRates, он изменяется только и только после OrderSelect.

Ask и Bid, как известно, берут значения из копии рыночного окружения, которая без вызова RefreshRates() остается неизменной. Термин "текущая цена закрытия", так же как и обсуждаемое значение OrderClosePrice(), очевидно, был применен в контексте рыночного окружения обработчика тиков, а не в контексте реального времени. Так что, замечание по поводу экспертописателей с их ошибками и восприятием не имеет к сказанному мной никакого отношения.

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

Именно такие вопросы создают сомнения в правильном восприятии цен и способах их использования.
 
Renat:

Дело в том, что трейдер точно должен знать цену, по которой он хочет закрыться. Мало кто захочет, чтобы его закрывали по рынку - у трейдеров будут постоянные подозрения о слиппажах. В принципе, нулевая цена могла бы быть выходом, но не думаю, что мы на это пойдем.

Мы специально жестко проверяем цены, чтобы не дать писать очень плохих экспертов. Ошибки с выбором цен указывают на серьезные проблемы в эксперте. Если разрешим писать все что угодно в торговых заявках, то качество экспертов будет абсолютно неприемлемым. И в этом обязательно обвинят разработчиков, которые допускают такие глупости в торговых заявках.
Ну если дать пользователю выбор, он сам будет отвечать за последствия :)

Я к примеру уверен, что 99% экспертов будут использовать закрытие по рынку,
потому, что сейчас всем это приходится эмулировать руками добавляя кучу кода,
и потом проверяя ошибки (реквоты) и учитывать эти особенности в построении всего эксперта.
 
Renat писал (а):
Не рекомендую из-за сомнений в правильности его использования на фоне задаваемых вопросов.

А что мешает абстрагироваться от фона задаваемых вопросов? Ответ по существу представлял бы намного большую ценность.

Price не имеет права изменяться после .

Весьма сомнительное утверждение. Особенно на фоне :) спекуляций об изменении рыночной цены и значения цены в обработчике тиков.

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

Именно такие вопросы создают сомнения в правильном восприятии цен и способах их использования.

Опа. Помнится, вырванное из контекста утверждение было любимым оружием газеты Прав?Да! в идеологической борьбе. Которую она, к слову сказать, с треском проиграла.
Позволю себе напомнить, в оригинале текст был такой: "как это значение может устареть, если цена остается неизменной в обработчике тиков? По крайней мере, до вызова RefreshRates()." Что соответствует документации и легко может быть проверено простейшим советником. На всякий случай повторюсь, речь идет не о текущей рыночной цене, а о значениях Ask и Bid в функции start().


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