Ошибки, баги, вопросы - страница 524
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
К тому же закрытие по стоплоссу, насколько я понял, относит сделку к убыточной в результирующем отчете тестера (там где процент убыточных и прибыльных сделок)
После обновления до Build 507 у меня в тестере возникает две проблемы:
1. Во время оптимизации при переключении вкладок тестера терминал периодически(не всегда) вылетает;
2. Если в качестве оптимизируемого параметра было выбранно перечисление, то при попытке запустить один из результатов оптимизации эксперт не видет значение этого перечисления, т.е. оно всегда равно нулю.
После обновления до Build 507 у меня в тестере возникает две проблемы:
1. Во время оптимизации при переключении вкладок тестера терминал периодически(не всегда) вылетает;
2. Если в качестве оптимизируемого параметра было выбранно перечисление, то при попытке запустить один из результатов оптимизации эксперт не видет значение этого перечисления, т.е. оно всегда равно нулю.
Пожалуйста, напишите в сервисдеск с максимальными подробностями.
Мы знаем, что есть проблема с перечислениями при оптимизации, но никак не можем воспроизвести ошибку
В сервисдеск написал...
Я принял Вашу заявку и задал уточняющие вопросы
...И тут возникает вопрос (риторический?)...
Есть многократно повторяющиеся дополнительные расчёты в индикаторе одних и тех же величин, дающих, разумеется, одни и те же результаты. Решение вроде бы очевидное: рассчитать единожды (при первом обращении к историческим данным), затолкать всё в буфер, а в остальных случаях спокойно обращаться к готовым результатам. Но...
В индикаторе заведено и без того немыслимое количество буферов (не менее 10 для хранения рассчитанных данных всей истории на нескольких разных таймфреймах) - к ним и так уже происходит обращение за соответствующими первично рассчитанными данными. Теперь, по идее и как вариант, появилась необходимость удвоить количество буферов.
Конечно, всё упирается в технические параметры железа: вычислительная мощность процессора и объём оперативной памяти. И тут - кто кого победит. Но примем железо за весьма среднее - не самый свежий домашний ПК. И того, и этого не слишком много и не слишком мало. Навскидку предпочесть затруднительно: то ли разбрасываться памятью, то ли вычислительной мощностью.
Поэтому вопрос к осведомлённой публике: что порекомендуете? Может, всё же появятся аргументы "за" тот или иной вариант... Либо не захламлять память удвоением расчётных индикаторных буферов, а греть процессор, на ходу обсчитывая одно и то же всякий раз при очередной необходимости, либо наоборот?
Спасибо.
...И тут возникает вопрос (риторический?)...
...Конечно, всё упирается в технические параметры железа: вычислительная мощность процессора и объём оперативной памяти. И тут - кто кого победит. Но примем железо за весьма среднее - не самый свежий домашний ПК. И того, и этого не слишком много и не слишком мало. Навскидку предпочесть затруднительно: то ли разбрасываться памятью, то ли вычислительной мощностью.
...
...И тут возникает вопрос (риторический?)...
Есть многократно повторяющиеся дополнительные расчёты в индикаторе одних и тех же величин, дающих, разумеется, одни и те же результаты. Решение вроде бы очевидное: рассчитать единожды (при первом обращении к историческим данным), затолкать всё в буфер, а в остальных случаях спокойно обращаться к готовым результатам. Но...
В индикаторе заведено и без того немыслимое количество буферов (не менее 10 для хранения рассчитанных данных всей истории на нескольких разных таймфреймах) - к ним и так уже происходит обращение за соответствующими первично рассчитанными данными. Теперь, по идее и как вариант, появилась необходимость удвоить количество буферов.
Конечно, всё упирается в технические параметры железа: вычислительная мощность процессора и объём оперативной памяти. И тут - кто кого победит. Но примем железо за весьма среднее - не самый свежий домашний ПК. И того, и этого не слишком много и не слишком мало. Навскидку предпочесть затруднительно: то ли разбрасываться памятью, то ли вычислительной мощностью.
Поэтому вопрос к осведомлённой публике: что порекомендуете? Может, всё же появятся аргументы "за" тот или иной вариант... Либо не захламлять память удвоением расчётных индикаторных буферов, а греть процессор, на ходу обсчитывая одно и то же всякий раз при очередной необходимости, либо наоборот?
Спасибо.
Как вариант - почему бы вам не использовать для ваших нужд базы данных? Обсчитали, записали.. пришло время - извлекли в наиболее удобном виде, пользуемся.
Архитектурно решение позволяет отделить расчеты и кэширование результатов.
Как вариант - почему бы вам не использовать для ваших нужд базы данных? Обсчитали, записали.. пришло время - извлекли в наиболее удобном виде, пользуемся.
Архитектурно решение позволяет отделить расчеты и кэширование результатов.
Не отрицаю, но словосочетание "пришло время" звучит забавно, учитывая, что каждое обращение будет воспроизводиться в OnCalculate при каждом тике. Либо БД должна лежать полностью в оперативке, либо придётся медленно доступаться к диску и запиливать его в прах. Хотя... что я понимаю в СУБД...
Впрочем, разве MQL - не язык запросов из БД? Если так, то работа с БД с диска уже осуществляется и диск вроде живой пока. Тут ничего нового придумывать и не надо.
Если же Вы имели в виду какую-то другую БД и специфический (нештатный) способ доступа к ней, тогда прошу пояснить. Если предлагаете интеграцию взаимодействия MQL5 с чем-то ещё, то мне пока рановато этим заниматься, я MLQ-то только начал изучать и движусь в направлении продвинутого кипятильника...
Очень часто происходит разрыв связи с сервером. При этом индикатор показывает стабильную связь:
Обратно терминал не подключается. Приходиться вручную залогиниваться. Можно ли как-то программно это сделать средствами MQL5?