Тестер, поддерживающий МГ4-скрипты и советников - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я этого не говорил.
Вообще не касался этой темы и не планирую участвовать.
Видимо, мне показалось:
А вот интегрированные стоплоссы и тейкпрофиты на самом деле являются виртуальными и выбрасываются на исполнение по маркету, когда придет время. У такого решения есть хорошая сторона - она экономит на ГО (гарантийном обеспечении, марже).
Задумайтесь над тем, что дают новые функции доступа к данным и почему так сделано.
В MetaTrader 4 лимитированная глубина истории, отдельные таймфремы и прямой доступ к барам своего символа через Open/High/Low/Close/Time[xxx]. Такой прямой доступ очень дорог в реализации с точки зрения ресурсов и затрат CPU. Задумайтесь о том, что каждый эксперт имеет свою локальную копию этих данных, чтобы не конфликтовать с другими экспертами и самим терминалом.
При росте количества символов (например, в МТ5 можно иметь 5 000-10 000 инструментов) и использовании глубокой минутной истории как основы всех таймфреймов, уже в принципе невозможно использовать методы работы MT4. Банально не хватит оперативной памяти, да еще копирование больших кусков убивает производительность. Поэтому в МТ5 уже нет автоматического ведения скрытой и дорогой копии чарта для каждого экперта.
Вместо этого мы перешли на очень экономные CopyXXX функции, где разработчик точно запрашивает в локальный массив столько данных, сколько ему нужно, а не весь доступный график. Дальше идет максимально быстрая работа с локальными данными (вместо старого достаточно дорого Open/High/Low/Close/Time[xxx]), плюс автор может кешировать эти данные и экономно использовать их при следующем вызове. Экономия по памяти и CPU получается огромная. Кроме того, у самой платформы развязываются руки по управлению огромными базами - доступ к ним всегда по запросу(вместо неконтролируемого прямого) и это позволяет гибко управлять кешами.
Еще важно отметить, что простота обращения Open/High/Low/Close/Time[xxx] в MQL4 касалась только текущего символа и таймфрейма, а все остальные данные других символов и таймфреймов доставались через iClose/iLow(...) функции, что давало серьезнейшие тормоза. Переход в MQL5 на единую модель CopyXXX функций в корне улучшил ситуацию, дав возможность разработчикам одним запросом получать нужные куски данных и не делать многократные блокируемые вызовы (задумайтесь о блокировках в каждом одиночном вызове iClose).
...
Как насчет производительности CopyXXX?
В плане экономии памяти - вопросов нет. Но вызывать на каждом тике CopyXXX куда накладнее чем один раз скопировать в буфер массив котировок и обращаться к нему по прямому индексу типа Rates[X]. Получается классическая дилемма программирования: "Экономия памяти vs. Экономия времени ЦП".
Не меньше, чем MT5. А теперь адресуйте этот же вопрос себе, только четверку на пятерку замените.
Идите изучать, что такое РЫНОК! Трейдер, понимаешь ли...
Т.е. Вы утверждаете что МТ4 скажем может хранить историю спреда или "знат" про реальные объемы (без всяких там костылей и остальных совсем уж не адекватные решений)?
Вы согласны с тем что на реальном рынке спред явно не фиксирован? Пойдите и в тестере МТ4 попробуйте протестировать советник на котировках с изменяющимся спредом, потом поговорим.
Весь мир меня волнует не так сильно,как интересы заказчиков на разработку экспертов со сложной логикой. ;)
Компромиссным решением была бы организация виртуальных ордеров на уровне MT5. Тогда был бы и нужный кому то неттинг, и старая логика работы с ордерами.
Риски такой "визуализации" Вы на себя возьмете?
в МТ5 все кто хотел давно используют решение за счет хеджирования при помощи сделок на разных инструментах с высокой степенью корреляции.
Да, это маржи может потребовать гораздо больше чем в МТ4, но с точки зрения здравого смысла это правильно.
Конечно, никто не отменял "виртуальную" схему при этом.
Т.е. Вы утверждаете что МТ4 скажем может хранить историю спреда или "знат" про реальные объемы (без всяких там костылей и остальных совсем уж не адекватные решений)?
Вы согласны с тем что на реальном рынке спред явно не фиксирован? Пойдите и в тестере МТ4 попробуйте протестировать советник на котировках с изменяющимся спредом, потом поговорим.
Риски такой "визуализации" Вы на себя возьмете?
в МТ5 все кто хотел давно используют решение за счет хеджирования при помощи сделок на разных инструментах с высокой степенью корреляции.
Слава Богу, есть пока МТ4. :) В нем хочешь - на одном инструменте. Хочешь - на разных.
В чем же вы видите риски?
Как насчет производительности CopyXXX?
В плане экономии памяти - вопросов нет. Но вызывать на каждом тике CopyXXX куда накладнее чем один раз скопировать в буфер массив котировок и обращаться к нему по прямому индексу типа Rates[X]. Получается классическая дилемма программирования: "Экономия памяти vs. Экономия времени ЦП".
У CopyXXX такая же скорость как и у iClose/iOpen/iXXXX функций. Только iXXX возвращает по одному элементу, а CopyXXX - множество и тем самым более эффективная и производительная.
Вероятно, вы не учитываете, что в МТ4 работает принудительное копирование _всей_ истории локального чарта в локальное(кеш) рыночное окружение эксперта перед каждым запуском обработчика тиков. А это очень дорого, хотя у нас есть метод экономного обновления этой информации. Специальная функция RefreshRates из MQL4 как раз и вызывает принудительное обновление кешей и истории локального чарта.
Вызывать CopyXXX гораздо эффективнее, причем у разработчиков появляется очень точный и аккуратный механизм кеширования ранее запрошенных данных. Например, не надо перезапрашивать глубокую историю на каждом тике, а хранить/дописывать ее локально и получать к ней максимально быстрый доступ.
Если сравнивать старые методы "прямого" (на самом деле там не прямой доступ) доступа Open/High/Low/Close и работу с локальным массивом double local[xxxx], то последний в разы быстрее. Поэтому лучше копировать к себе локально, а потом иметь быстрый локальный доступ к многократно запрашиваемым данным.
Слава Богу, есть пока МТ4. :) В нем хочешь - на одном инструменте. Хочешь - на разных.
В чем же вы видите риски?
При разработке/использования "торговых платформ" существуют определенные расходы и риски, которые в конечном счете кто-то берет на себя.
Что касается "виртуализации" в ПО от других разработчиков
Дело это хорошее, если все используется для себя и люди внедряющие решение понимают что делают.
Основными расходами будут: средства затраченные на разработку системы, средства затраченные на поддержку работоспособности системы и время затраченное на реализацию проекта.
Основные риски: на реализацию работоспособного проекта будет затрачено слишком много времени или средств (проект не окупится), проект будет не эффективен по сравнению с другими решениями, при реализации проекта будут допущены скрытые ошибки в коде или алгоритмах.
Да, банки и прочие игроки рынка прибегают к разработке своего ПО с необходимым функционалом, но, при этом они тратят огромное количество времени и ресурсов. При этом они абсолютно все риски берут на себя.
Что касается работы в МТ5 (различные варианты с применением МТ5)
Тут конечно MQ сделали большую часть всей работы, но и ввели определенные ограничения по функционалу.
Основными расходами будут: средства затраченные на поддержку работоспособности системы и время затраченное на реализацию проекта.
Основные риски: проект будет не эффективен по сравнению с другими решениями, при реализации проекта будут допущены скрытые ошибки в коде или алгоритмах, придется постоянно следить за работоспособностью всей системы (защищать ее от проблем с программным и аппаратным обеспечением; следить за качеством связи, электропитанием, безопасностью данных и т.д.).
Тут конечно можно подумать о коммерческом применении (предоставлении возможности использования другим людям), с определенными ограничениями и оговорками.Хотелось бы взглянуть
Здесь пример, где особенно видна простота и удобство использования ООП при написании простеньких программ.