Ошибки, баги, вопросы - страница 2160
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
С точки зрения MQ, видимо, правильно. Как всегда, решили за нас, как удобнее.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
В профиле исчезли сообщения.
Renat Fatkhullin, 2018.03.08 10:31
Убрали временно, чтобы уменьшить объем функционала, работающего в режиме совместимости.
Как закончим процесс переноса, добавим новые возможности.
Это новая очень большая и многофункциональная система.
Внедряются новые чаты.
С точки зрения MQ, видимо, правильно. Как всегда, решили за нас, как удобнее.
Переходим на уровень телепат... )))))
Непонятный баг в основном индикаторе. Возникает только на таймфреймах ниже H1, и только в момент запуска терминала. Текст ошибки «S-v5 (EURUSD,M10) array out of range in 'S-v5.mq5' (211,54)». Отрисовка происходит корректно, но в обратном порядке, хотя для всех буферов установлен флаг таймсерии.
Состав шаблона – основной индикатор (№1) (в котором возникает ошибка), дополнительный индикатор (№2) (объединение нескольких хендлов основного индикатора с различными параметрами (период просмотра)), индикатор (№3) выводящий стрелки на основной график по сигналам с индикатора №1), индикатор (№4) выводящий стрелки на основной график по сигналам с индикатора №2.
Переключении таймфрейма, повторное применение шаблона, если убрать любые 2 индикатора с 2 по 4 или только под номером 1, вывод нового символа из обзора рынка и применение данного шаблона – ошибка не воспроизводиться и отрисовка всех индикаторов происходит корректно.
Ошибка при компиляции
Сообщение об ошибке не позволяет понять причину в обширном коде
ниже понятно
Нет сообщения об ошибке
более того - выполняется и даже результат есть (!)
В таком варианте:
не работает переход к строке ошибки (по Enter)
Ошибка при компиляции
В попытке ускорения работы, когда создавал этот пример, совершенно случайно столкнулся с одной странностью, которую просто отложил на полку.
И сейчас, когда я попытался разобраться с этой странностью, запутался еще больше.
Итак, в расчете я использую функцию квадратного корня sqrt(), которую я решил обойти путем создания double массива.
Т.к. я беру квадратный корень всегда с целых чисел, то создание массива выглядит так:
Логично предположить, что считывание из массива SQRT[x] выполняется быстрее, чем функция sqrt(x).
И это подтверждается проверочным кодом:
результат свидетельствует о выигрыше скорости ~ 1.5 раза:
Но когда я заменяю в коде функцию sqrt() на считывание элементов массива SQRT[], вместо ускорения работы, я получаю жуткие тормоза.
Считывание элемента из массиваа SQRT[] происходит в разы, может быть даже на порядок дольше, чем выполнение функции sqrt().
И я не понимаю, где происходит утечка скорости. Ведь вышеуказанный проверочный код говорит об обратном.
Можно предположить, что компилятор каким-то странным образом осуществляет доступ к большому массиву и на каждом витке цикла словно "забывает" о массиве и каждый раз проводит свою какую-то служебную индексацию.
Но тогда это внутренний логический или стратегический баг компилятора. Причем с этим нужно явно что-то делать, т.к. эта утечка скорости очень существенна и ее трудно обнаружить, т.к. она не очевидна.
Прилагаю код скрипта для демонстрации этой странности.
При запуске по умолчанию (arr=false) вычисляются функции sqrt(), а при изменении arr на true значение квадратного корня берется из массива.
ЧТО НЕ ТАК? ОТКУДА ТОРМОЗА?
В попытке ускорения работы, когда создавал этот пример, совершенно случайно столкнулся с одной странностью, которую просто отложил на полку.
Логично предположить, что считывание из массива SQRT[x] выполняется быстрее, чем функция sqrt(x).
Из динамического массива не факт.
Тем более, что взятие корня давно уже в есть на уровне команды процессора SQRTSD. То есть, с помощью заведомых расходов на доступ в динамическом массиве, выиграть у процессорной реализации уже не получится.
И это подтверждается проверочным кодом:
результат свидетельствует о выигрыше скорости ~ 1.5 раза:
Сомневаюсь, что подтверждается.
Код такого вида прям как из учебника по оптимизации циклов. Оптимизатор кода из него просто конфетку может сделать, так как случай очень простой:
То есть, замер производительности в случае применения заведомо идеально оптимизируемых случаев нужно четко соотносить с целями теста.
В данном случае тест неправильный.
И я не понимаю, где происходит утечка скорости. Ведь вышеуказанный проверочный код говорит об обратном.
Не видя финального ассемблерного кода, я склоняюсь к:
Код весь проверим внимательно. Интересно найти, в чем реальная причина.
Из динамического массива не факт.
Не видя финального ассемблерного кода, я склоняюсь к:
Пробовал статический массив - тоже самое.
Как бы sqrt не был бы быстр, но мне сложно поверить в то, что эта функция может быть в 10 раз быть быстрее простого чтения элемента массива.
Причем, если в моем примере уменьшить размер канваса, скажем 50х50 ( для этого существует входной параметр Size, нужно вместо 0 установить 50),
и массив будет значительно меньше (5000 элементов), то скоростная картина заметно меняется. Нет уже такого сильного контраста.
Но мне не понятно, разве от размера массива зависит скорость доступа к его элементам?
А насчет простоты проверочного кода, пожалуй, Вы правы.
Попробовал чуть усложнить и результат совсем другой: