Меры предосторожности Python для экономии на размере текстового файла чисто числовых символов

Question

Я собираю много выводов из сетевого анализа, перечисляя ребро на строку, что приводит к десяткам гигабайт, расширяя границы моих ресурсов (занижение). Поскольку я имею дело только с числовыми значениями, мне пришло в голову, что я могу быть умнее, чем использовать значения по умолчанию Py3k. То есть какая-то другая кодировка символов могла бы сэкономить мне немного места, если бы у меня были только цифры (и пробел и случайная десятичная точка). Как бы я ни был ограничен, я мог бы даже сэкономить на концах строк (не иметь дубликат CRLF в стандарте Windows). Какова лучшая практика в этом отношении?

Пример строки будет выглядеть так:

62233 242344 0,42442423

(Там, где на самом деле последнее число бессмысленно точно, я урежу его до трех ненулевых цифр.)

Поскольку мне нужно будет читать текстовый файл с помощью другого программного обеспечения (фактически, Stata), я не могу хранить данные в произвольном двоичном формате, хотя я не вижу причин, по которым Stata будет читать только текст UTF-8. Или вы просто говорите, что отказ от UTF-8 едва ли что-нибудь спасет меня?

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

Спасибо за все идеи и уточняющие вопросы!

Answer 1

Вы можете использовать zlib или gzip для сжатия данных при их создании. Вам вообще не нужно будет менять формат, сжатие будет корректироваться в соответствии с символами и последовательностями, которые вы используете чаще всего, чтобы создать оптимальный размер файла.

Answer 2

Избегайте кодировки символов полностью и сохраняйте ваши данные в двоичном формате. Смотрите Python struct . Закодированное в Ascii значение типа 4 миллиардов занимает 10 байтов, но помещается в 4-байтовое целое число. Существует много недостатков в пользовательском двоичном формате (его трудно отладить вручную или проверить с помощью других инструментов и т. Д.)

Answer 3

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

Сила Гзипа

Да, есть библиотека Python, позволяющая вам выводить поток и автоматически сжимать его.

Кодировка с потерями экономит место. Сокращение точности помогает.

Answer 4

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

Мгновенное сохранение в два раза меньше, если бы вы использовали 4 бита на символ. У вас есть алфавит от 0 до 9, точка, (возможно) знак минус, пробел и символ новой строки, которые представляют собой 14 символов, идеально подходящих для 2 ** 4 == 16 слотов.

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