памяти для pest (peg для rust с recursive descent парсером). я пока сильно плаваю в теоретической части, но вот соображения:
- согласно вики частным случаем recursive descent парсера для LL(k) грамматик является predictive parser работающий за линейное время
- для не LL(k) грамматик гарантируется только экспоненциальное время работы
- я вижу issue на гитхабе pest, где небольшое изменение грамматики позволило уйти от экспоненциального времени к линейному
- по поводу памяти вики говорит, что для ряда грамматик память в peg пропорциональна длине входной строки, а не высоте дерева разбора
в связи с этим вопрос - а как вообще проверить, что моя грамматика имеет линейное, а не экспоненциальное время и какая у нее память (логарифм или n)?
> вычислительной сложности и памяти для pest (peg для rust с recursive descent парсером) Судя по документации, это просто генератор recursive descent parsers для PEG (без memoization, но с некоторыми ad-hoc оптимизациями), я правильно понимаю? > по поводу памяти вики говорит, что для ряда грамматик память в peg пропорциональна длине входной строки Хмм... PEG — это просто формализм, утверждения вроде "память в peg пропорциональна длине входной строки" к нему вообще не относятся. Наверное, там это написано про какую-то реализацию? > а как вообще проверить, что моя грамматика имеет линейное, а не экспоненциальное время С учётом вышенаписанного (про ad-hoc оптимизации) — отладкой/тестированием, например (ну разве "аналитические грамматики" не прекрасны? ;( ). > и какая у нее память (логарифм или n)? Хмм... а при чём тут логарифм? По идее, у "наивной" реализации зависимость должна быть от высоты дерева, всё же.
1. судя по всему там нет генерации парсеров, а реализован некий универсальный recursive descent парсер 2. в вики про пропорциональную длине строки память сказано для неких peg в вакууме. что скрывается под парсером pest и справедливо ли это для него мне не понятно (у меня плавает теория) 3. варианта "тестированием" я и боялся (хотелось знать, есть ли какой-то вариант с математикой для этого) 4. согласен, высота дерева совсем не обязательно логарифм
1. По документации непонятно, в таком случае (там написано "pest works by compiling a description of a file format, called a grammar, into Rust code."). Вы же можете посмотреть, что там за "Rust code" генерируется — "табличный" parser или в самом деле recursive descent код на Rust. 2. "Анализ РВ-грамматики обычно производится packrat-парсером, который запоминает лишние шаги анализа. Такой анализ требует хранения данных пропорционально длине входных данных, в отличие от глубины дерева разбора для LR-анализаторов." — вот это? Ну так это только про этот метод реализации (подчеркнул). Если подобный метод в pest не используется — то получается O(высота дерева) памяти и экспоненциальное время разбора, в худшем случае. 3. Насчёт "математики" я не уверен (может, кто-то подскажет?) — но, опять-таки, это не "чистая" реализация (там точно есть ad-hoc optimizations, см. ссылки на ту issue), так что, даже если "математика" и есть, то с её помощью можно получить только приблизительные ответы.
Обсуждают сегодня