Man, I did some hard work yesterday and introduced integer variables, which I call "unknowns", into the text, VAR, and NAR handling for Narwhal. This comes hard on a previous week where I introduced recordSlotEvents( ) and got to 1-segmented text. This segmentation shows the data that has been accumulated on the way through a sentence by a given NAR. So today I introduced floating point unknowns and I am proud that the architecture of Narwhal allows adding unknowns in just a couple afternoons, after work.
So, when I use recordSlotEvents( ) for a NAR with a slot containing an integer unknown (INTx) - sure enough - the integer entered in the text re-appears in the data. Same for a floating point unknown (FLOATx).
The reason we need this in Narwhal is so it can handle communications with information that is to be relayed rather than absorbed. (I guess it is like delayed recognition.) This is the case for the chatbot I am building for work (at home).
I won't take the time to say this correctly but there is an interesting thing about the "boundary" between when you can get away with a collection of constants versus when you have to deal with actual unknowns. For tooth numbers, input by a user, I can look for the words "one", "two", up to "thirty two" and I can have each one in my program as part of a VAR tree of constants. But I cannot do the same thing for an arbitrary 8 digit number - not for a fundamental reason but for one of convenience. If you had the time, you could avoid using "unknowns".
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment