Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мне понравилось переписывать компрессор в качестве умственного упражнения, чтобы узнать что-то новое о различных доступных алгоритмах сжатия данных временных рядов.
Можно ускорить декомпрессию, если избавиться от 70% NormalizeDouble. Причине такой возможности в этом.
На dBid выделять 5 битов + 1 бит, как флаг, нужно ли делать нормализацию или нет. Такой подход минимально ухудшит компрессию (максимальная дельта станет в два раза ниже), но, возможно, даст 10-20% дополнительной производительности.
Also I see in the profiler that the two calls to NormalizeDouble() are alone consuming about 15% of the total running time .
Такой подход минимально ухудшит компрессию (максимальная дельта станет в два раза ниже), но, возможно, даст 10-20% дополнительной производительности.
Реализовал.
Было.
Стало.
Добавить макрос.
#define TICKS_SHORT_ALTERNATIVEСравнение в мат. режиме.
Implemented.
MOD1: Deacrease calls to NormalizeDouble
Calls to NormalizeDouble can be effectively decreased to the minimum possible (even less than you updated version) if you switch to +ve powers of 10, I mean MathPow(10, digits) like 10, 100, 1000 instead of -ve powers, 0.1, 0.01, etc. The round-off error will be less when you divide N/1000 than N*0.001
static const double Power10[] = {1, 1e1, 1e2, 1e3, 1e4, 1e5, 1e6, 1e7};MOD2: Totally Abandoning NormalizeDouble
if you wish to keep your calculations using the -ve powers of 10 as is:
I suggest using this NEW function (very fast) to replace NormalizeDouble for the prices that are not normalized correctly due to -ve powers of 10.
Both Mod1 and Mod2 are faster than you last update.
MOD1: Уменьшить количество вызовов NormalizeDouble
Количество вызовов NormalizeDouble можно эффективно сократить до минимума (даже меньше, чем в вашей обновленной версии), если переключиться на положительные степени числа 10 , я имею в виду MathPow(10, цифры), например, 10, 100, 1000 вместо отрицательных степеней, 0,1, 0,01 и т. д. Ошибка округления будет меньше при делении N/1000, чем N*0,001.
Я изменил этот код на такой
И получил в OnTester результат > 96%! Спасибо, что показали эту особенность.
MOD2: Полный отказ от NormalizeDouble
если вы хотите сохранить свои вычисления с использованием отрицательных степеней числа 10 как есть:
Я предлагаю использовать эту НОВУЮ функцию (очень быструю) для замены NormalizeDouble для цен, которые не нормализованы правильно из-за отрицательных степеней числа 10.
К сожалению, Ваша функция не всегда правильно срабатывает.
Я изменил этот код на такой
И получил в OnTester результат > 96%! Спасибо, что показали эту особенность.
Сделал такое сравнение.
Деление на положительную степень дает гораздо больше нормализованных значений, чем умножение на отрицательную степень. Еще раз спасибо!
Mod1 и Mod2 работают быстрее, чем в последнем обновлении.
Я написал свой вариант Mod1 и попробовал Ваш вариант.
К сожалению, каждый из них оказался по какой-то причине медленнее на моей машине, чем выложенный в кодобазу.
Видимо, операция деления значительно дороже операции умножения.
К сожалению, Ваша функция не всегда правильно срабатывает.
Для Digits <= 5 проблема только у этих чисел.
Совсем не возникает проблемы, если делать такой вызов.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотеки: TicksShort
fxsaber, 2025.07.24 05:26
Но в как определиться точно с одним из этих двух условий - не соображу.