Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мы специально жестко проверяем цены, чтобы не дать писать очень плохих экспертов. Ошибки с выбором цен указывают на серьезные проблемы в эксперте. Если разрешим писать все что угодно в торговых заявках, то качество экспертов будет абсолютно неприемлемым. И в этом обязательно обвинят разработчиков, которые допускают такие глупости в торговых заявках.
Мы специально жестко проверяем цены, чтобы не дать писать очень плохих экспертов. Ошибки с выбором цен указывают на серьезные проблемы в эксперте. Если разрешим писать все что угодно в торговых заявках, то качество экспертов будет абсолютно неприемлемым. И в этом обязательно обвинят разработчиков, которые допускают такие глупости в торговых заявках.
- человек думал, что совершит сделку по одной цене, а на самом деле цены давно уже изменились и ему дают реквот
- человек пишет настолько опасный и зацикленный код, что его никак нельзя пропускать к серверу (отлов грубейших ошибок на раннем этапе прямо в терминале позволяет снизить нагрузку на сервер)
- обработка заявок не должна содержать возможности предъявления претензий из-за подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", когда сразу же родится неувядающий негативный фон "открывают как хотят, верить нельзя", подпитываемый недоброжелателями.
- исключить ситуации, когда безбашенные эксперты пытаются втупую совершают десятки и сотни тысяч неудачных торговых транзакций в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
- человек думал, что совершит сделку по одной цене, а на самом деле цены давно уже изменились и ему дают реквот
- человек пишет настолько опасный и зацикленный код, что его никак нельзя пропускать к серверу (отлов грубейших ошибок на раннем этапе прямо в терминале позволяет снизить нагрузку на сервер)
- обработка заявок не должна содержать возможности предъявления претензий из-за подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", когда сразу же родится неувядающий негативный фон "открывают как хотят, верить нельзя", подпитываемый недоброжелателями.
- исключить ситуации, когда безбашенные эксперты пытаются втупую совершают десятки и сотни тысяч неудачных торговых транзакций в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.- Если птице отрезать руки ..
- Если ноги отрезать тоже ..
- Эта птица умрет со скуки ..
............
(Винокур)
ИМХО, насилие над клиентом не лучший способ научить его писать хорошие программы ..
Из перечисленных пунктов только 1 и 3 имеют отношение к теме ветки.
Мое видение - дать клиенту возможность совершать сделки и по рынку, и по заданной им цене.
Выбор за клиентом.
Указал совершать сделки по рынку - не жалуйся.
Хочеш совершать сделки по заданной цене - пожалуста, задавай цену.
При выборе сделок по рынку п.1 отпадает, реквоты можно отрабатывать автоматически (клиент согласился).
п.3 тут тоже отпадает, поскольку у клиента есть возможность совершать сделки с контролем цены и он сам от нее отказался.
Кому это нужно? Разработчикам? Нет. Брокерам? Нет. Видимо нужно тем, кто не хочет думать глубже или просто защищает других ради принципа.
Почему просто не соблюдать правила и торговать точно по рыночным ценам? А если нужно защищаться от реквотов, то можно выставить допустимый слиппаж.
А если нужно защищаться от реквотов, то можно выставить допустимый слиппаж.
Вот ответ полученный в свое время мною от Stringo в личной переписке касающейся такой ситуации:
"если цены не было в потоке (на быстром рынке она могла уйти из буфера) то даётся однозначный реквот без проверки слиппажа".
Т.е. в подобных ситуациях (быстрый рынок или недостаточно быстрая связь терминала с сервером) возможность закрыть по "текущей рыночной цене" (указав например "0" в качестве параметра) могла бы помочь с однозначным закрытием позиции. Ну а что касается притензий что цена "не совсем" та на которую клиент рассчитывал, так ведь явно указав параметром "текущая рыночная цена" он с этим уже как бы согласился.
Хотя, справедливости ради, надо заметить что "воя" в таких случаях все равно будет предостаточно. :) Посему и реализация такого варианта - на усмотрение разработчика. Хотя лично мне это (как вариант) в принципе понравилось бы. :)
Во-первых. Может стоит заглянуть в бумажки, к-рые мы подписываем с брокерами? Наверняка многие в своих договорах (в разделе "по телефону") увидят "По Рынку" как один из вариантов общения с ДЦ, что-то типа:
...
Нет необходимости указывать цену, достаточно сказать: "По рынку".
Рыночный ордер ... будет исполнен при первом, с момента установки ордера, возникшем на рынке предложении ...
...
Во-вторых. А кто просит разработчиков чуть ли не менять идеологию продукта? Не надо править существующие функции (если будете править под каждого из нас ...), достаточно добавить отдельную функцию ОрдерПоРынку() - и в этом случае вся ответственность за последствия употребления ложится на трейдера.
А функция все-таки будет полезна.
Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
- человек думал, что совершит сделку по одной цене, а на самом деле
цены давно уже изменились и ему дают реквот
- человек пишет настолько опасный и зацикленный код, что его никак
нельзя пропускать к серверу (отлов грубейших ошибок на раннем
этапе прямо в терминале позволяет снизить нагрузку на сервер)
- обработка заявок не должна содержать возможности предъявления
претензий из-за подмены условия "сделка по цене, точно заявленной
клиентом" на "сделка по рыночной цене", когда сразу же
родится неувядающий негативный фон "открывают как хотят,
верить нельзя", подпитываемый недоброжелателями.
- исключить ситуации, когда безбашенные эксперты пытаются втупую
совершают десятки и сотни тысяч неудачных торговых транзакций
в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.Еще раз.
Речь здесь с самого начала идет лишь о замене закешированного значения Ask или Bid в вызове OrderClose() закешированным аналогичным образом значением, доступным через OrderClosePrice, т.е. об удобстве использования
вместо громоздкого
Как последняя конструкция поможет избежать озвученных проблем по сравнению с вызовом одной строкой? Скорее всего, наоборот, она может послужить дополнительным источником ошибок среди неопытных экспертописателей и как раз поспособствует их возникновению.
Совершенно непонятны причины такого мощного противодействия с привлечением тематики намного более сложного уровня, которая никак не меняет логики значений Ask и Bid и вызовов OrderClosePrice() и RefreshRates() в функции start().
Да еще с применением многочисленных инсинуаций про неких безбашенных экспертописателей с их заблуждениями и искажением смысла сказанного оппонентом. Выглядит, по крайней мере, неэтично.
Не знаю, зачем Вам понадобилось мое видение на эти проблемы. И какое отношение эти проблемы имеют к топику.
Предложите свое видение, как принимать заявки в коде так, чтобы избежать проблем:
- человек думал, что совершит сделку по одной цене, а на самом деле
цены давно уже изменились и ему дают реквот
- человек пишет настолько опасный и зацикленный код, что его никак
нельзя пропускать к серверу (отлов грубейших ошибок на раннем
этапе прямо в терминале позволяет снизить нагрузку на сервер)
- обработка заявок не должна содержать возможности предъявления
претензий из-за подмены условия "сделка по цене, точно заявленной
клиентом" на "сделка по рыночной цене", когда сразу же
родится неувядающий негативный фон "открывают как хотят,
верить нельзя", подпитываемый недоброжелателями.
- исключить ситуации, когда безбашенные эксперты пытаются втупую
совершают десятки и сотни тысяч неудачных торговых транзакций
в сутки
Жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий. Но главное, трейдер должен принять простую вещь "процесс асинхронны" - это снимает 80% всех проблем в коде.И так по пунктам:
1. Если человек думал, что совершит сделку по одной цене, то он явно должен указать эту цену при вызове торговой функции. В этом случае, при невозможности проведения операции по данной цене, он получит реквот. Если же человек хочет провести сделку по текущей рыночной цене на момент запроса торговой операции, он указывает в качестве цены "0" и не имеет притензий к тому что цены давно уже изменились, что будет по тому и отработает. Т.е. та цена которая должна была быть в реквоте и будет ценой проведения торговой операции.
2. Тут очень много субъективизма. Объективно можно писать настолько же опасный и зацикленный код придерживаясь правила что в OrderClose для Buy-ордеров надо указывать Bid, а для Sell-ордеров Ask. На практике же ошибок такого плана станет гораздо меньше ибо уверен, что большинство неопытных программеров экспертов будут работать именно по рынку (так будет проще программировать). И как раз ошибок в этих операциях будет меньше ибо сами операции будут трактоваться однозначно. А по поводу притензий (а они естественно будут) - см. пункт 1 (клиент САМ согласился проводить операцию по рынку и отказался контролировать предложенную цену).
3. По поводу подмены условия "сделка по цене, точно заявленной клиентом" на "сделка по рыночной цене", так нет никакой подмены! Функционал не заменяется, а расширяется!!! Если клиент хочет сделку по точно заявленной цене - он указывает эту цену, если же он хочет сделку по рыночной цене - он указывает "0", тем самым соглашаясь на любую предложенную цену. Так что все четко прописано и клиент может пользоваться на свое усмотрение любым функционалом.
4. Если безбашенные эксперты будут пытаться втупую совершают десятки и сотни тысяч торговых транзакций в сутки пользуясь расширенным функционалом, то как раз все эти операции будут корректными, ибо все будут проводиться по текущей рыночной цене и какие тогда могут быть притензии к этим экспертам? А написать безбашенный эксперт можно и с текущим функционалом всего лишь следую определенным правилам. Т.е. расширенный функционал не ведет к дополнительным проблемам при написании экспертов, а как раз наоборот упрощает проведение корректных торговых операций (естественно клиент сам берет на себя ответственность при использовании возможности проводить операцию по текущей рыночной цене).
Ну и наконец "жесткий контроль торговых заявок позволяет останавливать экспертописателей и заставляет их более осознанно подходить к программированию своих стратегий" конечно важен, однако этот контроль никуда и не исчезает если клиент использует четко указанные цены в торговых операциях. В случае же если клиент сознательно соглашается работать "по рынку" (указав соответствующее значение параметра торговой функции), он сам берет на себя ответственность за собственное решение. А вот как раз программирование торговой стратегии в этом случае технически упрощается и следовательно ведет к уменьшению вероятности допустить ошибку.
Еще раз хочу прокомментировать, я не предлагаю ломать, я предлагаю расширить! Хочет клиент контролировать цену (и в случае чего получать реквот) - пользуется имеющимся функционалом, хочет работать "по рынку" (полагаясь на цены предлагаемые брокером) - пользуется возможностью указать "по рынку".
Все выше изложенное разумеется ИМХО и реализация предложенного варианта исключительно на усмотрение разработчиков.