At 9:29 AM +0200 4/17/00, Loic Dachary wrote:
> I recently implemented a search algorithm (in the current mifluz package
>from CVS file mifluz/test/search.cc) and found that it was convinient that
I'll take a look. I'm not entirely sure you really want all the
WordList methods in a ParseTree though. I can see that you might want
the interior data (e.g. word records) available as a WordList. But I
don't see when you would want the entire tree to look this way.
I mean, as I'm envisioning it, the ParseTree will hold not only the
WordReferences (temporarily), but the lists of results. This way the
class could cache either set (or both), either the individual
queries, or up at the top of the tree, the entire user query.
> Instead of building a binary syntax tree (each node has a left/right child)
>I also find it a lot more convinient to build a N-ary tree. For instance
>a Or node has N children and the query:
Yeah, I think you're right here. This will cut down on the number of
"extra" interior nodes. It certainly makes parsing easier.
--
-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
