Нестабильность тестера советников - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пытаемся резюмировать:
Это - гадание.
Нужен внятный ответ разработчиков.
Хорошо если дождёмся этих комментариев. :(
Услышать бы хотя бы практические рекомендации от корифеев. Пытаюсь резюмировать:
Нужно нормализовать ЛЮБЫЕ цены, подаваемые в функции OrderSend(), OrderClose(), OrderCloseBy() и OrderModify()
Так?
во избежание трудно определяемых ошибок, при переносе на терминал неизвестной компании у клиента. при использовании точных цен - да. при сравнениях необязательно.
Это - гадание.
Нужен внятный ответ разработчиков.
Кто б спорил - конечно нужен. Дождёмся ли?
Ещё вопрос к разработчикам есть:
- почему при заданном параметре Slipage 1п в OrderSend()/OrderClose() реальное открытие/закрытие бывает с проскальзыванием 3-5 и более пунктов?
аналогичный вопрос: почему при слипаже в 100 пип и больше, на быстром рынке невозможно открыть ордер, хотя цена не выходит за пределы слипажа ?
аналогичный вопрос: почему при слипаже в 100 пип и больше, на быстром рынке невозможно открыть ордер, хотя цена не выходит за пределы слипажа ?
Этот вопрос немного проще т.к. на него уже давал ответ Ренат:
Максимальное отклонение не действует, если на сервер приходит явно и сильно устаревшая заявка (что часто бывает на сильных движениях).
В этом случае торговый сервер сам безусловно отдает реквот даже без транслировании заявки дилеру. То есть, сервер получает устаревшую цену в торговой заявке и говорит клиенту:
Фактически максимально допустимый слиппаж (допустимое отклонение) в функции OrderSend не более 5 пунктов (или 1-2 спреда). БОльшее значение все равно не будет принято во внимание на торговом сервере при анализе цен.
Реквот при слиппаже 10 однозначно означает реально устаревшую (но "удачную" для трейдера) цену. Как раз описываемый мною случай.
аналогичный вопрос: почему при слипаже в 100 пип и больше, на быстром рынке невозможно открыть ордер, хотя цена не выходит за пределы слипажа ?
Ответ на этот вопрос был. Слипаж не может быть больше 10 пунктов. Ответ на этот вопрос был когда-то сделан. Но что такое 10 пунктов для кроссов.
дело не в этом, даже если колебания цены не выходят за пределы максимально допустимого слипажа 5-10 пип, все равно есть проблема открыть ордер, или закрыть, а на пятизнаке и подавно...
во избежание трудно определяемых ошибок, при переносе на терминал неизвестной компании у клиента. при использовании точных цен - да. при сравнениях необязательно.
к сожалению и при сравнениях тоже надо ...
у меня часто вылетает в условии не туда при таких сравнениях
OrderStopLoss()==0.
Поэтому нормализую АБСОЛЮТНО ВСЁ. Причём с учётом тиксайз... случаи разные бывают.
ND(OrderStopLoss())==ND(0)
А при нормализации я уже давно забыл, что такое проблемы с открытием/закрытием... зачем голову ломать, когда проще дописать пару лишних буковок.
к сожалению и при сравнениях тоже надо ...
у меня часто вылетает в условии не туда при таких сравнениях
OrderStopLoss()==0.
Поэтому нормализую АБСОЛЮТНО ВСЁ. Причём с учётом тиксайз... случаи разные бывают.
ND(OrderStopLoss())==ND(0)
А при нормализации я уже давно забыл, что такое проблемы с открытием/закрытием... зачем голову ломать, когда проще дописать пару лишних буковок.
совершенно согласен. я имел ввиду сравнение по модулю типа if( x > y), если говорить осравнении по абсолютному значеню, то нормализовать надо, тем более что вызов функции очень прост и надо дописать лишь nd(), так что даже переделка других своветников не занимает много времени и сил...
Но это заслуга "языка". ;)
А ведь чуть изменив логику его реализации - тысячи ошибок исчезли....
взять бы ту же операцию деления. Кто мешает для этой операции задействовать промежуточный тип не зависящий от тира операндов, а double...
;)