Эффективное хранение большой матрицы на жестком диске
У меня много больших 1GB+ матриц doubles (плавает), многие из них 0.0, которые должны храниться эффективно. Я держусь double типа, так как некоторые элементы действительно должны быть double (но я могу рассмотреть возможность изменения этого, если это может привести к значительной экономии места). Заголовок строки не является обязательным. Матрицы не имеют пропущенных элементов, NaN, NA, NULL и т. Д.: все они doubles,
Некоторые столбцы будут редкими, другие не будут. Соотношение разреженных столбцов будет варьироваться от файла к файлу.
Что такое экономически эффективная альтернатива CSV? Для моего использования мне нужно быстро разобрать эту матрицу в R, python а также Javaпоэтому формат файла, специфичный для одного языка, не подходит. Доступ может быть по строке или столбцу.
Я также не ищу коммерческого решения.
Моя главная цель - сэкономить место на жестком диске без выдувания io раз. Использование ОЗУ после импорта не является основным фактором.
1 ответ
Самый важный вопрос, если вы всегда расширяете всю матрицу в памяти или вам нужен произвольный доступ к сжатой форме (и как). Расширение намного проще, поэтому я концентрируюсь на этом.
Вы можете использовать растровое изображение, указывающее, присутствует ли число или ноль. Это стоит 1 бит на запись и, следовательно, может увеличить размер файла на 1/64 в случае отсутствия нулей или уменьшить его до 1/64 в случае всех нулей. Если есть серии нулей, вы можете сохранить количество следующих нулей и число ненулевых вместо этого, например, упаковав два 4-битных числа в один байт.
Как double Представление стандартное, вы можете использовать двоичное представление на обоих языках. Если многие из ваших номеров на самом деле ints, вы можете рассмотреть что-то, как я сделал.
Если последовательные числа связаны, вы можете рассмотреть возможность сохранения их различий.
Я не обращаю внимания на сохранение типа double, поскольку некоторые элементы действительно должны иметь тип double (но я могу рассмотреть возможность его изменения, если это может привести к значительной экономии места).
Очевидно, что переход на float обменял бы половину точности на остановку памяти. Это, вероятно, слишком неточно, так что вы можете вместо этого пропустить несколько битов из богомола и получить, например, 6 байтов на запись. В качестве альтернативы вы могли бы уменьшить показатель степени до одного байта, так как диапазон от 1e-38 до 3e38 должен быть достаточным.