Надёжные реализации экспертов - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Те, кто писали выше - опытные люди. То, что они говорят, думаю, надо внимательно осмысливать.
Согласен. Вот я пока что и осмысливаю. И мысли у меня такие же почти как и раньше
А для простоты понимания их слов, и в целом для себя, если что (в т.ч., и чтоб мозаика, при необходимости сходилась), помогут и учебник, и документация, и коды Игоря, Кима и поиск по сайту.
У Кима функции, а у меня - другое. Тут нужно как-то продумать реализацию работы функции (функций) и эксперта. А сами функции у меня есть, да и продумано там уже всё (все проверки на свободный торговый потом, возможности торговли..).
Немного не так.
Искать свои ордера на каждом тике совсем не обязательно. Я храню тикеты ордеров в массиве и на каждом тике проверяю состояние ордеров перебирая этот массив. В случае изменений какого либо ордера перезаполняю массив.
Удаление отложенных ордеров, как и закрытие рыночных надо ставить в цикл, выходом из которого будет выполнение операции.
Соответственно список задач сокращается и никакие дополнительные флаги не нужны.
Так я не совсем понимаю, резонность заведения данного массива. Ведь что пробежать по массиву, что по ордерам чтоб выбрать нужный, .. разницы то особой нет. Ведь всё-равно, в массиве хранится будут, как я понял все тикеты. Если какой-то ордер удалился, то с данного массива его убираем, а если открылся, то добавляем, верно?
Но после любой операции, придётся массив перебирать, дабы заполнить "пустоты", т.е. сдвинуть значения, чтоб исключить "пустые ячейки". Но, опять-таки, суть не в выборе.
Например, я на каждом тике ищу свои ордера. И накаждом тике я знаю, сколько ордеров и какого типа у меня имеется. Если сигнал, например, - купить, а зависли продажи (стоповые ордера), - нужно их снести, чтоб не висели. Вот в чём суть. Так вот цепочка:
- Поиск ордеров на каждом тике.
- Получение торгового сигнала.
- Если сигнал в одну сторону, а имеются висяки по предыдущему сигналу, нужно снести висяки.
- Висяки пытаемся снести.
- Если не снеслись, то... Ждём нового тика.
Цепочка повторяется,... Если висяки есть, значит снова пробуем их снести. И тд. Не логично? Зачем тут запоминать тикеты? Что это нам даст?
Так я не совсем понимаю, резонность заведения данного массива. Ведь что пробежать по массиву, что по ордерам чтоб выбрать нужный, .. разницы то особой нет.
Разница есть и не малая. Если на одном счёте будут работать несколько советников, то каждый из них должен перебрать ВСЕ ордера, а так только свои.
Дальше обрати внимание на слова Дианы об обработке ошибок, что исключает необходимость на следующем тике проверять выполнение команды удаления или закрытия ордера.
Разница есть и не малая. Если на одном счёте будут работать несколько советников, то каждый из них должен перебрать ВСЕ ордера, а так только свои.
Алексей, Вы хотите сказать, что OrdersTotal() возвращает не кол-во ордеров, открытых советником, а вообще открытых всеми советниками терминала?
Дальше обрати внимание на слова Дианы об обработке ошибок, что исключает необходимость на следующем тике проверять выполнение команды удаления или закрытия ордера.
Немного не так.
Искать свои ордера на каждом тике совсем не обязательно. Я храню тикеты ордеров в массиве и на каждом тике проверяю состояние ордеров перебирая этот массив. В случае изменений какого либо ордера перезаполняю массив..
Так если на каждом тике мы свои ордера не ищем, а лишь проверяем состояние ордеров посредством глобального массива, откуда уверенность, что в тот момент, когда в глобальном массиве одно количество тикетов, а по факту уже другое?
И вообще, этот глобальные массив чтоб удобно было использовать будет иметь не одного измерение, судя по всему7 Иначе хз что за он в момент перебора...
Удаление отложенных ордеров, как и закрытие рыночных надо ставить в цикл, выходом из которого будет выполнение операции.
Соответственно список задач сокращается и никакие дополнительные флаги не нужны.
Но теоретически может не удалится или не закрыться ордера, не смотря на цикл. Ведь в нём будет N-ое количество попыток. По истечению... Выход из цикла и отработка дальше кода эксперта..
Алексей, Вы хотите сказать, что OrdersTotal() возвращает не кол-во ордеров, открытых советником, а вообще открытых всеми советниками терминала?
Это не я хочу сказать. Это сказано в документации.
Ошибки то проверяются, но это не гарантирует то, что команда удаления или закрытия, да и( или ) модификации, в том числе, реализуется успешно. Ну проверил, ну поток занет, занет... подождали.. и вышли. Не зависнуть же в этой функции пока она не исполнится. Логично? Всё-равно придётся чуть-что выйти из неё и выполнять другой код.
Так если на каждом тике мы свои ордера не ищем, а лишь проверяем состояние ордеров посредством глобального массива, откуда уверенность, что в тот момент, когда в глобальном массиве одно количество тикетов, а по факту уже другое?
И вообще, этот глобальные массив чтоб удобно было использовать будет иметь не одного измерение, судя по всему7 Иначе хз что за он в момент перебора...
Но теоретически может не удалится или не закрыться ордера, не смотря на цикл. Ведь в нём будет N-ое количество попыток. По истечению... Выход из цикла и отработка дальше кода эксперта..
Уверенность именно в обратном, потому и проверяется на OrderCloseTime() > 0
Размер массива должен быть динамический.
Количество попыток можно организовать как душа пожелает. Хоть в бесконечный цикл засунуть, это на любителя.
Разница есть и не малая. Если на одном счёте будут работать несколько советников, то каждый из них должен перебрать ВСЕ ордера, а так только свои.
Скорее всего, преждевременная оптимизация кода. Ничего страшного в переборе всех ордеров нет. Их не бывает очень много. Максимум, что видел на сегодняшний день, это 1000. Что такое 1000 итераций для современных компьютеров?
В случае со своим массивом ордеров перебор такого массива уложится в один проход только тогда, когда вообще не было никаких изменений. Во всех других случаях, потребуется, как минимум, два прохода. К примеру, при удалении ордера нужно будет переместить ордера сверху вниз на одну позицию (т. е. на каждый удаленный ордер приходится новый проход; можно и это оптимизировать, но приведет к усложнению кода).
Таким образом, если и будет выигрыш в скорости исполнения, то он будет настолько мизерный, что станет сопоставим с величиной погрешности измерений этой самой скорости. С другой стороны, механизм слежения за актуальностью массива ордеров - это лишний код, который требует отладки. Сталкивался с этой проблемой, когда писал копировщики сделок. Там, действительно, не уйти от своего массива, сохраняющего предыдущее состояние ордеров для сравнения с текущим состоянием. Написание и отладка такого блока занимают несравненно больше времени, чем код простого перебора всех ордеров с выбором "своих".
Поэтому, на мой взгляд, в тех задачах, где можно обойтись без ведения своего глобального массива ордеров, стоит применять простой вариант: пройтись по списку рабочих ордеров и записать "свои" ордера в локальный массив, с которым и иметь дело на текущем тике. На следующем тике вновь перебираются все ордера и составляется новый массив.
Jedem das seine. Но если ещё приходится перебирать ордера истории, то это ещё усложняет процесс. А в общем-то всё это на любителя. И может быть делается не ради ускорения. Мне почему-то так приятней, а иногда ещё и структуру использую. А что касается локального массива, так вот в нём-то как раз полнейшая бесполезность.
Jedem das seine. Но если ещё приходится перебирать ордера истории, то это ещё усложняет процесс.
История счета в МТ4 это вообще отдельный вопрос )) Она, к сожалению, устроена так, что зависит от действий пользователя: он может "спрятать" всю историю, установив соответствующие даты. Поэтому с историей счета в МТ4 лучше не связываться, а вести свою бухгалтерию. Таким образом, здесь как раз лучше вести свой массив, как Вы и говорите. А еще лучше - построить логику эксперта так, чтобы история счета вообще не использовалась, потому что гарантировать круглосуточную работу эксперта никто не может.
А в общем-то всё это на любителя. И может быть делается не ради ускорения. Мне почему-то так приятней, а иногда ещё и структуру использую. А что касается локального массива, так вот в нём-то как раз полнейшая бесполезность.
В чем же бесполезность локального массива? Возможно, я неоднозначно выразился. Массив объявлен как член класса и однократно (при инициализации программы) распределен на максимально разрешенное стратегией количество ордеров, что избавляет от "долгой" операции перераспределения памяти (ArrayResize) и гарантирует, что не будет ошибок при ее выделении. На каждом новом тике массив заполняется заново. Счетчик указывает количество заполненных элементов массива.
И да, конечно, при записи информации об ордерах это массив структур, что позволяет сохранять всю нужную информацию о каждом ордере. В Учебнике об этом не могли написать, т. к. тогда структур в MQL4 еще не было.