Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
3Б. Закрытие частично открытием половинного селла - OUT.
Плохо :/
Почему плохо? Всё ведь просто, если я правильно Вас понял. Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью.
Плохо вот почему. У Вашего подхода "Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью" есть одна особенность, которая мне представляется громоздкой, а именно: необходимость каждый раз дополнительно проверять наличие сведений о позиции в базе терминала.
Все мы прекрасно знаем, что сведения в базу терминала попадают с некоторым запаздыванием относительно реального положения дел. Поэтому не исключены ситуации, когда проверка выдаёт результат типа "OUT и позиция есть", а в реальности эта сделка полностью позицию закрыла. Т.е. можно элементарно получить недостоверную информацию и на её основании предпринять ошибочные шаги. ..Либо придётся придумывать дополнительные проверки, задержки - кто во что горазд.
А ведь можно обойтись и без этих наворотов. В частности, без проверок на наличие позиции. Для этого достаточно оставить взаимно-однозначное соответствие между закрытием позиции и свойством DEAL_ENTRY_OUT (соответствие - как оно сейчас и преподносится в Справочнике), а сокращение объёма позиции выделить в отдельное свойство сделки. Тогда будет достаточно найти в истории (HistorySelectByPosition) всего одну сделку со свойством DEAL_ENTRY_OUT и гарантированно знать, что позиция не сокращена, а именно закрыта, и что уже ни при каких обстоятельствах она не может быть перевёрнута.
Плохо вот почему. У Вашего подхода "Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью" есть одна особенность, которая мне представляется громоздкой, а именно: необходимость каждый раз дополнительно проверять наличие сведений о позиции в базе терминала.
Все мы прекрасно знаем, что сведения в базу терминала попадают с некоторым запаздыванием относительно реального положения дел. Поэтому не исключены ситуации, когда проверка выдаёт результат типа "OUT и позиция есть", а в реальности эта сделка полностью позицию закрыла. Т.е. можно элементарно получить недостоверную информацию и на её основании предпринять ошибочные шаги. ..Либо придётся придумывать дополнительные проверки, задержки - кто во что горазд.
А ведь можно обойтись и без этих наворотов. В частности, без проверок на наличие позиции. Для этого достаточно оставить взаимно-однозначное соответствие между закрытием позиции и свойством DEAL_ENTRY_OUT (соответствие - как оно сейчас и преподносится в Справочнике), а сокращение объёма позиции выделить в отдельное свойство сделки. Тогда будет достаточно найти в истории (HistorySelectByPosition) всего одну сделку со свойством DEAL_ENTRY_OUT и гарантированно знать, что позиция не сокращена, а именно закрыта, и что уже ни при каких обстоятельствах она не может быть перевёрнута.
В OnTrade() ведь мы получаем ответ от сервера. То есть, если проверять событие в OnTrade(), то мы уже будем точно знать, есть позиция или нет. Хотя можно было бы сделать штатные варианты типа DEAL_ENTRY_FULLOUT (полное закрытие) или DEAL_ENTRY_PARTOUT (частичное закрытие), чтобы всё было идеально элегантно. )))
А пока можно сделать отдельные функции, чтобы не вводить каждый раз "громоздкие проверки".Хотя можно было бы сделать штатные варианты типа DEAL_ENTRY_FULLOUT (полное закрытие) или DEAL_ENTRY_PARTOUT (частичное закрытие), чтобы всё было идеально элегантно. )))
О том и речь.. Не надо даже будет делать дополнительные проверки в том же OnTrade, которые на фоне предложенного решения (FULLOUT / PARTOUT) всё-таки выглядят громоздко.
Попробуйте оформить в виде предложения в Сервисдеск. Может быть рассмотрят и однажды реализуют.
Да уже сделал :) Как ошибку языка ..Ого, час сочинял.
Это всё же нельзя назвать ошибкой. Но что же теперь поделаешь раз уже отправили. ))
Да, каждому периоду соответствует определённое значение. Пару лет назад кто-то выкладывал на форуме. Самостоятельно можете выяснить, запустив строчку, аналогичную нижеприведённой:
Скрипт распечатает значения ENUM_TIMEFRAMES для всех периодов в десятичной системе: