Пожалуйста рассудите. - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Для определения экстремумов не надо анализировать тики. Экстремум - это всегда одно из значений High или Low баров. В большинстве случаев, для этого достаточно даже быстрого метода тестирования на основе сформировавшихся баров.
Так еще и время имеет значение
Так еще и время имеет значение
Если время возникновения экстремума важно с точностью до милисекунды, то тестирование бессмысленно, т.к. даже потиковое тестирование не даст верного (как в рынке) времени возникновения экстремума (тики-то генерируются искусственно).
Если достаточно знать время возникновения экстремума примерно (в пределе +- 1 минута), то достаточно использовать быстрый метод на основе сформировавшихся баров. Время возникновения экстремума будет при этом равно времени открытия баров.
Какой величины этот участок?
Вообще в реале до 5 минут, но с учетом того, что тестер МТ не работает с реальными тиками, и внутри минутной свечи он творит всё, что заблагорассудится ( в тестере МТ у меня уже три мегаграаля есть), я тестирую советники, закачивая реальную секундную историю. но тестер секундные свечи считает как минутные, поэтому 5 минут превращаются в 18 тысяч секунд.
хотелось бы услышать мнение сообщества по поводу сложившейся ситуации:
Я вот одного не понимаю - а в чём проблема-то? У вас есть "боевая" и "тестовая" версия одной и той же системы. Задача первой - работа на реале - ошибки, манименеджмент, 100500 разных странных ситуаций и т.п. Задача тестовой версии - быстрая работа и ясность кода (причём, последнее явно важнее!).
Я сам использую такую схему - потому что "боевик" на пару порядков медленнее примерно. :)
В чём проблема-то оптимизировать версию, предназначенную для этого, а торговать "боевиком"? У вас ведь именно две версии в распоряжении, если я правильно понял?
Вообще в реале до 5 минут, но с учетом того, что тестер МТ не работает с реальными тиками, и внутри минутной свечи он творит всё, что заблагорассудится ( в тестере МТ у меня уже три мегаграаля есть), я тестирую советники, закачивая реальную секундную историю. но тестер секундные свечи считает как минутные, поэтому 5 минут превращаются в 18 тысяч секунд.
А Вы в курсе, что МТ4 не предназначен для тестирования на таймфреймах меньше одной минуты? Например, в этом случае категорически нельзя использовать отложенные ордера.
Даже если вам нужно найти экстремум на 18 000 последовательных данных, для этого вовсе необязательно каждую секунду пересчитывать весь массив полностью. Для этого необходимо организовать очередь FIFO (первый вошел - первый вышел). Каждое новое вошедшее значение сравнивается с текущим экстремумом. Если экстремум найден, то он становиться текущим.
З.Ы. Хотя не все так просто. Похоже требуется знать ранг каждого вошедшего тика (его место относительно текущего экстремума), а без манипуляций с динамической памятью здесь не обойтись. Поэтому похоже действительно единственно возможный вариант, доступный в МТ4, перебор всех 18 000 с приходом каждого нового бара. Отсюда и тормоза.
З.Ы.Ы. Да забейте Вы на эти тики. С МТ4 в этом режиме натерпитесь, а выхлоп будет минимальный.
З.Ы.Ы.Ы Хотя в принципе можно организовать эффективный поиск по рангам снижающий количество итераций с 18 000 до 15(!) при этом с приходом нового тика будет переписываться только одно значение массива, а не весь массив целиком (а это тоже очень накладная операция). Но все равно, алгоритм получится не тривиальным хотя и быстрым.
З.Ы.Ы.Ы.Ы В принципе, возможность оптимизации - самое первое о чем должен был подумать разработчик, начав реализовывать этот алгоритм, потому что ежу понятно, что решение в лоб этого ТЗ приведет к диким тормозам, и это скорее всего разработчик понимал уже на этапе ознакомления с ТЗ!
Я вот одного не понимаю - а в чём проблема-то? У вас есть "боевая" и "тестовая" версия одной и той же системы. Задача первой - работа на реале - ошибки, манименеджмент, 100500 разных странных ситуаций и т.п. Задача тестовой версии - быстрая работа и ясность кода (причём, последнее явно важнее!).
Я сам использую такую схему - потому что "боевик" на пару порядков медленнее примерно. :)
В чём проблема-то оптимизировать версию, предназначенную для этого, а торговать "боевиком"? У вас ведь именно две версии в распоряжении, если я правильно понял?
А Вы в курсе, что МТ4 не предназначен для тестирования на таймфреймах меньше одной минуты? Например, в этом случае категорически нельзя использовать отложенные ордера.
Даже если вам нужно найти экстремум на 18 000 последовательных данных, для этого вовсе необязательно каждую секунду пересчитывать весь массив полностью. Для этого необходимо организовать очередь FIFO (первый вошел - первый вышел). Каждое новое вошедшее значение сравнивается с текущим экстремумом. Если экстремум найден, то он становиться текущим.
З.Ы. Хотя не все так просто. Похоже требуется знать ранг каждого вошедшего тика (его место относительно текущего экстремума), а без манипуляций с динамической памятью здесь не обойтись. Поэтому похоже действительно единственно возможный вариант, доступный в МТ4, перебор всех 18 000 с приходом каждого нового бара. Отсюда и тормоза.
З.Ы.Ы. Да забейте Вы на эти тики. С МТ4 в этом режиме натерпитесь, а выхлоп будет минимальный.
Отложенные ордера в сове не используются - это раз.
По поводу реализации - Это здорово, возьму на карандаш, спасибо.
Насчет ЗЫ.Ы - не могу забить. Я придумал уже третий советник, мне его пишут, запускаю в тестере и волосы начинают шевелиться. Я понимаю, что изобрел грааль. со ста баксов за год десять тысяч прибыли, без увеличения лота и с максимальной просадкой в 20 баксов.
Но на практике оказывается что это не грааль, а долбаный тестер мозги морочит. А на реале картинка совсем иная... Вот и вынужден играться с секундной историей. Заказывал переписать сов МТ на джаву, чтобы протестить в терминале дюкаса, но там тестер хоть и идеально точный, но абсолютно хилый. Протестировать большое количество комбинаций на продолжительном промежутке времени не реально в принципе. То есть его можно использовать для прогона по истории, но не для оптимизации.
Поэтому вынужден мучаться с МТ
З.Ы.Ы.Ы.Ы В принципе, возможность оптимизации - самое первое о чем должен был подумать разработчик, начав реализовывать этот алгоритм, потому что ежу понятно, что решение в лоб этого ТЗ приведет к диким тормозам, и это скорее всего разработчик понимал уже на этапе ознакомления с ТЗ!
Вероятно это так и было. Но ему плевать. Ему главное получить предоплату 100%, а потом при каждом удобном случае ещё найти повод снять денег. Насчет качества - это уже не его проблемы. Конвеерный бизнес. Будет ли он особо заморачиваться, если одновременно пишет по несколько сов от нескольких разных заказчиков? Тут уж не до творчества. Лепит абы побыстрее.
Да, кстати. Спасибо Вам за активное участие. Искренне признателен Вам, в отличие от некоторых "корифеев", которые считают, что раз я в ТЗ не указал необходимость возможности полноценной оптимизации, то я "спалился" (С) и типа сам дурак, а кодер - красавчик.
Вероятно это так и было. Но ему плевать. Ему главное получить предоплату 100%, а потом при каждом удобном случае ещё найти повод снять денег. Насчет качества - это уже не его проблемы. Конвеерный бизнес. Будет ли он особо заморачиваться, если одновременно пишет по несколько сов от нескольких разных заказчиков? Тут уж не до творчества. Лепит абы побыстрее.
Да, кстати. Спасибо Вам за активное участие. Искренне признателен Вам, в отличие от некоторых "корифеев", которые считают, что раз я в ТЗ не указал необходимость возможности полноценной оптимизации, то я "спалился" (С) и типа сам дурак, а кодер - красавчик.
Насчет ТЗ просто ситуация не однозначная. Если задача высокопроизводительной оптимизации программисту первоначально не ставилась, а задание не содержит высокоресурсных вычислений, и задание было выполненно им, но скорость работы не надлежащая, то скорее здесь прав программист. Однако в Вашем случае ситуация несколько иная. Вы дали задание, ресурсоемкость которого не оценили. Т.к. вы не программист, а заказчик, то определять ресурсоемкость Вы и не обязаны. Программист, ознакомившись с ТЗ, должен был понять, что это очень ресурсоемкое ТЗ и как минимум предупредить Вас об этом до начала выполнения работ. Он этого, на сколько я понимаю, не сделал, и тем самым ввел Вас в заблуждение. То что вы неявно подразумевали (высокая производительность), оказалось невыполненной. Виноват в этом случае программист, который не предупредил Вас о том, что заведомо знал о проблемах с оптимизацией.