Можно ли хранить многомерные массивы произвольной формы в ячейке PyTables? - PullRequest
Новая
       16

Можно ли хранить многомерные массивы произвольной формы в ячейке PyTables?

1 голос
/ 19 января 2012

PyTables поддерживает создание таблиц из пользовательских классов, которые наследуются от класса IsDescription. Это включает поддержку многомерных ячеек, как в следующем примере из документации: 

class Particle(IsDescription):
    name = StringCol(itemsize=16) # 16-character string
    lati = Int32Col() # integer
    longi = Int32Col() # integer
    pressure = Float32Col(shape=(2,3)) # array of floats (single-precision) 
    temperature = Float64Col(shape=(2,3)) # array of doubles (double-precision)

Однако возможно ли хранить многомерный массив произвольной формы в одной ячейке? Следуя приведенному выше примеру, что-то вроде pressure = Float32Col(shape=(x, y)), где x и y определяются при вставке каждой строки.

Если нет, какой подход предпочтительнее? Хранить каждый (произвольной формы) многомерный массив в CArray с уникальным именем, а затем сохранять эти имена в главной индексной таблице? Приложение, которое я представляю, хранит изображения и связанные метаданные, которые я хотел бы иметь как для запроса, так и для использования numexpr вкл.

Любые указатели на лучшие практики PyTables приветствуются!

Ответы [ 2 ]

1 голос
/ 25 января 2012

Длинный ответ: «Да, но вы, вероятно, не хотите».

PyTables, вероятно, не поддерживает его напрямую, но HDF5 поддерживает создание вложенных типов данных переменной длины, что позволяет использовать рваные массивы в нескольких измерениях. Если вы хотите пойти по этому пути, вам нужно использовать h5py и просмотреть Руководство пользователя HDF5, глава «Типы данных» . См. Раздел 6.4.3.2.3. Типы данных переменной длины . (Я бы связал это, но они явно решили не ставить якоря так глубоко).

Лично я бы упорядочил полученные данные по группам наборов данных, а не по одной таблице. То есть что-то вроде: 

/particles/particlename1/pressure
/particles/particlename1/temperature
/particles/particlename2/pressure
/particles/particlename2/temperature

и так далее. Значения широты и долготы были бы атрибутами группы /particles/particlename, а не наборов данных, хотя наличие небольших наборов данных для них тоже прекрасно.

Если вы хотите иметь возможность выполнять поиск по широте и долготе, тогда было бы неплохо иметь набор данных со столбцами широта / долгота / имя. А если вы хотите по-настоящему выглядеть модно, есть тип данных HDF5 для ссылок, позволяющий хранить указатель на набор данных или даже на подмножество набора данных.

0 голосов
/ 24 января 2012

Краткий ответ - «нет», и я думаю, что это «ограничение» hdf5, а не pytables.

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

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

HDF5 на самом деле имеет API , который разработан (и оптимизирован для) для хранения изображений в файле hdf5.Я не думаю, что это выставлено в pytables.

...