Надёжные реализации экспертов - страница 2

 
shanty:
Ну а как тогда?
Вы на правильном пути своими мыслями. 
 
shanty:

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

Я думаю, что, например, удалять ордера можно так:

1. На каждом тике ищем свои ордера.

2. Если есть просроченные пытаемся из снести. 

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

4. На следующем тике проверяем положение флага, и, если  он в положении не удалось снести ордер, то пытаемся снова.

5. Если ордер снесли, флаг возводим в положение, мол всё произошло удачно. Значится больше не вызываем данную функцию, до наступления соответствующих условий.

Логично? 

Немного не так.

Искать свои ордера на каждом тике совсем не обязательно. Я храню тикеты ордеров в массиве и на каждом тике проверяю состояние ордеров перебирая этот массив. В случае изменений какого либо ордера перезаполняю массив.

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

Соответственно список задач сокращается и никакие дополнительные флаги не нужны.

 
shanty:

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

Я думаю, что, например, удалять ордера можно так:

1. На каждом тике ищем свои ордера.

2. Если есть просроченные пытаемся из снести. 

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

4. На следующем тике проверяем положение флага, и, если  он в положении не удалось снести ордер, то пытаемся снова.

5. Если ордер снесли, флаг возводим в положение, мол всё произошло удачно. Значится больше не вызываем данную функцию, до наступления соответствующих условий.

Логично? 

Чтобы принципиально не ломать свой взгляд на мир, можно пойти простым путем. Если с первого раза не  удалось что-то сделать, для какого-то ордера, создаем глобальную переменную, а в ней код того, что вам надо сделать. Еще одну функцию надо будет написать, которая работает на каждом тике, и если у какого-то ордера есть глобальная переменная, функция доделывает дело. 
 
AlexeyVik:

Немного не так.

Искать свои ордера на каждом тике совсем не обязательно. Я храню тикеты ордеров в массиве и на каждом тике проверяю состояние ордеров перебирая этот массив. В случае изменений какого либо ордера перезаполняю массив.

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

Соответственно список задач сокращается и никакие дополнительные флаги не нужны.

Если пришлось перезапустить терминал или эксперта? 
 
Integer:
Если пришлось перезапустить терминал или эксперта? 
В ините проверяется наличие своих ордеров и заполняется массив. Следующая перезапись массива только после изменения количества своих ордеров. Т.е. после открытия, закрытия по алгоритму или OrderCloseTime() > 0
 
AlexeyVik:
В ините проверяется наличие своих ордеров и заполняется массив. Следующая перезапись массива только после изменения количества своих ордеров. Т.е. после открытия, закрытия по алгоритму или OrderCloseTime() > 0
Как надежно срабатывает это в ините? Тестировали разные экстремальные варианты? 
 
Integer:
Как надежно срабатывает это в ините? Тестировали разные экстремальные варианты? 
А какие сомнения? Массив объявлен на уровне глобальных переменных и доступен из любого места программы...
 
AlexeyVik:
А какие сомнения? Массив объявлен на уровне глобальных переменных и доступен из любого места программы...
В массиве нет сомнений.
 
shanty:

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

Я думаю, что, например, удалять ордера можно так:

1. На каждом тике ищем свои ордера.

2. Если есть просроченные пытаемся из снести. 

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

4. На следующем тике проверяем положение флага, и, если  он в положении не удалось снести ордер, то пытаемся снова.

5. Если ордер снесли, флаг возводим в положение, мол всё произошло удачно. Значится больше не вызываем данную функцию, до наступления соответствующих условий.

Логично? 

1. - да. Сохранение тикетов в свой массив (за которым потом и следить) или составление списка заново на каждом тике не так уж и сильно влияет на быстродействие эксперта, как это может показаться. Количество ордеров - достаточно небольшая величина по сравнению с количеством баров, по которым эксперт должен рассчитать значения той же МА. Что уж говорить о более серьезных расчетах?

2. - 5. На мой взгляд, не нужно всех этих премудростей с результатами предыдущих запросов. Гораздо проще и универсальнее сделать обычный алгоритм, который проверяет каким должно быть на текущем тике состояние ордеров. Если нужно удалить ордер, удаляем его. Если на следующем тике обнаруживается тот же ордер вновь, то не настолько уж и важно, почему на предыдущем тике не удалось его удалить (логика не "Кто виноват?", а "Что делать?"). Естественно, все это при условии, что перед совершением торговой операции проведены все проверки на возможность совершения такой операции: ордер не заморожен, рынок открыт, разрешена автоторговля и т. д.

 
shanty:

На всякий случай напишу, что вот на это предложение обратите особое внимание в посте выше:

Scriptong:

...

Естественно, все это при условии, что перед совершением торговой операции проведены все проверки на возможность совершения такой операции: ордер не заморожен, рынок открыт, разрешена автоторговля и т. д.

в т.ч., обработка ошибок при удалении и модификации ордеров может снимать множество вопросов и проблем. Как-то так, если кратко.


Те, кто писали выше - опытные люди. То, что они говорят, думаю, надо внимательно осмысливать. Конечные же кодовые решения, естественно, остаются за вами. В том числе, поскольку советуемые вам, как и принимаемые вами, решения могут быть различающимися (в т.ч., зависеть от ситуаций/задач/целей, личного опыта, каких-либо личных предпочтений и/или мотивов).


А для простоты понимания других здесь, и в целом для себя, если что (в т.ч., и чтоб мозаика, при необходимости сходилась), помогут и учебник, и документация, и коды Игоря Кима, и поиск по сайту.

На всякий случай приведу и три выдержки из Учебника, из глав по торговым операциям. В Учебнике и Документации много полезной инфы и проще может быть потом понимать, что могут иметь в виду другие. Тем более, что в постах на форуме какая-то инфа может, в т.ч., к примеру, подразумеваться писавшим какой-либо пост по умолчанию, и, соответственно, не быть достаточно понятна или упущена другим из виду в силу различных причин.

Выдержки из Учебника:

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


С момента, когда программа отдаёт торговый приказ (и одновременно с этим передаёт управление) клиентскому терминалу, до момента, кода управление возвращается в программу, программа находится в режиме ожидания ответа. В этот период в программе не осуществляется никаких действий. Управление возвращается в программу в соответствии с правилом исполнения вызова функции (сформировавшей торговый приказ).


Если торговый приказ был некорректным, то программа находится в режиме ожидания ответа непродолжительное время (период t 1 - t 4). Если же торговый приказ был одобрен клиентским терминалом и отправлен на сервер, то программа может находиться в режиме ожидания ответа в течение различного по продолжительности времени (t 1 - t 9), в зависимости от качества связи и времени принятия решения на сервере