Библиотеки: LastOrder - страница 2

 
Aleksei Radchenko:

1. Пункт не существенный, профайлер часто косячит, согласен.

А вот по поводу 3тьего =)
Андрей, дело не в принте, а в том, что нельзя предпринимать дальнейшие действия, если нет уверенности что полученный тикет - последний. А в случае с грязным селектом, такой уверенности нет. Я бы просто пропустил этот тик.

Посты Рената читаю, также могу сказать, что в реальности терминал преподносит много сюрпризов. Поэтому весь свой код я подвергаю тщательному юнит тестированию и профилированию. И еще небыло у меня проекта, в котором не вылезла бы какая нибудь зловредная штука =) А когда мы работаем с деньгами - это не допустимо.

Я предложил альтернативу, возвращать флаг успеха и переносить курсор. =) 

Нет, как перфекционист перфекционисту, первый пункт не прощу )

Вот такой вот советник, попеременно компилируемый с вызовом М1 и М2 и тестируемый на всех тиках с 2008 года, выполняется ожидаемо за одно время:

bool flag = false;

void OnTick()
{
        M1();
//      M2();
}

void M1()
{
        int s;
        if ( flag )
                s = 1;
        else
                s = 2;
}

void M2()
{
        int s = (flag) ? 1 : 2;
}

2017.03.21 16:40:39.813 EURUSD,M5: 129422497 tick events (666879 bars, 129423498 bar states) processed in 0:00:17.047 (total time 0:00:56.890)

2017.03.21 16:38:26.788 EURUSD,M5: 129422497 tick events (666879 bars, 129423498 bar states) processed in 0:00:17.500 (total time 0:00:55.594)


А по поводу 3-го пункта — все равно не вижу смысла пропускать тик.

У меня много советников работали и работают на реалах всевозможных брокеров, и ошибочный Селект никогда никак не обрабатывался (принты выводились).

Не могу представить ситуацию, когда в синхронной 4-ке может задублироваться ордер из-за ошибки селекта.

 

Такой результат потому, что время выполнения функции по сравнению с временем на работу системы тестирования - мало.

Загоните функцию хотя бы в цикл на 10000. Тогда результаты будут более очевидными.

 
Aleksei Radchenko:

Такой результат потому, что время выполнения функции по сравнению с временем на работу системы тестирования - мало.

Загоните функцию хотя бы в цикл на 10000. Тогда результаты будут более очевидными.

Да нет же! Вот за год, но с циклом на 1000 итераций:

2017.03.21 17:09:49.020 EURUSD,M5: 27143066 tick events (75684 bars, 27144067 bar states) processed in 0:00:52.719 (total time 0:00:57.625)

2017.03.21 17:05:17.842 EURUSD,M5: 27143066 tick events (75684 bars, 27144067 bar states) processed in 0:00:52.704 (total time 0:00:55.157)

От увеличения до 10000 ничего не изменится, только время.


Почему не воспользуетесь советом и не погуглите на тему? Сразу же находятся очень похожие объяснения:

  • https://www.mql5.com/ru/forum/94893#comment_2779735
  • https://www.mql5.com/ru/forum/34093#comment_974172

Альтернативные реализации стандартных функций/подходов
Альтернативные реализации стандартных функций/подходов
  • www.mql5.com
NormalizeDouble Результат 1123275 и 1666643 в пользу MyNormalizeDouble (Optimize=1). Без оптимизации - быстрее раза в четыре (на память...
 

Обработать "грязный" Select можно в цикле просто поставить
ticket = -1;
break;

У меня вопрос. Где в документации написано, что ордера отсортированы по дате? Почему все-таки нет смысла перебирать все ордера?

 
Alexey Lopatin:

Обработать "грязный" Select можно в цикле просто поставить
ticket = -1;
break;

Вопрос заключался в том, зачем это делать.


Alexey Lopatin:

У меня вопрос. Где в документации написано, что ордера отсортированы по дате? Почему все-таки нет смысла перебирать все ордера?

Нигде. Я бы тоже на это не полагался бы.

 
Alexey Lopatin:

Обработать "грязный" Select можно в цикле просто поставить
ticket = -1;
break;

У меня вопрос. Где в документации написано, что ордера отсортированы по дате? Почему все-таки нет смысла перебирать все ордера?


Список ордеров не сортирован, но формируется по дате. Это естественный порядок и очень мало вероятно, что его будут ломать.
 
Aleksei Radchenko:

Список ордеров не сортирован, но формируется по дате. Это естественный порядок и очень мало вероятно, что его будут ломать.

Уже были такие разговоры. Лет эдак много назад. Тоже люди закладывались на сортировку по умолчанию. Потом в спешке переделывали свои советники когда вдруг зависимость появилась от сортировки в терминале. А потом опять зависимость от сортировки перестала быть ...а потом опять ...

В общем, люди пишут про поиск ордера по времени не просто так, а потому, что выстрадано - один раз написать, и больше ни от кого не зависеть, и не полагаться на авось.

 
Я тоже так думаю. Что внутри может поменяться трудно предугадать, поэтому надо ориентироваться на "кота в мешке".  Впрочем код открыт, каждый может переписать его под себя или не пользоваться вовсе.
Поправил код насчет "грязного" Select. Действительно, в случае какой-либо ошибки вернется не совсем последний ордер. Теперь при ошибке OrderSelect() поиск прерывается и возвращается тикет -1.
Причина обращения: