ФорумРазделы

Библиотеки: MathTicker - генератор тиков в математическом режиме - страница 5

Новый комментарий
fxsaber #:
Можно избавиться от большого количества NormalizeDouble.

В коде есть отключение нормализации

#define NormalizeOuts // нормализовать цены и объемы при чтении. Немного увеличит время генерации тиков. совпадает с нормализованными - нет смысла тратить время

   #ifdef NormalizeOuts
      //медленнее в 1,56 раза чем без нормализации. 740 мс против 472
      double ToPrice  (long d){return NormalizeDouble(d * this.point, this.dig);}
      double ToVolume (long d){return NormalizeDouble(d * this.VolumeStep, this.digV);}
   #else
      double ToPrice  (long d){return d * this.point;}//совпадает с нормализованными - нет смысла тратить время
      double ToVolume (long d){return d * this.VolumeStep;}
   #endif
есть иногда отличия в 14-16 знаке после запятой. Думаю нет смысла ее использовать
fxsaber #:
Странно, что такой вариант не дал ускорения.
видимо / и % достаточно быстрые. У меня тоже вначале был большая портянка, потом придумал через /%. Но не из за скорости, а для компатности и чтобы не запутаться в 26 варантах
Forester #:

Думаю нет смысла ее использовать

Есть смысл. Например, гарантия срабатывания TakeProfit при касании может быть только при нормализованной цене.
fxsaber #:

Правильно ли я понимаю, что zip-файл содержит сразу много независимых zip-блоков?

При оптимизации сейчас на каждом проходе идет последовательная zip-распаковка этих блоков.

Имеет смысл всего один раз распаковать в другой файл непосредственно перед оптимизацией в OnTesterInit.

И удалить этот файл в OnTesterDeinit.

fxsaber #:
Можно избавиться от большого количества NormalizeDouble.
Попробовал такую версию
      double ToPrice  (long d){double v=d * this.point; Amount8++; if(v == (d / this.kPoint )){Count8++;return v;}else{return NormalizeDouble(v, this.dig );}}//совпадает с нормализованными - нет смысла тратить время

где

this.kPoint=(double)(long)(1/point_ + 0.1);

дает 59% ==.  Но массивы тиков не равны.

Преобразование в int не делаю, т.к. на вход приходит лонг.

Скорость с этой функцией
2025.11.18 18:01:44.850    1 (EURUSD,H1)    Decompress performance: 2446 MB/s
2025.11.18 18:01:44.850    1 (EURUSD,H1)    Decompress performance: 42.7 Ticks (millions)/sec.
2025.11.18 18:01:44.850    1 (EURUSD,H1)    Decompress performance criterion: 722.4
2025.11.18 18:01:46.550    1 (EURUSD,H1)    Correct = false

А просто с нормализацией
2025.11.18 18:02:47.796    1 (EURUSD,H1)    Decompress performance: 3171 MB/s
2025.11.18 18:02:47.796    1 (EURUSD,H1)    Decompress performance: 55.4 Ticks (millions)/sec.
2025.11.18 18:02:47.796    1 (EURUSD,H1)    Decompress performance criterion: 936.6
2025.11.18 18:02:49.526    1 (EURUSD,H1)    Correct = true

Т.е. нормализация всех тиков быстрее, чем с этими проверками и частичная нормализация.

Думаю нет смысла этот делать, а просто нормализовать все.
Forester #:
Попробовал такую версию

дает 59% ==.

Речь шла о том, что на этапе компрессии оставлять флаг этого равенства. Т.е. во время декомпрессии значение этого равенства должно было быть уже известным.

Думаю нет смысла этот делать, а просто нормализовать все.

Я делал и это дало заметный эффект. У меня в 70% равенство, но с быстрым умножением, а не тормозным делением.

//#define MathTicker_optimize //optimize best number of files and ticks
Как будут результаты, дайте знать. Все таки нестандартная конфигурация.
fxsaber #:

Речь шла о том, что на этапе компрессии оставлять флаг этого равенства. Т.е. во время декомпрессии значение этого равенства должно было быть уже известным.

Я делал и это дало заметный эффект. У меня в 70% равенство, но с быстрым умножением, а не тормозным делением.

Так проблема не только в замедлении, но и в том, что массивы не проходят тест на сравнение. Вроде моя формула эквивалентна вашей, но может что и не так, если есть отличия...
Ну а если еще и метку каждому тику сохранять, то и  размеры файлов увеличатся. Наверное байт надо выделять на это. Это увеличит файлы с средним в 3,2 байта до 4,2 байт.
Думаю просто нормализацию оставить. Согласен, что для тп/сл при касании она нужна. Уберу дефайн на отключение нормализации.
Тем более что потери в 1 секунду на тест за 3 года (кажется так) - не большая потеря. У меня каждый проход 12 минут считался последний раз из за долгого обучения МО. А на какие то простые быстрые стратегии (чтобы за секунды считались) у меня нет идей.

с быстрым умножением, а не тормозным делением.
Тоже использую умножение. 
v=d * this.point
fxsaber #:
Как будут результаты, дайте знать. Все таки нестандартная конфигурация.
Подбор числа файлов убрал из кода. С одним файлом все отлично работает. SSD его кеширует наверное и отдает со скоростью примерно, как RAM. Так что наверное лучше уменьшать размер файлов. Тут подбор числа тиков в блоке можно сделать и наверное под каждый вариант из 6 он будет разным.
Forester #:
Ну а если еще и метку каждому тику сохранять, то и  размеры файлов увеличатся.

У меня шесть байтов на тик, поэтому мог себе доп. биты позволить без увеличения размера. Ваш же вариант значительно сильнее по степени сжатия, а потому чувствительнее к доп. информации.

Forester #:
Тоже использую умножение.

Здесь надо менять - ускорит.

   long ToLong (double d){return (long)(d / this.point      + 0.01);}//цена

Подбор числа файлов убрал из кода.

Вы, вроде, говорили, что увеличение файлов-клонов в RAM-диске поднимает производительность на определенных конфигурациях. В EAToMath это вынес в input-параметры. В блоге описывал.

Сколько копий файловых тиков использовать. На некоторых конфигурациях с многокальной памятью этот параметр может влиять на итоговую производительность
Forester #:

Еще одна идея есть.

Возможно, что-то из этого создаст почву для дельных мыслей. Я не смог взрастить.
123456789
Новый комментарий