Ошибки, баги, вопросы - страница 2822
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Только округление не через штатные round(), ceil(), floor() т.к. они тоже возвращают double.
А через эти, тем более они работают быстрее штатных:
Может и быстрее, да только неправильнее.
Вы то сами пробовали?
Попробуйте:
Выход:
должно быть 12346, т.к. это ceil ("Возвращает ближайшее сверху целое числовое значение.")в первом случае получается 12345, т.к. значимых цифр в типе double 17, а у вас 18
Действительно, нельзя сравнивать double. Просто жёсткое правило.
Конечно, можно и иногда даже нужно сравнивать double напрямую между собой.
Например, при Оптимизации OnTick вызывается иногда триллион раз. Штатный Тестер для того, чтобы понять, исполнять висящий лимитник или нет, делает сравнение текущей соответствующей цены символа и цены лимитника. Делает это для каждой отложки перед каждым OnTick вызовом. Т.е. таких проверок делается десятки и сотни миллиардов раз.
И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую. Т.к. цены и отложенных ордеров и символа предварительно нормализованы. Поэтому могут и должны сравниваться между собой напрямую.
Не на ровном месте MQL-кастомный Тестер уделывает нативный штатный Тестер по производительности.
fxsaber:
Конечно, можно и иногда даже нужно сравнивать double напрямую между собой.
Например, при Оптимизации OnTick вызывается иногда триллион раз. Штатный Тестер для того, чтобы понять, исполнять висящий лимитник или нет, делает сравнение текущей соответствующей цены символа и цены лимитника. Делает это для каждой отложки перед каждым OnTick вызовом. Т.е. таких проверок делается десятки и сотни миллиардов раз.
И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую. Т.к. цены и отложенных ордеров и символа предварительно нормализованы. Поэтому могут и должны сравниваться между собой напрямую.
Не на ровном месте MQL-кастомный Тестер уделывает нативный штатный Тестер по производительности.
NormalizeDouble() очень дорогая функция. Поэтому про нее лучше забыть.
Вот скрипт, который демонстрирует разницу между NormalizeDouble() и нормализацию с помощью int:
результат:
ЗЫ причем нормализация через int получается еще и точнее (это можно увидеть по количеству девяток после последней цифры нормализации - выделено синим.)NormalizeDouble() очень дорогая функция. Поэтому про нее лучше забыть.
Вот скрипт, который демонстрирует разницу между NormalizeDouble() и нормализацию с помощью int:
результат:
ЗЫ причем нормализация через int получается еще и точнее (это можно увидеть по количеству девяток после последней цифры нормализации - выделено синим.)а если суммировать не через double, а через long, тогда результат еще более впечатляет, т.к. суммирование через int (умножение и округление с последующим делением итоговой суммы) вычесляется быстрее обычной суммы double.
результат:
а если суммировать не через double, а через long, тогда результат еще более впечатляет, т.к. суммирование через int (умножение и округление с последующим делением итоговой суммы) вычесляется быстрее обычной суммы double.
результат:
Decimal для сравнения добавьте.
Ошибся ссылкой, там не полная реализация.
И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую.
Откуда вам это известно? Ведь даже если цены не нормализованы, то проверка элементарно делается и без всякой нормализации:
учитывая, что цены кратны ticksize
ЗЫ причем нормализация через int получается еще и точнее (это можно увидеть по количеству девяток после последней цифры нормализации - выделено синим.)
Тест некорректный. Почему вы делите на 100000.0 только один раз в конце? Оно должно выполняться на каждой итерации, и потом суммироваться. Вот тогда это будет честное сравнение. А так у вас никакая не нормализация, а вы просто оптимизировали свой тестовый алгоритм. Естественно так будет и быстрее, и точнее (т.к. уменьшается накопленная ошибка)
Откуда вам это известно?
Потому что можно подать на вход ненормализованные цены Тестеру, и он сработает с ними идентично.
Ведь даже если цены не нормализованы, то проверка элементарно делается и без всякой нормализации
В данном случае под нормализацией имел в виду некий единый стандарт-алгоритм, после применения которого позволяется напрямую сравнивать double этого стандарта.
Так вот Тестер не сравнивает напрямую. А делает это либо через NormalizeDouble, либо через ticksize, либо еще как-то. Но точно не прямым сравнением даблов. И это совсем нерационально.
Конечно, можно и иногда даже нужно сравнивать double напрямую между собой.
Например, при Оптимизации OnTick вызывается иногда триллион раз. Штатный Тестер для того, чтобы понять, исполнять висящий лимитник или нет, делает сравнение текущей соответствующей цены символа и цены лимитника. Делает это для каждой отложки перед каждым OnTick вызовом. Т.е. таких проверок делается десятки и сотни миллиардов раз.
И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую. Т.к. цены и отложенных ордеров и символа предварительно нормализованы. Поэтому могут и должны сравниваться между собой напрямую.
Не на ровном месте MQL-кастомный Тестер уделывает нативный штатный Тестер по производительности.
решил проверить бредовую версию по быстродействию.
И результат удивил.
Сравнение даже предварительно нормализованных double происходит в среднем даже более медленее, чем если double сравнивать через эпсилон или через преобразование в int
Результат:
Не исключаю, что многое зависит от новизны и архитектуры процессора, и у кого-то результат может быть другим.
ЗЫ признаться честно - даже не понимаю, почему так происходит.
Вроде и оптимизировать при сумме случайных чисел компилятору нечего. За скобки округление не вынесешь.
Вроде сравнение double в процессоре - это одна команда
При варианте сравнения через эпсилон(самый быстрый вариант) все равно происходит операция сравнения двух double, но при этом дополнительно происходит вызов функции с передачей трех параметров и одна операция вычитания.
Неужели производительность операции сравнения двух double зависит от значений самых переменных. Сомневаюсь.
Блин, не понимаю. Помогите пожалуйста - чего я не учел или где я ошибся?