Парсер функции

Язык-то какой?

З.Ы. Я когда-то в подобной задании на делфях сделал свой парсер без проблем.

все время зыбваю указывать - С/С++

С/С++

Нет такого языка =) Есть С, есть С++. На чем ты пишешь?

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

я тебе такое на хаскеле могу написать.

да мне б либу обычную какую-нить=) у меня и так знакомый на флексе+бизон собирается писать)

да мне б либу обычную какую-нить=) у меня и так знакомый на флексе+бизон собирается писать)

Ну так отлично, чего тебе еще надо? =)

Или если ты ленивый, то gcc + fprintf сделают свое черное дело :D

ну пока он напишет - это раз... и не хочется использовать, что-то стороннее в плане языка - это два...

Пишется за 5 минут. За полчаса - если не знаешь теории.

Вот тебе LL(1) грамматика в PEG, чтобы сразу парсер писать.

expr <- WS additive EOF
additive <- multitive restAdditive
restAdditive <- PLUS additive
                / MINUS additive
                /
multitive <- factor restMultitive
restMultitive <- STAR multitve
                 / SLASH multitive
                 /
factor <- term restFactor
restFactor <- CARET factor
              /
term <- LPAREN additive RPAREN
        / MINUS term
        / NUMBER
        / VAR

PLUS <- '+' WS
MINUS <- '-' WS
STAR <- '*'
SLASH <- '/' WS
CARET <- '^' WS
NUMBER <- [0-9]+ WS
VAR <- [a-zA-Z]+ WS
WS <- [\r\t\n ]*
EOF <- !.

И вообще - было в SICP.

lovesan

Небольшая поправка:

term <- LPAREN additive RPAREN
        / MINUS term
        / PLUS term
        / NUMBER
        / VAR

PLUS <- '+' WS
MINUS <- '-' WS
STAR <- '*' WS
SLASH <- '/' WS
CARET <- '^' WS
LPAREN <- '(' WS
RPAREN <- ')' WS
NUMBER <- [0-9]+ WS
VAR <- [a-zA-Z]+ WS
WS <- [\r\t\n ]*
EOF <- !.

По такой грамматике только слабоумный будет писать парсер дольше получаса.

lovesan

C++ - второй по непригодности язык для такого. После Си, естественно.

Какой тупой аноним.

есть стринга

А уроки ты уже сделал?

Сишечку любимую обидели?


Но, да, надо было уточнить - ни для чего кроме простейших генераторов LL(1) и в крайнем случае, LALR(1), сишечка непригодна, потому как уебищна до невыносимости. И то, генераторы лучше писать НЕ на Си. Парсинг на сишечке это адская боль в жопе.

конечно сделал а ты?

Вот Простой пример хотя и на delphi думаю что на C++ несложно переписать

слишком толсто для такой задачи

Я тот гипотетический знакомый) В оригинале в задании стоял разбор произвольной функции. Ни больше, ни меньше. То есть, надеюсь, что всякие дробно-рациональные, экспоненты и прочая тригонометрия - это предел, но, тем не менее, flex + bison - получи расширяемость в случае неудачи во все поля. // Да, универская лаба.

libtcc from Tiny C Compiler, как вариант. Ещё Boost Spirit, или замутить парсер самому (man lex)

«x+y»

Точно так, или какая-нибудь обратная польская нотация?

И, C++ - второй по непригодности язык для такого. После Си, естественно.

Видимо, ты парсеры на Фортране не писал :D

На питоне это делается тривиально. На плюсах вроде была либа, тема тут уже всплывала, но я забыл ответ - я то это делаю на питоне;-)

А вообсче - суете тушку ф-ии как строку в отдельный модуль, компиляете его в .so-шку, грузите на ходу и все дела... пусть работает железная пила (gcc). Производные при таком подходе берете численно.

На питоне это делается тривиально.

eval?

Если Си, то рекомендую поглядеть книжечку Кернигана и Ричи. В ней такой парсер как раз рассматривался, ЕМНИП.

Ты знал, ты знал, ты не мог догадаться!(с)

На самом деле чуток сложнее - делается набор классов с перегруженными операторами, eval возвращает выражение в виде дерева, дальше делай с ним че хошь - в другой формат переводи, аналитически дифференцируй (такое же дерево вылазит), прогоняй через CAS и т.д.

Вспомнил, читал про такое. Зачётная идея, одобрямс.

На плюсах кстати аналогично (у меня даж такая лаба есть;-)) - базовый класс с перегруженными операторами, наследники (для каждого оператора свой + числа + переменные), дальше задаем исходные переменные и напускаем на это gcc. Т.е. делаем ручками сист. хранения и преобразования выражения, а парсит нехай компайлер. Только в плюсах со сборкой мусора надо возится...

Ну и еще при выводе что бы лишних скобок не лепить надо озаботится коммутативностью и приоритетом операторов;-)

За использование eval для такого надо руки отрубать и выгонять из профессии.

Это аналогично: http://juick.com/dmz/1669710

lovesan

а уж за использование целого GCC - тем более.

А что, Вы уже асили документацию к своему супер-пупер продукту, что тратите тут свое бесценное время на высказывание своего мнения (которое вообще то никого не интересует)?

И, C++ - второй по непригодности язык для такого.

да, смотрится тяжеловато http://chilon.net/library.html

https://github.com/nuisanceofcats/nyah

хотя в tbPEG грамматика чуть полегче выглядит, ну да это в основном сахарок http://chilon.net/papers/tbpeg.pdf http://chilon.net/nyah/

После Си, естественно

на C, кстати более пристойно: https://github.com/nddrylliog/greg

дадада, ещё можно Cling из LLVM воткнуть: http://llvm.org/devmtg/2010-11/Naumann-Cling.pdf , вот только нафига?

переводим в RPN (обратную польскую нотацию), а там уже всё совсем просто.

А с-но ЗАЧЕМ? То о чем я говорю не требует сторонних библиотек и занимает абсолютный минимум строк кода. Что, ТС где то акцентировал внимание на производительности, он пишет мировой веб-интерефейс для расчета производных всеми страждущими (сдающими ЕГЭ), который будет крутиться на одном древнем пне? Или лишних вызовов eval/gcc религия не позволяет? А как же простите тогда unix-way?

Или лишних вызовов eval/gcc религия не позволяет?

Каждый вызов eval/gcc - это огромная дыра в архитектуре, которую ничем не прикрыть. И имеет смысл использовать подобные средства лишь в том случае, когда альтернативные способы решения задачи несравнимо сложнее. Здесь речь идет о написании нескольких строк кода - такой выигрыш использование евала (а уж тем более gcc) не оправдывает.

Каждый вызов eval/gcc - это огромная дыра в архитектуре, которую ничем не прикрыть.

Это ИМНО очень спорное утверждение.

Народ! Подскажите плз какую-нибудь библиотеку для парсинга функции двух переменных - то есть у нас есть стринга, что-то типа «x+y» А мне надо узнать значение этой функции и взять производную. Графики её я уже придумал - буду строить с помощью mathgl, но там не смог найти, описанную выше функциональность.... ЗЫ навык гугления у меня очень мало прокачен=(

Вообще-то там есть — см. mglFormula::Calc(), mglFormula::CalcD()

http://mathgl.sourceforge.net/mathgl_en/mathgl_en_55.html#mglFormula-class