Линейное торможение - ошибка программиста или особенность работы MT4? - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Сильно хотца познакомиться кто под ником MetaQuotes запостил эту вещчь, можно в личку отозваться?
Бегло посмотрел код. Сразу на ум пришел отрывок из стихотворения Лермонтова:
Теперь о Вашем вопросе:
-Aleks-:
На стадии доработки стратегии, а особенно тактики приходиться заказывать всевозможные дополнения для проверки идеи, на этой стадии вполне можно терпеть неторопливость советника.
Но меня удивило такое падение скорости в 6 раз по сравнению с основной версией советника. Оптимизация настройки советника необходима как минимум для сборки аналитических данных.
Я правильно понимаю, что чужой код читать невозможно и лучше после утверждения для себя удачной версии советника заказать его ещё раз, но что б писался он с нуля, и только в этом случае можно быть уверенным в высокой скорости и надежности? Лично мне казалось что от части задача компилятора вырезать к примеру дублирующие друг друга операции...
Я не об этом коде, а вообще глобально. Т.е. вы опровергаете это утверждение?Если заказывать программистам которые пишут в стиле "смешались в кучу кони, люди" - то переписывать придется не дважды и не трижды, а вообще постоянно и всегда на 100%, за все увеличивающийся бюджет. Если же заказывать будете у профессионалов, то изменение требований на 20%, 40% даже 80% не потребует переписывание кода не то что полностью, а даже на такой же процент, как процент самих изменений. Но с бюджетом "<50$" забудьте об этом.
Я правильно понял, что надо сделать искусственную задержку при отправке приказов на открытие ордеров, но при этом не ждать подтверждения того, что они открылись?
безусловно, любые ошибки отправки ордера советник должен обрабатывать. В самом простом варианте - выводить сообщение о неудачном открытии ордера. В более продвинутом - принимать решение о дальнейших действиях.
Так мне советник нужен что б меня замещать, тут дальнейшие действия весьма актуальны... но не факт что они будут уже своевременны (к примеру цена уже очень далеко ушла от расчетной точки входа).
не дал отправить. Попросите кодера использовать IsTradeContextBusy для проверки.
Спасибо за совет, но именно об этих нюансах я говорил в соседней ветке. Мне то откуда знать об этом?
если используете 509 билд то там 8 потоков. ситуации с IsTradeContextBusy по идее не должно возникнуть.
Если возникнет, то смотри пункт выше.
вы также можете использовать несколько терминалов.
Тут не понял, разве количество терминалов влияет на прохождение ордера? Т.е. по одному и тому же аккаунту можно запустить несколько терминалов и с каждого послать приказ на открытие ордера, и если половина из них захлебнется, то вторая половина выполнит приказ успешно? Я думал, что ордер должен обработать ДЦ и только после этого принимать следующий...
Бегло посмотрел код. Сразу на ум пришел отрывок из стихотворения Лермонтова:
Теперь о Вашем вопросе:
Если заказывать программистам которые пишут в стиле "смешались в кучу кони, люди" - то переписывать придется не дважды и не трижды, а вообще постоянно и всегда на 100%, за все увеличивающийся бюджет. Если же заказывать будете у профессионалов, то изменение требований на 20%, 40% даже 80% не потребует переписывание кода не то что полностью, а даже на такой же процент, как процент самих изменений. Но с бюджетом "<50$" забудьте об этом.
Сейчас советник мне обходится в более чем 100$ и я знаю, что буду ещё его дописывать. Получается такая математика:
10 ревизий по 30$ дают расход в 300$, в то время как 10 по 50$ - 500. Экономия как бы 200$ - для меня это существенно. Но когда меня все устроит, я смогу заказать советник с нуля(откинув лишнее) и он будет стоить допустим 80$, в итоге такой подход себя оправдывает, особенно когда ведется разработка. Вот только нервишки приходится изнашивать... но тут как повезет.
Неправильно поняли. Ни каких искусственных задержек быть не должно. В МТ5 есть простенькая событийная модель которую и необходимо использовать вместо задержек по sleep()
Спасибо за совет, но именно об этих нюансах я говорил в соседней ветке. Мне то откуда знать об этом?
а не надо в них разбираться и что то искать.
если кто намекнул, как должно быть а ты обнаружил в коде отсутствие такого - молча меняй кодера. А не создавай ветки.
Тут не понял, разве количество терминалов влияет на прохождение ордера? Т.е. по одному и тому же аккаунту можно запустить несколько терминалов и с каждого послать приказ на открытие ордера, и если половина из них захлебнется, то вторая половина выполнит приказ успешно?
сколько терминалов - такая и кратность потоков для отправки. 10 терминалов отправят по 1 приказу - будет 10 ордеров.
Так мне советник нужен что б меня замещать, тут дальнейшие действия весьма актуальны... но не факт что они будут уже своевременны (к примеру цена уже очень далеко ушла от расчетной точки входа).
Сейчас советник мне обходится в более чем 100$ и я знаю, что буду ещё его дописывать. Получается такая математика:10 ревизий по 30$ дают расход в 300$, в то время как 10 по 50$ - 500. Экономия как бы 200$ - для меня это существенно. Но когда меня все устроит, я смогу заказать советник с нуля(откинув лишнее) и он будет стоить допустим 80$, в итоге такой подход себя оправдывает, особенно когда ведется разработка. Вот только нервишки приходится изнашивать... но тут как повезет.
Вот это с вашей стороны неверный подход.
Заказываете код для тестера, предупреждая о важности скорости оптимизации, вносите в него же необходимые доработки. И уже после того, как будет готова тестовая версия, заказываете версию для реала с уже отработанной логикой и всеми доработками/нужностями.
Гораздо больше экономия будет. Нет?
а не надо в них разбираться и что то искать.
если кто намекнул, как должно быть а ты обнаружил в коде отсутствие такого - молча меняй кодера. А не создавай ветки.
сколько терминалов - такая и кратность потоков для отправки. 10 терминалов отправят по 1 приказу - будет 10 ордеров.
А как же ДЦ? Ведь залипание ордера происходит именно у него!? Какой смысл тогда слать кучу ордеров.
Вот это с вашей стороны неверный подход.
Заказываете код для тестера, предупреждая о важности скорости оптимизации, вносите в него же необходимые доработки. И уже после того, как будет готова тестовая версия, заказываете версию для реала с уже отработанной логикой и всеми доработками/нужностями.
Гораздо больше экономия будет. Нет?
Ну, начну с того, что я изначально не предполагал, что скорость тестирования очень сильно зависит от реализации для тестера или реала.
А касаемо остального, так я так и делаю, тестирую, дорабатываю... или вы хотите сказать, что цена в разы будет меньше, если я буду сразу писать "мне не для реала, а тестирования"?
А как же ДЦ? Ведь залипание ордера происходит именно у него!? Какой смысл тогда слать кучу ордеров.
не, ну если скорость заливки всего десятка одномоментно не надо, то я ж не настаиваю.
можно слать по одному из одного терминала, ждать освобождения контекста и так далее.
глядишь за пару минут весь десяток и отправится.
не, ну если скорость заливки всего десятка одномоментно не надо, то я ж не настаиваю.
можно слать по одному из одного терминала, ждать освобождения контекста и так далее.
глядишь за пару минут весь десяток и отправится.
Так я спрашиваю, так как совершенно не знаю, как ордера обрабатываются у ДЦ - параллельно или последовательно?
параллельно или последовательно?
заявки поступают последовательно. но не факт, что Бай исполнится быстрее следующего селл, ибо есть иногда еще провайдер ликвидности.
но для упрощения мировосприятия - думай всегда, что идет последовательно.
только к чему эта информация? от темы не отходи.