Умная логика обработки информации MQL

 

Я пишу ТЗ для советника на MT4 с приоритетом на ускоренную обработку данных.

Прошу Вас подсказать, имеет ли значение для ускорение работы последовательность выполнения расчета или  выборочное (как правильно называется - репрезентативное?).

Прикладываю два варианта в виде картинок, на которых отображены блок схемы (примитивно).

Если можно, то напишите как должен выглядеть код, если выборочное исполнение блоков будет происходить - чисто примитивный макет, и даст ли это существенный прирост скорости если одно из промежуточных условий будет верно!?

Файлы:
Logic_V_01.png  26 kb
Logic_V_02.png  30 kb
 
Меньше блоков, быстрее будет обработка инфы
 

GriFFon4ik:
Меньше блоков, быстрее будет обработка инфы 

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

 
-Aleks-:

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

Думаю, по скорости оба варианта будут одинаковы и осуществимы на языке MQL5.

Вопрос в стиле программирования. Кому как удобнее делать структуру. 

 

Я так понимаю, во втором варианте проверки расположены в порядке приоритета.

При срабатывании текущей - в следующие не заходим.

 

А в первом варианте у каждой проверки можно встроить проверку флага результата предыдущей проверки.

И в случае срабатывания какой-либо текущей - все остальные проходим "насквозь" не "проверяя". 

 
-Aleks-:

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

Такие возможности есть у языка MQL5, особенно при использовании ООП.

Конечно стоит! 

 

Как по мне -- так я бы вообще Ваши блок-схемы не принял бы во внимание -- "мартышкин труд".

Любой программист, для которого Вы пишете своё ТЗ -- будет писать код так как умеет и так как понимает -- 100% не вникая и не учитывая Ваши блок схемы.

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

 
Fleder:

Такие возможности есть у языка MQL5, особенно при использовании ООП.

Конечно стоит! 

Спасибо за ответ! Значит, все ж таки блоки, которые должны быть по ТЗ пропущены - будут пропущены и на их расчет не понадобиться время!? Это было бы отлично! Если писаться программа будет не на MQL5 а на MQL4 это что-то изменит!?

 
abolk:

Как по мне -- так я бы вообще Ваши блок-схемы не принял бы во внимание -- "мартышкин труд".

Любой программист, для которого Вы пишете своё ТЗ -- будет писать код так как умеет и так как понимает -- 100% не вникая и не учитывая Ваши блок схемы.

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

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

 
-Aleks-:

Спасибо за ответ! Значит, все ж таки блоки, которые должны быть по ТЗ пропущены - будут пропущены и на их расчет не понадобиться время!? Это было бы отлично! Если писаться программа будет не на MQL5 а на MQL4 это что-то изменит!?

Недавний глобальный апгрейд языка MQL4 сделал его почти идентичным языку MQL5 (за исключением некоторых моментов).

С другой стороны, как уже было сказано выше, у КАЖДОГО программиста своё "видение" структуры исходного кода.

Как показывает горькая практика, очень часто заказчик и программист не могут понять друг друга даже

на уровне корректного объяснения ТЗ.

Можно сделать вывод, что поиск программиста, "видение" структуры которого совпадёт с вашим - задача не из лёгких!

И работать с ним придётся очень "тесно",  а программистам не нравится, когда им пытаются  указывать, как "прогить".

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

И - не поскупитесь! 

 
Fleder:

Недавний глобальный апгрейд языка MQL4 сделал его почти идентичным языку MQL5 (за исключением некоторых моментов).

С другой стороны, как уже было сказано выше, у КАЖДОГО программиста своё "видение" структуры исходного кода.

Как показывает горькая практика, очень часто заказчик и программист не могут понять друг друга даже

на уровне корректного объяснения ТЗ.

Можно сделать вывод, что поиск программиста, "видение" структуры которого совпадёт с вашим - задача не из лёгких!

И работать с ним придётся очень "тесно",  а программистам не нравится, когда им пытаются  указывать, как "прогить".

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

И - не поскупитесь! 

Вы совершенно правы, самое сложное в работе это найти общий язык, на котором тебя будут понимать, поэтому мне и казалось, что наличие визуальной логики приблизит к лучшему пониманию.
А вопрос последовательного или выборочного исполнения кода программы нужно явно указать в ТЗ, но и проконтролировать это мне как то надо.
Дело в том, что я в советнике использую ряд фильтров, в том числе и на основе внешних пользовательских индикаторов, которые существенно замедляют работу, и если есть возможность прекратить проверку актуальности данных, если они уже отфильтрованы предшествующим фильтром, то я бы хотел этим пользоваться.
Что же касается скупости, то советник я пишу долго, вношу изменения, и готов платить за доработки, которые при соблюдении моей логики будут менее трудозатратны и быстры по исполнению. Поэтому доход от работы со мной будет стабильный, хоть и не большой...
Причина обращения: