Выпущен MetaTrader 4 Client Terminal build 600 с обновленным языком MQL4 и Маркетом приложений - страница 98
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
На форуме по MQL5 разработчики сообщали, что в историях "никакая упорядоченность не гарантируется". Реально встречавшиеся мне исторические списки там были упорядочены по тикетам. Думается, и здесь так же. В случае синхронизации времени на сервере с астрономическим со сдвигом на 2 секунды назад - что будет с упорядоченностью по времени? Тикеты при сдвиге времени назад продолжают наращиваться. Однако и в их последовательность, думается, можно влезть специальными средствами, также как в первичные ключи в базах данных.
ЗЫ. Для ясности лучше бы говорить об упорядоченности не по "времени", а по "штампу времени"
По итогам обсуждения этой темы напрашивается вывод, что упорядоченность списка ордеров никто не может гарантировать. Поэтому необходимо использовать более сложные процедуры гарантированной сортировки.
Жаль что не было комментариев от разработчиков.
По итогам обсуждения этой темы напрашивается вывод, что упорядоченность списка ордеров никто не может гарантировать. Поэтому необходимо использовать более сложные процедуры гарантированной сортировки.
Жаль что не было комментариев от разработчиков.
Ну, по-крайней мере, чтобы найти несколько однозначно последних, нужно отбирать их по времени. По времени открытия - последние открытые, по времени закрытия - последние закрытые. Как ни крути время сервера, а количество секунд с 01.01.1970 до времени выбранного ордера останется количеством секунд. У одного ордера их больше, у другого меньше. Сдвигай/не сдвигай время сервера, а разница между временами этих ордеров останется неизменной. Значит можно однозначно найти самый последний, предпоследний, пред-предпоследний, и т.д.
Хотя конечно - комментарий от разработчиков не помешал бы.
. Сдвигай/не сдвигай время сервера, а разница между временами этих ордеров останется неизменной. Значит можно однозначно найти самый последний, предпоследний, пред-предпоследний, и т.д.
Хотя конечно - комментарий от разработчиков не помешал бы.
В истории торговли с одним клиентом отметки времени при сдвиге назад на 2 секунды, скорее всего, останутся возрастающими. На 20 секунд - уже большой вопрос, при ловле новостных скачков отметка времени закрытия запросто может оказаться меньше отметки времени открытия сделки. Надежнее упорядочивать по тикетам.
Лет пять назад спрашивал, какие требования предъявляет поставщик торгового сервера Метатрейдер к синхронизации серверного времени с астрономическим. Ответили, что никаких, на усмотрение администратора сервера.
Нормальная реализация простановки неубывающих штампов времени имеется, например, на бирже. По сведениям за март 2010 (Дмитрий Глотиков, Фондовая биржа РТС, http://forum.rts.micex.ru/viewtopic.asp?t=15432): GPS приемник (с погрешность до 50 наносекунд) стоит на собственном NTP сервере, ядро торговой системы работает в режиме постоянной синхронизации времени с "плавным подводом" часов. Похоже, на этой бирже и точность времени очень хорошая, и последовательность событий нарушить трудно.Здравствуйте! Имея советники на предыдущей версии МетаТрейдара я обновил терминал. После вернулся обратно к 509. Так что советники "побывав" в 60... билде, вернулись в версию терминала, на котором были написаны.
Вопрос такой: что делать с теми экспертами, которые перестали открывать сделки на тестере после "возвращения" и с теми, которые проверить больше не получается (кнопка start в тестере просто не отвечает на клик)?
... Надежнее упорядочивать по тикетам. ...
по тикетам упорядочивать некорректно, т.к. тикет отложенного ордера может быть выставлен раньше, а сработает позже другого. Второй нюанс - при частичном закрытии ордера номер тикета изменится, хотя время открытия останется старым.
Вот уже несколько страниц обсуждается вопрос сортировки ордеров, но я так и не пойму, почему этот вопрос вызывает разногласия? Разве не логично сортировать ордера рыночные по времени открытия, а исторические по времени закрытия? Или это невозможно сделать???
Почему ссылаются на сортировку ордеров на сервере ДЦ? Разве OrdersHistoryTotal(); берёт ордера с сервера ДЦ??? Может я уже отстал, но как я помню количество ордеров в истории зависит от установки фильтра в закладке "История Счета".
Хотелось-бы услышать мнение представителей MQ по этому вопросу.
Вот уже несколько страниц обсуждается вопрос сортировки ордеров, но я так и не пойму, почему этот вопрос вызывает разногласия? Разве не логично сортировать ордера рыночные по времени открытия, а исторические по времени закрытия? Или это невозможно сделать???
Почему ссылаются на сортировку ордеров на сервере ДЦ? Разве OrdersHistoryTotal(); берёт ордера с сервера ДЦ??? Может я уже отстал, но как я помню количество ордеров в истории зависит от установки фильтра в закладке "История Счета".
Хотелось-бы услышать мнение представителей MQ по этому вопросу.
По времени сортировать не логично. За одну секунду может быть открыто несколько ордеров. Логично сортировать по тикетам, т.к. это уникальный ключ, и сортировка по возрастанию (или убыванию) тикетов дает возможность бинарного поиска.
И в терминале после его старта имеем сортировку истории по возрастанию тикетов. Потом, правда, в "хвост" истории ордера падают в порядке закрытия, но после перезагрузки вновь отсортируются по тикетам.
Потому и сказано "Хотелось-бы услышать мнение представителей MQ по этому вопросу."
На сколько я понимаю, при открытии\закрытии ордеров учитываются миллисекунды и соответственно 2 ордера в одном ДЦ не могут закрыться в одну миллисекунду и сортировка не будет нарушена.
А вот когда\если будет официальный ответ от представителей MQ будет всё понятно. А проверить самостоятельно в коде никто не запрещает.
Вот что происходит сейчас. Если у пользователя вашего советника поставлен фильтр "Выбор периода" -> "Сегодня", а в коде идёт поиск ордера закрытого вчера, то этот ордер не будет найден. Будет-ли такой код с таким OrdersHistoryTotal(); работать правильно, так как задумано??? Специально сейчас проверил, OrdersHistoryTotal(); показывает количество ордеров в зависимости от фильтра в закладке "История Счета"
Ну, по-крайней мере, чтобы найти несколько однозначно последних, нужно отбирать их по времени. По времени открытия - последние открытые, по времени закрытия - последние закрытые. Как ни крути время сервера, а количество секунд с 01.01.1970 до времени выбранного ордера останется количеством секунд. У одного ордера их больше, у другого меньше. Сдвигай/не сдвигай время сервера, а разница между временами этих ордеров останется неизменной. Значит можно однозначно найти самый последний, предпоследний, пред-предпоследний, и т.д.
Хотя конечно - комментарий от разработчиков не помешал бы.
Многого не предусмотрено! Приходится изгаляться, чтобы иметь, как минимум, контроль над ситуацией на графике! А управление ситуацией полностью в руках сервера!
Потому и сказано "Хотелось-бы услышать мнение представителей MQ по этому вопросу."
На сколько я понимаю, при открытии\закрытии ордеров учитываются миллисекунды и соответственно 2 ордера в одном ДЦ не могут закрыться в одну миллисекунду и сортировка не будет нарушена.
Торговый сервер MT5, если верить разработчикам, в состоянии обслужить десять тысяч ордеров в секунду. Четверку к этому показателю приближают. Миллисекунд не хватит.
Пусть даже один ордер в секунду. Открытие получило штамп времени 21:00:03, затем сдвиг серверного времени назад на 10 секунд, в 20:59:58 серверного времени закрытие с отметкой 20:59:58. Продолжительность сделки реальная 5 секунд, по отметкам времени минус 5 секунд. Что здесь неверно?
На мой взгляд, неверным является полное отсутствие требований поставщика к аппаратному и программному окружению сервера в части синхронизации серверного времени с астрономическим. Для решаемой финансовой задачи соблюдение последовательности событий - критически важная вещь. Совсем по-хорошему Метаквотес могли бы поставлять в составе своих программных средств синхронизацию, достаточную для воспроизведения в истории реальной последовательности событий. Или, хотя бы, средства "плавного" сдвига времени назад. Как один из элементов, не отсылать терминалам тики с отметкой серверного времени меньше уже достигнутой. Это несложно, также как и бесплатная синхронизация.