Чтение 32-битных подписанных ieee 754 с плавающей запятой из двоичного файла с помощью python?

У меня есть двоичный файл, который представляет собой простой список подписанных 32-битных чисел с плавающей запятой ieee754. Они ничем не разделены, а просто появляются друг за другом до EOF.

Как мне читать из этого файла и правильно интерпретировать их как числа с плавающей запятой?

Я пытался использовать read(4), но он автоматически преобразовывал их в строку с кодировкой ascii.

Я также пытался использовать bytearray, но это занимает только 1 байт за раз вместо 4 байтов за раз, как мне нужно.


python parsing floating-point binaryfiles ieee-754
person Razor Storm    schedule 08.06.2011    source источник

Ответы (2)


arrow_upward
31
arrow_downward 

struct.unpack('f', file.read(4))

Также можно распаковать сразу несколько, что будет быстрее:

struct.unpack('f'*n, file.read(4*n))
person Marcelo Cantos    schedule 08.06.2011
comment
+1 за 'f'*n; где этот синтаксис задокументирован? Должно быть, я пропустил это в своем учебнике по Python. - person Andrew White; 09.06.2011
comment
Умножение строк задокументировано в руководстве и в справочном разделе библиотеки по объектам последовательности. - person Thomas Wouters; 09.06.2011
comment
@Andrew: об этом есть краткое упоминание в руководстве в разделе строки. Ищите повтор. - person Marcelo Cantos; 09.06.2011
comment
Более общий способ распаковки нескольких будет unpack('{0}f'.format(n), ...), или, если вы знаете, сколько заранее, то просто unpack('10f', ...), например. Лучше использовать встроенный метод повторения, чем полагаться на манипуляции со строками. - person Scott Griffiths; 09.06.2011
comment
@cdiggins: я предпочитаю то, что требует наименьшего количества набора текста и легче всего читается. Эти два фактора иногда противоречат друг другу, так что вы, возможно, поменяли одно на другое, но в данном случае моя версия короче и понятнее. С точки зрения производительности, я ожидаю, что эти две формы будут почти идентичными, поскольку основная часть времени тратится на подсистему ввода/вывода. Если длина известна во время кодирования, то я согласен, что '10f' лучше по тем же причинам: он немного короче и легче читается, чем 'f'*10. - person Marcelo Cantos; 11.03.2012
comment
@Marcelo, я согласен с принципом, но подумайте о распаковке 100 000 инт. Мне не имеет смысла создавать строку формата длиной 100 КБ. Вместо этого '{0}f'.format(1000000) имеет больше смысла. - person cdiggins; 11.03.2012
comment
@cdiggins: Что не имеет смысла? При 100000 элементов моя версия на 10% (12 мкс) медленнее и остается заметно короче и четче. - person Marcelo Cantos; 12.03.2012

arrow_upward
5
arrow_downward

Взгляните на struct.unpack. Что-то вроде следующего может работать...

f = struct.unpack('f', data_read)
person Andrew White    schedule 08.06.2011