MT4 to MT5 - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
+
-
Полгода уменьшенные в разы т.е. 1-2 месяца под отладчиком - респект профессионалам!
Ну раз пост по сути, отвечу.
Есть разные уровни тестирования, можно сделать режим тестирования на скорость, но можно сделать и на качество.
Если пользователю требуется сделать оптимизация, велкам в быстрый тестер, если же нужна отладка на истории то плевать на скорость, нужен тест на чётко заданном участке, который программер зарание вычленил из вороха котиров (а скорее всего ему заказчик прислал репорт на баг на этом участке), и эти вопросы решаются разными режимами тестера.
Один вопрос оптимизация, другой отладка прог.
Речь не шла о тестировании и оптимизации, а именно об отладке, на основании которой как правило, правят код, а на основании различных исторических данных, как правило правят внешние переменные, если конечно ваш советник написан грамотно.
Полгода уменьшенные в разы т.е. 1-2 месяца под отладчиком - респект профессионалам!
Речь не шла о тестировании и оптимизации, а именно об отладке, на основании которой как правило, правят код, а на основании различных исторических данных, как правило правят внешние переменные, если конечно ваш советник написан грамотно.
Вы не верно истолковываете отладку, видимо не пользовались стандартным отладчиком.
Сейчас 2 часа ночи, сижу отлаживаю прогу, движения котиров никакие, но мне нужно прямо сейчас проверить как прога себя поведёт на пейролах (я точно знаю когда они были, и когда будут в следующий раз).
Вопрос: что ж теперь ждать месяц до выхода пейролов? а если прогавил момент, или не уловил суть бага? как отмотать и проверить снова? что снова месяц ждать? или нужно вставить отображение дополнительной переменной?
ведь по закону подлости, хорошая мысля приходит опосля.
ЗЫ отладка на истории закрывает все эти неразрешимые (в данной реализации) ситуации.
revers45:
Сегодня вам "жутко" не хватает отладки на длительных прогонах исторических данных, а завтра будет не хватать ее, еще и на множестве проходов оптимизации...
Но зачем эти малопродуктивные затраты времени на бесконечные повторные прогоны, ведь отладка предназначена в основном для поиска логических ошибок в коде, а для проверки его на многообразии данных, существуют совсем другие методы, например модульное тестирование.
Нет. Погодите.
Во-первых, действительно, если будет возможность отладки на исторических данных - никаких проблем не будет запустить отладку на множестве (хотя, зачем ?) проходов оптимизации. Ведь по сути, проход с историческими данными и выбраными входными параметрами - ничем не отличается от прохода с выбранными данными и очередным набором оптимизируемых параметров.
Во-вторых, вы совершенно правы - отладка нужна ИМЕННО для поиска логических ошибок в НОВОМ коде, а вовсе не для проверки РАБОЧЕГО когда на многообразии данных. И именно поэтому - нужна отладка на исторических данных.
Ситуация тут проста - вы написали модуль, который обрабатывает одну из возможных ситуаций. Теперь необходимо отладить этот код. А для этого - необходимо, чтобы на входе были данные из ситуации, которая будет обрабатываться вашим, только что написанным блоком. Как вы предлагаете это сделать ? Просто прогоняем в тестере - получаем критическую ошибку. И почему - невозможно понять. Что делать ? Именно тут и требуется вызвать функцию OnTick() в тот момент, когда таймсерии имеют ситуацию включения написанного блока - и "пробежаться" в отладчике по коду, чтобы понять, почему возникает такая ошибка.
Сейчас мне приходится пользоваться только трассировочными сообщениями - что гораздо сложнее, чем отладка, ведь все переменные невозможно вывести в печать, приходится много раз запускать тестер стратегий на нужных даных, какждый раз постепенно добавляя трассировочный вывод, "подбираясь" к ошибке.
Любими по любому поводу своё фи вставлять? честно говоря сильно смахивает на тролинг.
Коллега, нет смысла бросаться подобными обвинениями. Лучше постараться донести до человека суть проблемы (даже если он считает, что "знает лучше").
Образно говоря, если перейти на бытовой уровень, на каждый автомобиль вы бы навесили диагностические стенды по трансмиссии, двигателю и.т.д. Не страшно, что они сильно замедлят езду главное уменьшат аварийность и смогут на ходу предсказывать неисправности...)
То есть речь о достаточной полезности и необходимой достаточности.
Ну, собственно, Urain правильно ответил, но я поясню на вашем примере, поскольку сам был когда-то автослесарем, и, иногда мне приходилось делать именно то, что вы и предложили - "навешивать" на автомобиль диагностические приборы, и в таком непотребном (и даже небезопасном) виде проезжаться по испытательному полигону.
Представьте себе - вы едете, и вдруг в моторе появляется громкий зловещий скрежет. Появился, и исчез. Через некоторое время - опять появился и исчез. И так - периодически, все более громкий. Что вы сделаете ? Понятное дело - погоните автомобиль в сервис. Мастер вас спрашивает, что случилось - вы отвечаете, мол, появляется скрежет. Садитесь, едете... А скрежета - и нет ! И вобще все с мотором в порядке. Мастер на вас с удивлением смотрит, подозревая в троллинге.
Что делать ?
У вас нет никаких способов, как только "прогон автомобиля на исторических данных" - то есть создать условия, в которых скрежет появится. И при этом - глядите, что получается - наконец, этот скрежет проявился, мастер был рядом - но это он же не глядел внутрь мотора ! Мастер только убедился, что ИНОГДА в машине возникает нештатная ситуация. И теперь - впереди довольно долгая процедура поиска таких вот, "плавающих" неисправностей - и, заметьте, всегда опять "на исторических данных".
Спорщики, а не че, что данные on-line сильно отличаются от данных off-line. На истории будете проверять что? Принцип генерации тиков в тестере?
В МТ4 нет дебагера, весь дебагинг всегда делал в тестере (с помощью принтов и каментов), в принципе и на МТ5 можно это делать, но ведь есть же штантый дебагер.
Получается ситуация в МТ5 есть штатная фича, на её разработку потрачена туева хуча человекочасов, а она лежит на полке по причине недопилки.
Спорщики, а не че, что данные on-line сильно отличаются от данных off-line. На истории будете проверять что? Принцип генерации тиков в тестере?
Нет. Тут ситуация другая.
Нам ведь не важно, что данные онлайн отличаются от данных оффлайн. Нам важно, чтобы при ОПРЕДЕЛЕННЫХ входных данных блоки советника работали определенным образом. Мы в исторических данных находим именно такие необходимые данные, и "скармливаем" их советнику, анализируя его деятельность. И этот анализ - очень удобно производить в отладчике.
На худой конец, конечно, можно использовать трассировочные сообщения через Print. Но по мере усложнения советника такой метод становится слишком напряжным и трудоемким.
Ну, собственно, Urain правильно ответил, но я поясню на вашем примере, поскольку сам был когда-то автослесарем, и, иногда мне приходилось делать именно то, что вы и предложили - "навешивать" на автомобиль диагностические приборы, и в таком непотребном (и даже небезопасном) виде проезжаться по испытательному полигону.
Представьте себе - вы едете, и вдруг в моторе появляется громкий зловещий скрежет. Появился, и исчез. Через некоторое время - опять появился и исчез. И так - периодически, все более громкий. Что вы сделаете ? Понятное дело - погоните автомобиль в сервис. Мастер вас спрашивает, что случилось - вы отвечаете, мол, появляется скрежет. Садитесь, едете... А скрежета - и нет ! И вобще все с мотором в порядке. Мастер на вас с удивлением смотрит, подозревая в троллинге.
Что делать ?
У вас нет никаких способов, как только "прогон автомобиля на исторических данных" - то есть создать условия, в которых скрежет появится. И при этом - глядите, что получается - наконец, этот скрежет проявился, мастер был рядом - но это он же не глядел внутрь мотора ! Мастер только убедился, что ИНОГДА в машине возникает нештатная ситуация. И теперь - впереди довольно долгая процедура поиска таких вот, "плавающих" неисправностей - и, заметьте, всегда опять "на исторических данных".
Спасибо за подробности, но я ведь сразу написал, что для решения описанных вами задач, проверки кода на различных комбинациях данных, обычно применяются такие методы, как модульное тестирование.
Модульное тестирование в отличие от предлагаемой вами отладки в тестере, на подбираемых исторических данных, может обеспечить не случайный набор данных, а полный перебор возможных их значений и\или комбинаций т.е. это намного более эффективно, причем модульные тесты беспрепятственно можно прогонять в текущей реализации отладчика.
И это широко известная мировая практика, поэтому нам не требуется тут изобретать велосипед или автомобиль, с квадкатными колесами...)))
Спасибо за подробности, но я ведь сразу написал, что для решения описанных вами задач, проверки кода на различных комбинациях данных, обычно применяются такие методы, как модульное тестирование.
Модульное тестирование в отличие от предлагаемой вами отладки в тестере, на подбираемых исторических данных, может обеспечить не случайный набор данных, а полный перебор возможных их значений и\или комбинаций т.е. это намного более эффективно, причем модульные тесты беспрепятственно можно прогонять в текущей реализации отладчика.
И это широко известная мировая практика, поэтому нам не требуется тут изобретать велосипед или автомобиль, с квадкатными колесами...)))
Ух ты, аж глаза открылись :) а мы то бараны 30 000 строк за один день набиваем ни разу F7 не нажимая, а потом удивляется откуда столько багов сразу :)
Большие проекты никак иначе как модульно как раз и не пишутся (естественно с отладкой каждого модуля).
Но даже если вы проверили отдельно колёса, отдельно руль итд, то собрав всё вместе и проехав по ухабистой дороге может вылезть баг, и вот для того чтоб этот баг отловить нужно ещё раз проехать по этому участку.
А в данной реализации дебагера, возможно лишь выгнать машину за ворота, отдать заказчику приговаривая "держи теперь ты маешься".
Модульное тестирование в отличие от предлагаемой вами отладки в тестере, на подбираемых исторических данных, может обеспечить не случайный набор данных, а полный перебор возможных их значений и\или комбинаций т.е. это намного более эффективно, причем модульные тесты беспрепятственно можно прогонять в текущей реализации отладчика.
Оно, конечно, хорошо, когда возможно обеспечить "полный перебор возможных значений". Но, что-то мне подсказывает, что это невозможно для сколь-нибудь серьезного класса.
Кроме того, вот глядите, оттестировали отдельно классы, все работает, сложили вместе - в результате возвращаются ошибки, которых, по идее, быть не может. Что не так ? Как вы это обнаружите без пошагового прохождения кода (или трассировочных сообщений через каждые пару строк) ?
Или вот, относительно недавно я обнаружил баг в классах таймсерий Стандартной библиотеки - в классе-предке переменная в вызове функции объявлена, как int, а в классе потомке - как const int. В результате - компилятор считает эти функции различными, а не перегружаемыми виртуальными. По отдельности эти классы замечательно работают. Но как только я стал вызывать эти функции через указатель (задействовал механизм виртуальных функций) - код стал возвращать странные результаты. Мне понадобилось довольно кропотливое прохождение по коду, пока я заметил, что созданный объект таймсерии вызывает совсем не ту функцию, которую я предполагал. Боюсь, без отладчика - такой баг было бы выловить гораздо сложнее.