Это псевдо домашняя работа (это дополнительный кредит). У меня есть BST, который является индексом слов, указывающих на строки (хранящиеся где-то еще), содержащие слова. Мне нужно реализовать способ поиска с использованием s-выражений, чтобы я мог комбинировать и (&) и/или (|).
В командной строке пользователь может ввести что-то вроде:
QUERY ((((fire)&(forest))|((ocean)&(boat)))&(water))
По существу, это должно возвращать все строки, содержащие слова: огонь, лес и вода, а также все линии, содержащие океан, лодку и воду.
Мне нужна помощь в логике для синтаксического анализа и вставки узлов в дерево, чтобы правильно представлять выражение больше, чем фактический код. Единственное, что я разработал, что имеет смысл для меня, это вернуть набор строк для каждого слова в выражении. Тогда в зависимости от того, была ли это операция "или" или "и", я бы выполнил операцию объединения или типа пересечения на этих наборах, чтобы создать новый набор и передать это по дереву.
Я как бы потерял, как разбирать строку, содержащую выражение. После некоторого раздумья кажется, что "дальше" из одного из подвыражений, чем выше он должен быть в моем дереве s-expression? Я думаю, что если бы я мог просто нажать в правильном направлении, чтобы разобрать и вставить выражения в дерево, я должен быть в порядке.
Мое дерево образцов, которое я придумал для запроса выше, выглядит примерно так:
&
/ \
| water
/ \
& &
/ \ / \
fire forest ocean boat
Это имеет смысл, поскольку огонь возвратит набор строк, которые содержат огонь и лес, возвратит набор линий, в которых все будут содержать лес. Затем на "&" уровень я взял бы эти два набора и создал бы другой набор, содержащий только строки, которые были в обоих наборах, тем самым давая мне набор, который имеет только строки, которые содержат как огонь, так и лес.
Еще один камень преткновения - как представить все в дереве после преодоления барьера синтаксического разбора. У меня есть класс ExpTreeNode, который будет служить узлом для моего ExpTree (BST), а затем у меня есть 2 подкласса, оператор и операнд, но я не уверен, что это хороший подход.