На чем парсить большие объемы output из научных программ
Добрый день,
есть незадачка, надо писать парсер текстовых и не очень файлов сторонних программ. То есть, есть много разных софтов, каждый из которых имеет свой формат вывода. Надо по возможности поддерживать много разных форматов сторонних производителей, зачитывая их в свой софт. Если кому-то что-то говорит, то надо поддерживать TopSpin, VNMRJ, JDF форматы + многие форматы с молекулярной механики и ab initio + и кучу разного рода текстовых и не очень настроек.
Раньше я похожим не занимался, но если что-то надо было зачитать, делал по старинке на C или С++, но форматов было мало и делалось часто для себя с предварительным парсингом ручками в vim.
Времени нет, от слова совсем. Надо быстро решить и забыть. Платформа - строго Линукс, более
конкретно Линукс, поддерживаемый на Altera Cyclone-SoC, то есть дохлый процессор с дебьяном. Софтвер или библиотека для парсинга может быть опенсорсным, и желательно бесплатной или не дорогой.
Вопрос, скажите, пожалуйста, есть ли что-то удобное в виде С или С++ библиотек так, чтоб в этом можно было бы быстро разобраться и начать пользовать и Вы бы это могли бы порекомендовать?
Или есть ли что-то легко подцепляющееся к GNU-С/C++ библиотекам, так, чтоб можно было бы обмениваться большими массивами данных в памяти между парсером и С программой?
Мозги, руки есть, освоить смогу много, мой бекграунд - высокопроизводительная вычислительная математика где-то 25 лет опыта. Теорию компиляции когда-то в Универе по Ахо-Ульману учил и что-то до сих пор помню.
Мне нужно быстро, грубо говоря на изучение языка написания парсера есть неделя времени, плюс на само написание еще неделя. На С я поддержу это за месяц, а может и быстрее, но понимаю, что добавляя в дальнейшем форматы буду тратить больше времени. Также надеюсь, что продолжение этой работы в скором времени удастся делигировать на кого-то, поэтому написать сейчас на голом С/С++ - означает переписать это заново через пол-года - год.
Спасибо!
еорию компиляции когда-то в Универе по Ахо-Ульману учил и что-то до сих пор помню.
------
Делая строго по теории компилятор написать, разумеется, можно.
Правда с непривычки это займет довольно много времени.
В зависимости от того, насколько будешь придерживаться теории - модификация может стать мучительно сложной и долгой.
А времени, как ты сам говоришь, у тебя нет.
Потому могу посоветовать делать парсинг документов на базе "распознавателей".
Т.е. ты берешь документ и режешь на куски - какие-то маркеры между частями там же должны быть - вот по ним и режь.
С текстовым документом - просто - построчно и/или по абзацам.
Нарезанные куски скармливаемые "распознавателям".
Задача распознавателя - вычислить может ли он извлечь интересующие данные из предоставленного фрагмента.
Если "распознаватель" может извлечь нужное из фрагмента - он его извлекает, если нет - т.е. кусок им не опознается как содержащий узнаваемые им данные - кусок передается следующему "распознавателю".
Что нужно помнить - ты не будешь иметь полный компилятор исходного документа или группы документов и, соответственно, могут быть множественные распознавания... ну или в терминах грамматики - локальные неоднозначности. Т.е. придется решать как это найти и как разрешить.
Но сами распознаватели писать просто.
Например - распознаватель рецепта борща.
Документ должен содержать текст "Рецепт борща.". Иначе он не считается распознанным.
Дальше пойдут ингредиенты - каждый распознается своим отдельным распознавателем.
Но ведь ты же знаешь что именно тебе надо извлечь из всех наборов данных? Вот оттуда и танцуй.
Писанины довольно много, но она не сложная. Ну валидировать весь набор надо...
Работать будет относительно медленно.
У меня документы разбираются где-то в 20 раз медленнее, чем при чтении по формату, но данные Я получаю корректные.
Модификация всей системы - относительно не сложная - меняется/дописывается только набор распознавателей - проверено на множественных изменениях форматов документов клиентами.
На чем писать - почти без разницы.
Будет чуток удобнее иметь базовый абстрактный класс и виртуальные функции, но ничто не мешает вместо массива объектов(распознователей) сделать массив указателей на функции.
Спасибо большое за ответы!
> bison? Но бинарники часто контекстно-зависимы...
я специально не писал названия... Да, можно бизоном, можно лексом, можно яком. Я правда на них еще ни разу не писал, посему и вопрошаю. Вопрос именно что проще/удобнее, пожалуйста, посоветуйте!
Понятно можно и на тикле с перлом тоже писать, в моем случае в них разбираться не надо будет, так как я на них писал уже, и на них точно будет проще, чем на голом С/С++, но 100% потом придется переписывать.
> 2murr
Да, теория мне понятна, я не зря про Ахо-Ульмана написал, да и ИИ могу на OpenCL прикрутить, благо железо позволяет, но нет необходимости это делать, ибо нужно быстро, удобно, и без выежонов. То есть реально нужен форматированный ввод, только форматы очень у всех разные и поддерживать на обычных языках (С/С++ и даже то, что работает со строками типа перла) этот синтаксис очень не удобно.
Посему ищется адекватное мнение, кто пользовал или хотя бы видел, на каком из зверей или с помощью какой библиотеки зверей это реализовывать, вдруг кто знает и имеет практический опыт, посоветуйте, пожалуйста!
Еще раз хотел бы заметить, что данные - обычно научные, то есть там довольно большие таблицы чисел, которые иногда надо на лету слегка скалировать, нормировать, или еще как преобразовывать. И да, бинарники тоже, к сожалению, имеются.
То есть функциональность какого-нибудь быка с прямым доступом в С ИМХО выглядит идеальной, но может есть что-то и более правильное?
-----
Как вариант:
https://www.codeproject.com/Articles/28294/a-Tiny-Parser-G...
Редактировать более-менее удобно.
Но тебе будет нужно описать имеющиеся документы какой-то грамматикой и как-то обрабатывать свертку правил.
По грамматике тебе уже MrSanders сказал - могут быть множественные неоднозначности, особенно на бинарниках.
ибо нужно быстро, удобно, и без выежонов.
-----
Тогда сначала оцени с какой стороны подходить к задаче:
- от полной спецификации документа к тому что в нем возможно содержится
- от того что ты ищешь к способу его извлечения.
В первом случае - ссылка выше,
Во втором - описано мною раннее.
Для 10-ти вариантов извлекаемых данных Я бы не стал возится с полным парсингом сотни типов документоv.
Ок, я понял, спасибо, что отвечали, мурр.
В общем, вопрос ребром, вернее три:
1. на сколько реально разобраться и начать писать на функционале бизона?
2. на сколько реально сделать микс между LALR грамматикой, (как я понимаю, бизон ее поддерживает) и Сшными вставками, так, что документ кусками парсится бизоном, кусками - голым С (для поддержки бинарников и вычислительных преобразований).
3. и насколько реально при полной мотивации начать писать уже на таком миксе так, что эффективность будет существенно выше, чем на голом С, это за неделю реально или совсем нет?
Кто с практическим опытом, или хотя бы видел слышал, поделитесь, пожалуйста!
Спасибо!
Мне нужно быстро, грубо говоря на изучение языка написания парсера есть неделя времени, плюс на само написание еще неделя. На С я поддержу это за месяц, а может и быстрее, но понимаю, что добавляя в дальнейшем форматы буду тратить больше времени.
Мне кажется, что на опросы и попытки воспользоваться какой-то супер-технологией (не факт что получится), уйдет больше времени, чем написать на том языке, которым уверенно владеешь (это же не мегапроект на годы). Короче, хватит трепаться, пиши гамильтониан... С пламенным приветом от бывшего физика-теоретика, а теперь борца за денежные знаки для дяди и для себя, конечно. :))
> Мне кажется, что на опросы и попытки воспользоваться какой-то
супер-технологией (не факт что получится), уйдет больше времени, чем
написать на том языке, которым уверенно владеешь (это же не мегапроект
на годы). Короче, хватит трепаться, пиши гамильтониан... С пламенным
приветом от бывшего физика-теоретика, а теперь борца за денежные знаки
для дяди и для себя, конечно. :))
спасибо за мнение! Оно понятно и очевидно и я с ним почти согласен.
За супер-технологией не гонюсь, только вижу, что методом в лоб на С придется изобретать много велосипедов. Иногда на поверхности лежат красиво и путево написанные велосипеды, и грех ими не воспользоваться. ИМХО, даже вставки на tcl с прямым вызовом из С могут сильно упростить задачу, и это мне понятно как делать.
2MrSanders - бизон похоже осваиваем, и как раз можно в Сшник встроить, СПАСИБО БОЛЬШОЕ!!!
1. Идёт речь о потоке данных или об архиве данных?
Если данные идут потоком с разных систем по Сети, то стандартное решение состоит в добавлении интерфейсов-Schnittstellen. Это гораздо проще, чем иметь дело с распознаванием содержимого сгенерированных медиа файлов различных форматов. Если нужно распознавание, то задача неразрешима в обозначенных ТС сроках. ABBY имеет лучший распозанватель-OCR на рынке, но и он делает ошибки, т.к. любое распознавание основано на шаблонах. Чем специфичнее содержание документа, тем хуже будет результат. Самому писать подобную программу нет смысла, если речь не идёт о чём-то простом или не ставится задача создать свой OCR-продукт, т.к. создавать шаблоны или натаскивать ИИ весьма трудозатратно.
2. Что происходит с полученными данными?
Если речь идёт об архивации, задача сводится к простой конвертации форматов. Если требуются вычисления на основе данных, то подход с парсингом в принципе неверен, т.к. 100% корректного распознавания никто пока не добился, если речь не идёт о "табличных" форматах, как CSV.
Огромное спасибо за советы!!!
Bigfoot - огромное спасибо за ссылку, я что-то этот пакет проморгал, который в моем случае многое на раз решит.
Еще бы такое же для NMR / VNMR Pulse Sequence, ибо хочется дать юзеру возможность сконвертировать их понятные уже написанные программы в мой формат. Если вдруг знаете, пожалуйста, поделитесь, пожалуйста, информацией!
AlexNek - да, Вы правы, примерно так и планировал.
beatus - надо быстро и безболезненно написать конвертор нескольких известных форматов ЯМР спектров в мой и обратно, то же самое, но в одну сторону - для последовательности импульсов. Большинство форматов я знаю, или сталкивался, но форматы - зоопарк реально.
У меня есть свой внутренний формат спектров, отличающийся от классических FID, которые пользуют все.
Отличие - из-за того, что пользуются дешевые нестабилизированные магниты и в них замешана ошибка флуктуаций магнитного поля. Эту ошибку можно убрать или повторными экспериментами, и/или если есть несколько спектров от разных изотопов. Большинство современных юзеров не готово вот так сразу мыслить в таких терминах и бета тестеры мне это высказывают - для них это магия, как из кривого спектра можно получить хороший.
Понятно 1D спектр я могу нарисовать и дать юзеру сравнить, хоть визуально, хоть в виде таблицы. Но есть многомерные спектры. И вот тут надо сравниваться, зачитывать зоопарк известных форматов и сравнивать с тем, что есть у меня.
Так как визуализатор со сравнивалкой я планировал сдавать в опенсорс, так как всяко уже несколько универов готово там
девелопить, то хочется заранее сделать маленькую красивую рыбу, и только ее администрить.
Само железо на котором это работает пока FPGA Cyclone 5 SoC, с дебьяном, но, девелопмент в опенсорсе можно и на обычной Убунте или Дебьяне делать, только главное, чтоб конвертер Pulse Sequence не создал медленно исполняемого кода, который не потянет мой SoC.
> Ах, вот оно што ) Хотите создать шаблоны для "зоопарка" форматов автоматически?
шаблоны - да, но не автоматически, а ручками, только ручками удобнее с помощью бизона и других известных и уже лежащих в свободном доступе велосипедах, как заметили и советовали MrSanders и Bigfoot.
А вот сама разпознавалка спектров по уже имеющейся базе данных будет с элементами иерархических тензорных аппроксимаций, что сейчас модно называть AI, но это совершенно не тема этого вопроса и это, к счастью уже работает :)