LINUX.ORG.RU

Есть ли такой формат данных?


0

0

Программа генерит в результате моделирования (интегрирования ODE) числовые данные. Их можно интерпретировать как траектории случайных процессов или как значения функций, вычисленные по сетке с постоянным шагом dt, начиная c t_0:

X: x_t0, x_t1, ..., x_tn;

Y: y_t0, y_t1, ..., y_tn,

...

где t_i = t0 + i*dt.

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

Формат CSV не устраивает хотя бы потому, что OpenOffice.org криво читает такие файлы с числовыми данными.

★★★★★

Ответ на: комментарий от dilmah

А какой именно XML? Есть что-нибудь типа MathML? И такое, чтобы понималось другими программами.

dave ★★★★★
() автор топика

Щас чувствую народ начнет дурачиться и предлагать невиданную экзотику.

Вообще вопрос поставлен неправильно. Выясни, чем ты будешь считать статистику и строить графики, и вопрос отпадет.

З.Ы. Наиболее компактный формат -- это сдампить IEEE сколько-то-там с плавающей точкой на С/С++. Если у тебя сотни миллионов точек -- м.б. важно.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> чем ты будешь считать статистику и строить графики, и вопрос отпадет.

Ты не понял. Мне самому обрабатывать ничего не надо. Это может быть полезно для других.

Хорошо. Поставим вопрос по другому. Чем обычно обрабатываются такие данные? Какими приложениями? Кроме офиса.

dave ★★★★★
() автор топика
Ответ на: комментарий от CL-USER

> SEXP

Это привязано к лиспу?

dave ★★★★★
() автор топика
Ответ на: комментарий от yoghurt

> XLS

Спасибки. Тоже вариант. Как бы только создать XLS-файл?

dave ★★★★★
() автор топика

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

imp ★★
()
Ответ на: комментарий от imp

Неправильно подозреваешь :)

TSV, ставил запятые и точки. Результат один: некоторые числа воспринимаются как даты. Можно импортировать все ячейки CSV как текст, а потом устанавливать числовой формат вручную. Так сработает, но не все пользователи догадаются. Скорее всего, увидят, что дефолтовый импорт CSV работает криво, и решат, что файл битый или еще что другое похуже...

Кстати, XLS - вполне вариант. Некоторые линуксовые проги его понимают. Пока нашел библиотеки POI и NPOI. Вопрос в том, заработает ли последняя в Mono, и позволяет ли лицензия (апачевская) использовать библиотеку в LGPL и GPL проекте. Целевая среда: неортодоксальные Mono + Gtk#.

dave ★★★★★
() автор топика

Есть еще вариант. Создавать ods-файл в формате OpenOffice.

dave ★★★★★
() автор топика
Ответ на: комментарий от dave

> Кроме офиса.

По моим понятиям, такие данные обрабатываются чем угодно, но не офисом :)

А тулз, например, такие:
- Чтобы прикинуть, gnuplot.
- Чтобы исследовать, R.
- Чтобы вставить в отчёт, pgfplots.

Sphinx ★★☆☆
()
Ответ на: комментарий от Sphinx

> По моим понятиям, такие данные обрабатываются чем угодно, но не офисом :)

Я бы разделил потенциальных пользователей на две неравные группы.

К первой относятся те, кто может реализовать метод Рунге-Кутта самостоятельно, если очень надо. Но это муторно и ведет к ошибкам, особенно при использовании сложных зависимостей, массивов, случайных функций и т.д. Там есть свои нюансы. Бывает проще взять готовую систему, которая взяла бы на себя рутину. Мой код (LGPL) реализует именно такую систему.

Здесь полезен формат CSV, который затем может быть обработан в octave, gnuplot, R и т.п.

Как мне кажется, в линуксе доля таких пользователей должна быть достаточно высокой. Но они, как правило, не являются целевой аудиторией системной динамики (так называется прикладная область).

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

Здесь уже крайне полезна бесшовная интеграция с офисом. Нужен или XLS, или опенофисовский ODS. Поскольку с CSV есть проблемы. Кажется, только MS Office нормально читает CSV, но не OpenOffice. Для линукса имеет значение последний.

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

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

dave ★★★★★
() автор топика

О чудо, опен-офис хорошо прочитал CSV! Надо будет проверить импорт по дефолту на буржуйских системных настройках. В общем, снимаю свои возражения. :)

dave ★★★★★
() автор топика

Если кому интересно, то первоначальная идея трансформировалась в следующую.

Существующее математическое ядро, написанное на C# с минимальными зависимостями от системы (используется CodeDom), оборачивается в консольное приложение.

На входе поступает описание задачи на высокоуровневом языке (можете найти тему про MapSim, которую я создавал ранее). Либо из файла, либо из стандартного ввода.

На выходе получаем следующую информацию.

Если есть ошибка, то ее краткое описание и местоположение.

Если ошибок нет, то в зависимости от опций выдает:

- либо текстовое описание вычислительного графа (для тестирования);

- либо сгенерированный код на C#, который интегрирует заданную входную модель (кстати, благодаря JIT работает очень быстро, почти так, как если бы алгоритм был запрограммирован на языке C);

- либо итоговый CSV/TSV файл с результатами моделирования (опция по дефолту).

Это позволяет, например, написать GUI на питоне, используя matplotlib для вывода графиков. Вполне можно сделать что-то типа системы Berkeley-Madonna (без редактора диаграмм, который там неосновной). Математическое ядро у меня уже давно есть. Оно хорошо оттестировано. Ему много лет. Теперь нужна GUI оболочка (для винды она тоже есть, но там другие приоритеты у GUI приложения).

Так что, выбор пал на CSV :)

dave ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.