Вопросы от "чайника" - страница 176

[Yedelkin]

Karlson:

3Б.  Закрытие частично открытием половинного селла - OUT. 

  Плохо :/  Получается, что в истории может быть несколько сделок со свойством OUT, а позиция при этом будет продолжать существовать.

[Anatoli Kazharski]

Yedelkin:
  Плохо :/

Почему плохо? Всё ведь просто, если я правильно Вас понял. Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью.

[Yedelkin]

tol64:
Почему плохо? Всё ведь просто, если я правильно Вас понял. Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью.

Плохо вот почему. У Вашего подхода "Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью" есть одна особенность, которая мне представляется громоздкой, а именно: необходимость каждый раз дополнительно проверять наличие сведений о позиции в базе терминала.

Все мы прекрасно знаем, что сведения в базу терминала попадают с некоторым запаздыванием относительно реального положения дел. Поэтому не исключены ситуации, когда проверка выдаёт результат типа "OUT и позиция есть", а в реальности эта сделка полностью позицию закрыла. Т.е. можно элементарно получить недостоверную информацию и на её основании предпринять ошибочные шаги. ..Либо придётся придумывать дополнительные проверки, задержки - кто во что горазд.

А ведь можно обойтись и без этих наворотов. В частности, без проверок на наличие позиции. Для этого достаточно оставить взаимно-однозначное соответствие между закрытием позиции и свойством DEAL_ENTRY_OUT (соответствие - как оно сейчас и преподносится в Справочнике), а сокращение объёма позиции выделить в отдельное свойство сделки. Тогда будет достаточно найти в истории (HistorySelectByPosition) всего одну сделку со свойством DEAL_ENTRY_OUT и гарантированно знать, что позиция не сокращена, а именно закрыта, и что уже ни при каких обстоятельствах она не может быть перевёрнута.

[Anatoli Kazharski]

Yedelkin:

Плохо вот почему. У Вашего подхода "Если OUT и позиция есть, то было сокращение объёма. Если OUT и позиции нет, то позиция была закрыта полностью" есть одна особенность, которая мне представляется громоздкой, а именно: необходимость каждый раз дополнительно проверять наличие сведений о позиции в базе терминала.

Все мы прекрасно знаем, что сведения в базу терминала попадают с некоторым запаздыванием относительно реального положения дел. Поэтому не исключены ситуации, когда проверка выдаёт результат типа "OUT и позиция есть", а в реальности эта сделка полностью позицию закрыла. Т.е. можно элементарно получить недостоверную информацию и на её основании предпринять ошибочные шаги. ..Либо придётся придумывать дополнительные проверки, задержки - кто во что горазд.

А ведь можно обойтись и без этих наворотов. В частности, без проверок на наличие позиции. Для этого достаточно оставить взаимно-однозначное соответствие между закрытием позиции и свойством DEAL_ENTRY_OUT (соответствие - как оно сейчас и преподносится в Справочнике), а сокращение объёма позиции выделить в отдельное свойство сделки. Тогда будет достаточно найти в истории (HistorySelectByPosition) всего одну сделку со свойством DEAL_ENTRY_OUT и гарантированно знать, что позиция не сокращена, а именно закрыта, и что уже ни при каких обстоятельствах она не может быть перевёрнута.

В OnTrade() ведь мы получаем ответ от сервера. То есть, если проверять событие в OnTrade(), то мы уже будем точно знать, есть позиция или нет. Хотя можно было бы сделать штатные варианты типа DEAL_ENTRY_FULLOUT (полное закрытие) или  DEAL_ENTRY_PARTOUT (частичное закрытие), чтобы всё было идеально элегантно. )))

А пока можно сделать отдельные функции, чтобы не вводить каждый раз "громоздкие проверки". 

[Yedelkin]

tol64:

Хотя можно было бы сделать штатные варианты типа DEAL_ENTRY_FULLOUT (полное закрытие) или  DEAL_ENTRY_PARTOUT (частичное закрытие), чтобы всё было идеально элегантно. )))

 О том и речь.. Не надо даже будет делать дополнительные проверки в том же OnTrade, которые на фоне предложенного решения (FULLOUT / PARTOUT) всё-таки выглядят громоздко.

[Anatoli Kazharski]

Yedelkin:
 О том и речь.. Не надо даже будет делать дополнительные проверки в том же OnTrade, которые на фоне предложенного решения (FULLOUT / PARTOUT) всё-таки выглядят громоздко.

Попробуйте оформить в виде предложения в Сервисдеск. Может быть рассмотрят и однажды реализуют.

[Yedelkin]

tol64:
Попробуйте оформить в виде предложения в Сервисдеск. Может быть рассмотрят и однажды реализуют.

   Да уже сделал :) Как ошибку языка ..Ого, час сочинял.

[Anatoli Kazharski]

Yedelkin:
   Да уже сделал :) Как ошибку языка ..Ого, час сочинял.

Это всё же нельзя назвать ошибкой. Но что же теперь поделаешь раз уже отправили. ))

[Yedelkin]

tol64:
Это всё же нельзя назвать ошибкой. Но что же теперь поделаешь раз уже отправили. ))    

  Ну, здесь уже немножко в силу вступают оценочные категории :) Отнесение к категории Errors я попытался обосновать :)

[Валерий]

Yedelkin:

 Да, каждому периоду соответствует определённое значение. Пару лет назад кто-то выкладывал на форуме. Самостоятельно можете выяснить, запустив строчку, аналогичную нижеприведённой:

 

Скрипт распечатает значения ENUM_TIMEFRAMES для всех периодов в десятичной системе:

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+