Re: One more question on TSTs
From: Bonj (Bonj_at_discussions.microsoft.com)
Date: 10/05/04
- Next message: Tom Widmer: "Re: IsTextUnicode and Windows 98"
- Previous message: Alexander Grigoriev: "Re: IsTextUnicode and Windows 98"
- In reply to: Carl Daniel [VC++ MVP]: "Re: One more question on TSTs"
- Next in thread: Igor Tandetnik: "Re: One more question on TSTs"
- Reply: Igor Tandetnik: "Re: One more question on TSTs"
- Reply: Alexander Nickolov: "Re: One more question on TSTs"
- Reply: Bonj: "Re: One more question on TSTs"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 5 Oct 2004 09:19:01 -0700
> You'd store something in the data of each node that identifies it as a legal
> end-node. For example, store your keyword classifier value in all potential
> end-nodes, and -1 in all others. Of course, all leaf nodes are end-nodes.
Right, got that bit. The bit I'm still a bit muddy on is how to decide
whether the 'incoming' (i.e. in-parameter) string that's finding its way
through the tree should *use* this end-node (if it exists), or make another
comparison. For instance, if "sp_helpindex" was the 'incoming' string, then
the node that it wants to get to (its target) is the "sp_helpindex" node. It
will go via the "sp_help" node, but will somehow have to choose to make
another comparison and go down the route towards the node for "sp_helpindex",
rather than stop at "sp_help".
Further, "sp_help" will also have to go via the "sp_help" node, but will
have to stop there.
"sp_helpgobbledegook" will have to go via "sp_help" aswell, but will have to
take the decision to make another comparison with its 'g' character, and then
fall out.
My current thinking is to also pass in the length of the string aswell
(which will be known in the calling algorithm anyway) and make it so each
node knows how long a string must be to stop at it. I'm pretty sure this will
work, although I haven't got the algorithm written yet, I like to have a
clear path for the alrogithm worked out before I write it, as I program best
when I program fast!
>
> If the data in your tree is dynamically allocated (I wouldn't think it would
> be in your case), then you could simply store null for non-end nodes.
That's the other bit I really want to know. How can I construct an algorithm
that contains word nodes like this, but *isn't* dynamically generated? The
only way I can think how I'm going to do it at the moment is if I have a
'node' class (or struct). Which means populating it at runtime. Which means
loading the data when the program starts. Is there another way?
>
> -cd
>
> PS: I'm glad you stuck with it!
Cheers! I always find it's best when you do. The only thing that puts me off
is "this'll be useless", I'm never put off by "it'll never work" - because if
anybody can get it to work, there's no reason why I can't. And this is
something that I actually *want* as a product to use in my own day to day
work, so it can't possibly be pointless. Otherwise, if I can't see myself
using it, I couldn't possibly have the motivation to have even started it! I
think the best programs are the ones that you actually specify yourself and
write for yourself...
BTW cheers for the help on the RICHEDIT by the way, I think I've finally
mastered that (although I shouldn't speak too soon...)
> I was going to put together a small TST
> demo to post here, but just haven't had the time.
Let me know if/ when you do...
Cheers
>
>
>
>
- Next message: Tom Widmer: "Re: IsTextUnicode and Windows 98"
- Previous message: Alexander Grigoriev: "Re: IsTextUnicode and Windows 98"
- In reply to: Carl Daniel [VC++ MVP]: "Re: One more question on TSTs"
- Next in thread: Igor Tandetnik: "Re: One more question on TSTs"
- Reply: Igor Tandetnik: "Re: One more question on TSTs"
- Reply: Alexander Nickolov: "Re: One more question on TSTs"
- Reply: Bonj: "Re: One more question on TSTs"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|