Мт4 Конец поддержке. - страница 39

[Реter Konow]

George Merts:

Спорно, что это преимущество.

Случайно кто-то будет изменять флаг - и это повлияет на поведение ТС.

Ну, от случайностей никак не застраховаться. Человеческий фактор неискореним.))

[Nikolai Semko]

Реter Konow:

Моя исходная задача: Показать эффективные решения без использования ООП.

Суть моего решения: - формирование глобального массива флагов событий новых баров всех символов и таймфреймов один раз в минуту.

Преимущества:

1. Автоматическое заполнение массива и автоматическое очищение.

2. Отсутствие нагрузки на систему.

3. Прямой доступ к массиву из любой функции и сохранение флага события до очищения массива.

Блин,  проснулся окончательно....

Ты понимаешь,  что бар любого символа может прийти в любое мгновение и задача состоит как как в том,  чтоб сообщить системе в это же самое мгновение,  что пришёл новый бар. Как ты себе это представляешь,  когда систему будешь опрашивать  раз в минуту?

[Georgiy Merts]

Реter Konow:
Ну, от случайностей никак не застраховаться. Человеческий фактор неискореним.))

Ну вот же. Поэтому, я считаю, что код надо писать так, чтобы он как можно сильнее ограничивал возможные ошибки человека. Как раз потому, что человеческий фактор - неискорением. Не далее, как вчера обнаружил ошибку в своем коде, из-за которой статистика по эксперту собиралась не с указанной даты (даты создания эксперта), а с начала истории. Просто забыл инициализировать переменую, и она осталась нулем.

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

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

[Georgiy Merts]

Nikolai Semko:
Блин,  проснулся окончательно....

Ты понимаешь,  что бар любого символа может прийти в любое мгновение и задача состоит как как в том,  чтоб сообщить системе в это же самое мгновение,  что пришёл новый бар. Как ты себе это представляешь,  когда систему будешь опрашивать  раз в минуту?

Зачем "в это самое мгновение" ???

У вас, друзья, просто разные подходы к совершению сделок. Если мы работаем на таймфрейме М1 - информацию, что пришел новый бар - мы должны получить не " в тоже самое мгновение", а при приходе новой минуты.  Если мы работаем на таймфрейме S1 (привет, Волчанский) - эту информацию мы должны получить при приходе новой секунды. Если мы работаем на каждом тике - информация должна прийти с приходом нового тика.

И есть вариант "работа по событию" - но тогда у нас должна быть не функция IsNewBar(), а функция OnNewBar(), которая, фактически является "подмножеством" функции OnTick()

[Реter Konow]

Nikolai Semko:
Блин,  проснулся окончательно....

Ты понимаешь,  что бар любого символа может прийти в любое мгновение и задача состоит как как в том,  чтоб сообщить системе в это же самое мгновение,  что пришёл новый бар. Как ты себе это представляешь,  когда систему будешь опрашивать  раз в минуту?

Функция iBars() всегда вернет текущее количество баров. Если оно изменилось с момента последнего обращения, - зафиксируем событие нового бара в массиве, если не изменилось - не зафиксируем.

[Реter Konow]

Nikolai Semko:
Блин,  проснулся окончательно....

Ты понимаешь,  что бар любого символа может прийти в любое мгновение и задача состоит как как в том,  чтоб сообщить системе в это же самое мгновение,  что пришёл новый бар. Как ты себе это представляешь,  когда систему будешь опрашивать  раз в минуту?

Ясно. То есть бар может и не придти в момент запроса iBars, а придти через мгновение после запроса. Тогда для системы он будет пропущен. Это по делу.

Тогда что, обращатся непрерывно? - явно не лучшее решение.

[Alexey Viktorov]

Реter Konow:

Ясно. То есть бар может и не придти в момент опроса, а придти через мгновение после опроса. Тогда для системы он будет пропущен. Это по делу.

Peter, предлагаю другую тему для обсуждения, второй раз. Писать ничего не надо, исключительно теория.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Мт4 Конец поддержке.

Alexey Viktorov, 2017.09.11 13:08

Мне кажется я нашёл примитивный пример удобства использования ООП. Вот функция заполнения массива указанным значением. Там их восемь разновидностей в зависимости от типа массива.

Вот представьте что вам надо написать функцию в которую надо передавать то один набор параметров, то другой, то третий... При алгоритмическом подходе получится N разных имён функций. Казалось-бы ничего страшного, можно ведь написать и 8 таких как ArrayInitializeInt() ArrayInitializeDouble() и так далее. Но ведь как приятно не задумываясь о типе массива просто применять одну функцию в любом случае и на сколько безопасно перепутать какой массив туда суёшь...

[Реter Konow]

Alexey Viktorov:

Peter, предлагаю другую тему для обсуждения, второй раз. Писать ничего не надо, исключительно теория.

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

[Alexey Viktorov]

Реter Konow:
Подождите чуточку пожалуйста. Мы полностью разберемся в этой теме и я внимательно ознакомлюсь со второй.

Как вы помните тема нового бара была поднята с целью выяснить плюсик ООП, но никак не варианты программирования и тем более не ваши способности. Но замечания к вашему коду и алгоритму в целом свернули дискуссию не в ту степь. Так-что думаю продолжать её нет необходимости.

[Реter Konow]

Alexey Viktorov:

Как вы помните тема нового бара была поднята с целью выяснить плюсик ООП, но никак не варианты программирования и тем более не ваши способности. Но замечания к вашему коду и алгоритму в целом свернули дискуссию не в ту степь. Так-что думаю продолжать её нет необходимости.

То есть, Вы хотите чтобы я продолжал в пух и прах разносить преимущества ООП, а меня все продолжали троллить?)) Но по сути Вы правы. Дискуссия пошла не в ту степь.