Особенности языка mql5, тонкости и приёмы работы - страница 301
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
BTW, вот более точный способ сравнить двойные числа a и b (т.е. вычисленные значения, а не константы) на равенство:
Так как это сравнение может изящно обрабатывать очень большие или очень маленькие числа.
Нормализуется ли d1 или d2?
В функции NormalizeDouble() была обнаружена небольшая ошибка, о которой я сообщал ранее, когда на выходе функции часто появляются небольшие ошибки округления (= 1 ULP; единица на последнем месте).
Если вам нужно "очень" точное округление до наименьшего значащего бита (ULP), пожалуйста, используйте мою библиотечную функцию Round(num, digits) из"math_utils.mqh".
Редактировать:
"Точная" функция Round может быть реализована как:
math_utils.mqh содержит довольно оптимизированную версию Round() для скорости.
BTW, в старых версиях MT5 функция Print() имела ошибки при печати двойных значений, поэтому было очень сложно определить, где именно происходят ошибки округления fp.
Теперь предполагается, что функция Print() корректна в MT5 (я не тестировал Print() на MT4).
Edit2:
Еще одна проблема в вашем коде - это точное сравнение дублей (вычисленных значений).
Вы должны использовать свободное (более толерантное) сравнение с использованием абсолютной разницы , как и раньше
Если вам нужно "очень" точное округление до наименьшего значащего бита (ULP), пожалуйста, используйте мою библиотечную функцию Round(num, digits) из"math_utils.mqh".
Мне нужна быстрая распаковка сжатого MqlTick. Этот вариант, к сожалению, медленный.
Мне нужна быстрая распаковка сжатого MqlTick. Этот вариант, к сожалению, медленный.
Смотрите мой пример здесь https://www.mql5.com/en/forum/349798/page2#comment_27766871.
fxsaber #:
MqlTick
Очень неразумно для упаковки данных создавать структуру T, когда каждому неупакованному элементу массива MqlTick будет соответствовать один упакованный элемент массива структуры T.
Упакованные данные - это для максимальной плотности и производительности должен быть набор нескольких массивов данных(причем в идеале битовых) и набор нескольких индексных массивов (тоже битовых). Упаковка, как и распаковка - это непрерывный последовательный рекуррентный процесс от нулевого до последнего индекса.
По идее в среднем на одну 60 байтную структуру MqlTick 4 байтов будет достаточно. Т.е. упаковка в 15 раз. Это подтверждается размером файлов tkc. И похоже это предел.
Очень странно почему данные M1 MqlRates (файлы hcc) до сих пор не упакованы!!! Сомневаюсь, чтобы загрузка и распаковка упакованного файла с диска SSD была бы дольше, чем загрузка неупакованного файла, размер которого скажем в 5-6 раз больше упакованного.
каждому неупакованному элементу массива MqlTick будет соответствовать один упакованный элемент массива структуры T.
Т.е. упаковывать можно разом не один MqlTick-элемент массива, а сразу несколько.
Т.е. в общем виде такое условие.
Но при такой нелаконичной исходной формулировке сразу отпадают люди из-за долгого понимания.
Мне нужна быстрая распаковка сжатого MqlTick. Этот вариант, к сожалению, медленный.
Попробуйте округлить до 5 цифр вместо 8, чтобы избежать крошечных ошибок округления:
Попробуйте округлить до 5 цифр вместо 8, чтобы избежать крошечных ошибок округления:
Да, в том контексте цифра имеет значение.