Имеется последовательность чисел, которая плавно возрастает, убывает и тд. Хочется её сжать. Числа с точностью 4 цифры после запятой.
Базовая оценка: текстовый JSON вида {"items": [0.1234, 0.1234, 0.1235, 0.1235, ...]} занимает 358 KB, сжимается гзипом до 73 KB.
Первый подход — извлекаем числа, масштабируем до целых (умножаем на 10000) и сохраняем как 4-байтовые int-ы в бинарном файле. Потом гзипуем файл. Получаем 69 KB.
Второй подход — сохраняем не сами числа, а разницу между ними, т.к. они довольно медленно возрастают/опускаются. Опять сохраняем как 4-байтовые int-ы. Получаем 44 KB.
Третий подход — нормализуем эти разницы, отнимая минимальное число, т.е. от 0 до max-min. Идея в том, что числа довольно маленькие, а отрицательные числа будут представлять из себя кучу единиц, может быть они сожмутся хуже нулей. Толку нет, получилось даже немного хуже.
Четвёртый подход — замечаем, что разницы умещаются в два байта максимум, а порой и в 1 байт, делаем немного умней алгоритм и сохраняем их группами то по 2 байта, то по 1 байту. Гзипаем результат, получилось 38K.
Пятый подход — реализуем всё сжатие вручную на кодах Хаффмана. В общем получилось лучше gzip, но не намного, цифр сейчас нет, в целом решил не двигаться в этом направлении, т.к. кода много, а толка мало. Общий подход был таков: берём разницы, часто эти разницы равны друг другу, т.е. идёт, например, куча нулей подряд, поэтому записываем парами (разница, количество разниц), потом считаем коды Хаффмана для значений разниц и для значений количеств разниц, потом записываем максимально экономя каждый бит это всё в конечный файл.
Вопрос — есть ли способ скармливать gzip-у данные так, чтобы он их как можно лучше распознавал и сжимал? Gzip нравится, т.е. его проверенные реализации есть везде.
Альтернативно можно попробовать сделать свой алгоритм, тогда тоже буду рад советам, но только если этот алгоритм будет намного лучше gzip-а, хотя бы раза в 3, т.к. его как минимум на двух языках придётся реализовывать и поддерживать, овчинка должна стоить выделки.