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

Новый комментарий
 
Renat писал (а):

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

Мы специально жестко проверяем цены, чтобы не дать писать очень плохих экспертов. Ошибки с выбором цен указывают на серьезные проблемы в эксперте. Если разрешим писать все что угодно в торговых заявках, то качество экспертов будет абсолютно неприемлемым. И в этом обязательно обвинят разработчиков, которые допускают такие глупости в торговых заявках.
Лучший способ избежать ошибок - не иметь возможности их совершить.
Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
  • человек думал, что совершит сделку по одной цене, а на самом деле цены давно уже изменились и ему дают реквот
  • человек пишет настолько опасный и зацикленный код, что его никак нельзя пропускать к серверу (отлов грубейших ошибок на раннем этапе прямо в терминале позволяет снизить нагрузку на сервер)
  • обработка заявок не должна содержать возможности предъявления претензий из-за подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", когда сразу же родится неувядающий негативный фон "открывают как хотят, верить нельзя", подпитываемый недоброжелателями.
  • исключить ситуации, когда безбашенные эксперты пытаются втупую совершают десятки и сотни тысяч неудачных торговых транзакций в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.
 
Renat:
Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
  • человек думал, что совершит сделку по одной цене, а на самом деле цены давно уже изменились и ему дают реквот
  • человек пишет настолько опасный и зацикленный код, что его никак нельзя пропускать к серверу (отлов грубейших ошибок на раннем этапе прямо в терминале позволяет снизить нагрузку на сервер)
  • обработка заявок не должна содержать возможности предъявления претензий из-за подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", когда сразу же родится неувядающий негативный фон "открывают как хотят, верить нельзя", подпитываемый недоброжелателями.
  • исключить ситуации, когда безбашенные эксперты пытаются втупую совершают десятки и сотни тысяч неудачных торговых транзакций в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.
Прочитал последнее предложение, и почему то стишок вспомнился ...

- Если птице отрезать руки ..
- Если ноги отрезать тоже ..
- Эта птица умрет со скуки ..
............
(Винокур)

ИМХО, насилие над клиентом не лучший способ научить его писать хорошие программы ..

Из перечисленных пунктов только 1 и 3 имеют отношение к теме ветки.
Мое видение - дать клиенту возможность совершать сделки и по рынку, и по заданной им цене.

Выбор за клиентом.
Указал совершать сделки по рынку - не жалуйся.
Хочеш совершать сделки по заданной цене - пожалуста, задавай цену.

При выборе сделок по рынку п.1 отпадает, реквоты можно отрабатывать автоматически (клиент согласился).
п.3 тут тоже отпадает, поскольку у клиента есть возможность совершать сделки с контролем цены и он сам от нее отказался.
 
Ослабление правил неминуемо приведет к массе претензий по исполнению. Мало кто будет разбираться в деталях, но заявлениями о плохих брокерах будут завалены все форумы.

Кому это нужно? Разработчикам? Нет. Брокерам? Нет. Видимо нужно тем, кто не хочет думать глубже или просто защищает других ради принципа.

Почему просто не соблюдать правила и торговать точно по рыночным ценам? А если нужно защищаться от реквотов, то можно выставить допустимый слиппаж.
 
Renat:
А если нужно защищаться от реквотов, то можно выставить допустимый слиппаж.
К сожалению это не всегда помогает. Бывают случаи когда цена уже ушла из потока (на быстром рынке) и тут уже никакой слиппаж не поможет (хоть 100 пипсов поставь).
Вот ответ полученный в свое время мною от Stringo в личной переписке касающейся такой ситуации:
"если цены не было в потоке (на быстром рынке она могла уйти из буфера) то даётся однозначный реквот без проверки слиппажа".
Т.е. в подобных ситуациях (быстрый рынок или недостаточно быстрая связь терминала с сервером) возможность закрыть по "текущей рыночной цене" (указав например "0" в качестве параметра) могла бы помочь с однозначным закрытием позиции. Ну а что касается притензий что цена "не совсем" та на которую клиент рассчитывал, так ведь явно указав параметром "текущая рыночная цена" он с этим уже как бы согласился.

Хотя, справедливости ради, надо заметить что "воя" в таких случаях все равно будет предостаточно. :) Посему и реализация такого варианта - на усмотрение разработчика. Хотя лично мне это (как вариант) в принципе понравилось бы. :)
 
Поскольку тема опять возникла.

Во-первых. Может стоит заглянуть в бумажки, к-рые мы подписываем с брокерами? Наверняка многие в своих договорах (в разделе "по телефону") увидят "По Рынку" как один из вариантов общения с ДЦ, что-то типа:
...
Нет необходимости указывать цену, достаточно сказать: "По рынку".
Рыночный ордер ... будет исполнен при первом, с момента установки ордера, возникшем на рынке предложении ...
...
Во-вторых. А кто просит разработчиков чуть ли не менять идеологию продукта? Не надо править существующие функции (если будете править под каждого из нас ...), достаточно добавить отдельную функцию ОрдерПоРынку() - и в этом случае вся ответственность за последствия употребления ложится на трейдера.

А функция все-таки будет полезна.
 
Renat:
Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
  • человек думал, что совершит сделку по одной цене, а на самом деле цены давно уже изменились и ему дают реквот
  • человек пишет настолько опасный и зацикленный код, что его никак нельзя пропускать к серверу (отлов грубейших ошибок на раннем этапе прямо в терминале позволяет снизить нагрузку на сервер)
  • обработка заявок не должна содержать возможности предъявления претензий из-за подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", когда сразу же родится неувядающий негативный фон "открывают как хотят, верить нельзя", подпитываемый недоброжелателями.
  • исключить ситуации, когда безбашенные эксперты пытаются втупую совершают десятки и сотни тысяч неудачных торговых транзакций в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.
Не знаю, зачем Вам понадобилось мое видение на эти проблемы. И какое отношение эти проблемы имеют к топику.

Еще раз.

Речь здесь с самого начала идет лишь о замене закешированного значения Ask или Bid в вызове OrderClose() закешированным аналогичным образом значением, доступным через OrderClosePrice, т.е. об удобстве использования 
OrderClose(OrderTicket(), OrderLots(), OrderClosePrice(), Slippage);
вместо громоздкого
double closePrice;
 
switch (OrderType())
{
    case OP_BUY:
        closePrice = Bid;
        break;
 
    case OP_SELL:
        closePrice = Ask;
        break;
 
    default:
        return;
}
 
closePrice = NormalizeDouble(closePrice, Digits);
 
OrderClose(OrderTicket(), OrderLots(), closePrice, Slippage);
Как последняя конструкция поможет избежать озвученных проблем по сравнению с вызовом одной строкой? Скорее всего, наоборот, она может послужить дополнительным источником ошибок среди неопытных экспертописателей и как раз поспособствует их возникновению.

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

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

Не знаю, зачем Вам понадобилось мое видение на эти проблемы. И какое отношение эти проблемы имеют к топику.
Критиковать всегда легче, чем выдать продуманное решение?
 
Renat:
Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
  • человек думал, что совершит сделку по одной цене, а на самом деле цены давно уже изменились и ему дают реквот
  • человек пишет настолько опасный и зацикленный код, что его никак нельзя пропускать к серверу (отлов грубейших ошибок на раннем этапе прямо в терминале позволяет снизить нагрузку на сервер)
  • обработка заявок не должна содержать возможности предъявления претензий из-за подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", когда сразу же родится неувядающий негативный фон "открывают как хотят, верить нельзя", подпитываемый недоброжелателями.
  • исключить ситуации, когда безбашенные эксперты пытаются втупую совершают десятки и сотни тысяч неудачных торговых транзакций в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.
Попробую я изложить свое видение. Исходить буду из высказанного выше предложения - не менять логику работы функций открытия/закрытия ордеров, а расширить ее возможностью указания "по рыночной цене" путем присвоения параметру цена значения "0".

И так по пунктам:

1. Если человек думал, что совершит сделку по одной цене, то он явно должен указать эту цену при вызове торговой функции. В этом случае, при невозможности проведения операции по данной цене, он получит реквот. Если же человек хочет провести сделку по текущей рыночной цене на момент запроса торговой операции, он указывает в качестве цены "0" и не имеет притензий к тому что цены давно уже изменились, что будет по тому и отработает. Т.е. та цена которая должна была быть в реквоте и будет ценой проведения торговой операции.

2. Тут очень много субъективизма. Объективно можно писать настолько же опасный и зацикленный код придерживаясь правила что в OrderClose для Buy-ордеров надо указывать Bid, а для Sell-ордеров Ask. На практике же ошибок такого плана станет гораздо меньше ибо уверен, что большинство неопытных программеров экспертов будут работать именно по рынку (так будет проще программировать). И как раз ошибок в этих операциях будет меньше ибо сами операции будут трактоваться однозначно. А по поводу притензий (а они естественно будут) - см. пункт 1 (клиент САМ согласился проводить операцию по рынку и отказался контролировать предложенную цену).

3. По поводу подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", так нет никакой подмены! Функционал не заменяется, а расширяется!!! Если клиент хочет сделку по точно заявленной цене - он указывает эту цену, если же он хочет сделку по рыночной цене - он указывает "0", тем самым соглашаясь на любую предложенную цену. Так что все четко прописано и клиент может пользоваться на свое усмотрение любым функционалом.

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

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

Еще раз хочу прокомментировать, я не предлагаю ломать, я предлагаю расширить! Хочет клиент контролировать цену (и в случае чего получать реквот) - пользуется имеющимся функционалом, хочет работать "по рынку" (полагаясь на цены предлагаемые брокером) - пользуется возможностью указать "по рынку".


Все выше изложенное разумеется ИМХО и реализация предложенного варианта исключительно на усмотрение разработчиков.
12
Новый комментарий
Причина обращения: