Хранение метаданных в многомерном массиве

Графики обычно - либо зависимость x от y при определенных параметрах, либо зависимости вида heat map https://en.wikipedia.org/wiki/Heat_map

А многомерный массив полностью заполнен?

Вообще это набор (список) записей, каждая из которых словарь вида {имя_параметра1:значение_параметра1, ...}

Да, многомерный массив полностью заполнен. А как потом зависимости строить? Сейчас приходится вручную смотреть куда что записал, а в идеале хотелось бы иметь такую структуру данных, чтобы можно было написать обвязку: построить зависимость того-то от того-то при таких-то таких-то значениях. Никак не придет в голову как это реализовать и не знаю даже слов по которым бы погуглить что-то подобное.

обычная реляционная база данных с индексами не годится? Строишь индексы по интересующим тебя параметрам, потом делаешь выборки.

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

Объём данных-то вообще какой?

Не знаком с реляционными базами, не слишком ли сложно для подобной задачи? В идеале хотелось бы обойтись стандартными средствами языка и сохранить текстовое отображение, чтобы если что можно было заслать данные коллабораторам.

Объём данных какой? Мегабайты? Гигабайты? Терабайты?

Объем смешной, типичный экспримент 3x10x10x20, где 3 - количество экспериментов выполненных при идентичных экспериментальных условиях 10 значений параметра1 10 значений параметра2 20 интересующих интенсивностей, полученных в результате обработки. Нужно выводить, например, зависимости различных интенсивностей в зависимости от параметра2 при фиксированном параметре1 после усреднения по всем 3 экспериментам или что-то в таком роде.

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

Твои данные можно представить как таблицу, в которой каждая строка соответствует одному эксперименту, а колонки описывают условия (параметры) эксперимента (даже если они не менялись в течение данноно эксперимента) и, собственно результаты эксперимента, ну и плюс колонка, идентифицирующая сам эксперимент. При твоих объёмах такую таблицу можно просто в Openoffice Calc держать. И сортировать и строить графики по любым колонкам, которые тебе захочется.

Не, если ты не об анализе тех гигабайт, то это уже другая тема. Вот ежели ты каждый раз прокачивал бы немеряные объёмы данных для каждого среза - там был бы смысл выкручиваться и искать пути оптимизации. Ну просто затраты времени на оптимизацию окупились бы снижением затрат времени на ожидание результата. А с шестью тысячами выборок - не стоит и напрягаться.

Openoffice - не подходит по 2-м причинам: 1) много работы ручками 2) графики некрасивые, если потом придется публиковать. Я сделал для нескольких экспериментов ручками, а теперь нужно сделать десятки/сотни различных экспериментов и желательно бы написать код, в котором нужно делать минимальные изменения для следующих входящих данных. Эксперимент по большей части автоматизирован.

В реляционных БД можно просто написать на языке SQL «Выбери мне такие-то колонки таблицы из строк, отвечающих таким-то условиям в таком-то порядке», но ты же не хочешь их изучать.

Если ты обмениваешься данными с коллегами, то электронные таблицы в открытом формате сойдут, какие бы ни были уродливые графики, а для публикации никто не мешает экспортировать данные и воспользоваться твоим обычным способом рисования красивых графиков. Кстати, чем ты их рисуешь красиво?

Да, не хотелось бы. Пожалуй лучше напишу костыль на кортэжах, словарях и списках, благо скорость не критична. Проблема с реляционными базами - потом забудешь как поправить что-то через год. Все заново нужно будет изучать. Рисую в матплотлибе. Вот пример графика:https://imageshack.us/i/exTJRRYxp Или вот для внутреннего пользования: https://imageshack.us/i/pa9zB8EEp

Проблема с реляционными базами - потом забудешь как поправить что-то через год. Все заново нужно будет изучать.

Кортежи разве проще вспомнить? Я, например, это слово-то в последний раз слышал лет двадцать или двадцать пять назад. В курсе реляционных баз данных, кстати :)

Да и не надо бояться забыть. Просто надо записывать. В случае с наборами данных это означает, что ты создаёшь стандартное представление данных (csv, SQL база данных или ещё что-то) и пишешь скрипт, который делает выборку, строит график и т.п. Если данные поменялись - ты построишь новый график тем же скриптом, применив его к другому набору данных. Чтобы не забыть что там у тебя в скрипте - обычно есть возможность откомментировать код. Да и твоим коллегам будет легче понять что ты делаешь в скрипте и проверить их корректность если потребуется.

Рисую в матплотлибе. Вот пример графика:https://imageshack.us/i/exTJRRYxp Или вот для внутреннего пользования: https://imageshack.us/i/pa9zB8EEp

Судя по их галерее, выглядит получше чем гнуплот. Хотя твои примеры графиков по качеству сосут и у гнуплота и у опенофиса, конечно..

А можешь кинуть пару примеров, например, на pastebin.com и сюда выложить ссылки?

Вообще то задача ТС на реляционные БД не ложиться - набор ключей заранее не известен и может меняться. Можно конечно ее и на реляц.БД сделать, но будет даже кривее чем средствами ЯП.

Можно посмотреть в сторону каких нить ооБД.

У нас есть такая шняга для хранения и обработки результатов числ.моделирования.

Пишите в личку aivanov [собака]keldysh [точка]ru

код на работе и write only, написан на коленке перед конференцией, вот сейчас собираюсь привести в порядок, тогда выложу

А netcdf/hdf5?

Решил остановиться на hdf5 и его привязке к питону h5py http://www.h5py.org/ http://stackoverflow.com/questions/23548704/search-for-attribute-value-in-hdf...

Да уже нашел, спасибо, похоже то, что надо

болшое преимушество грапхиков на матплотлиб перед офисом в том, что я их в любой момент смогу поправить до нужного качества все сразу небольшим изменением в коде

Вообще то задача ТС на реляционные БД не ложиться - набор ключей заранее не известен и может меняться.

Как это не известен? Известен - это его входные параметры.

Можно посмотреть в сторону каких нить ооБД.

Да, и чем это лучше кроме того, что сложнее? Человеку вон SQL трудно освоить почему-то.

Пишите в личку aivanov [собака]keldysh [точка]ru

Вот ещё. Ты тут пиши. Чтобы твоя дурь каждому видна была.

Как это не известен? Известен - это его входные параметры.

От запуска к запуску они различаются. Можно конечно хранить все в таблицах вида имя-параметра:значение-параметра, но нафига тогда прикручивать БД? Средствами питона это делается куда проще и прямее.

Да, и чем это лучше кроме того, что сложнее? Человеку вон SQL трудно освоить почему-то.

Тем что это сделано для задач типа задачи ТС.

Вот ещё. Ты тут пиши. Чтобы твоя дурь каждому видна была.

Ваша уже видна. Собакой своей будете командовать.

Очень странно что в треде нет слова numpy.

NumPy?