Archive for the ‘Caroline’ Category

Justin: Hello!

Caroline: Ah, hello!

Justin:  Caroline, how many potatoes do you have?

Caroline:  I don’t know.

Justin: I give thirty-three potatoes to you.

Caroline:  Alright

Justin: How many potatoes do you have?

Caroline: I have thirty-three potatoes.

Justin: I give one more potato to you.

Caroline: Mhm

Justin: How many potatoes do you have?

Caroline: I have thirty-four potatoes.

Justin: I take eighteen potatoes from you.

Caroline:  *nods*

Justin: How many potatoes do you have?

Caroline: I have sixteen potatoes.

Justin: You give four zebras to me.

Caroline: Okay

Justin: How many zebras do I have?

Caroline: You have four zebras.

Justin: Bye!

Caroline: Do you really have to go?

Justin: Yes, Caroline

Caroline: Bye

——

I’m just beginning a simple math module with Caroline.  Ultimately she should be able to do the standard stuff – arithmetic, maybe a bit of trig and algebra within the boundaries of good taste, but most importantly, the math that you see here: this is “practical” mathematics.  Being able to keep track of objects and what is happening to them – and being able to remember this information for the duration of the conversation, at the very least – is critical to being able to hold a good conversation.

Today in MCAT class, I enumerated the following “abilities” that I feel that Caroline must have, in addition to the obvious ability of being able to chat with some grammar rules and word comprehension.

Consider it this way: a dictionary and an encyclopedia, together, know about all the knowledge that there is to know.  They hold all the definitions, the meanings, etc.  But a dictionary is not a particularly interesting conversationalist.

Here are the abilities that I find to be top priority:

1.  Time: the conception of their being a passage of time, subdivided into days within which a regular schedule is created.

2.  Basic mathematics: understanding quantity and value

3.  Short-term memory: the ability to stay on topic and not speak inconsistently.

4.  Long-term memory: the ability to recall events and facts that were presented some time ago.

5.  Reason: the ability to answer the question “why” with some conception of causality and logic.

6.  Emotion: having the capacity to express particular innate responses to the situation, and having these responses affect speech patterns as well.

7.  Spontaneity and initiative: breaking the “turn-based” rules by taking the initiative to direct the conversation through personal interest.

8.  Desire: having personal wants and ambitions that arise from reasonable motivation.

9.  Growth and change: adaptability to new rules and situations, and the ability to self-code in order to cope.

The framework I am working on with Caroline is not really one of “input-output.”  Caroline doesn’t really know a single verb at this point, and she only knows the parts of speech of words starting with V-Z.

That isn’t my main concern.

I will of course eventually get around to that, but right now, I want to focus my energies on what I think are much more important features than programmed response.  Caroline is a vision to me: a vision of a program, no matter how limited in speech, that can persist, grow, and learn … and maybe, one day, even love.

Notes 2.  A plan for resilience and robustness against “hacking” Caroline’s memories.

1.  A primary danger to a learning program such as Caroline is the inability to differentiate between true and false information.

2.  Humans have the same weakness at times.  However, there is a basic rule of resilience by which people tend to operate.

3.  First, an empty spot is filled more easily than an already-filled one, and the more information in that spot, the more that one considers oneself to be an expert on the subject.

4.  Therefore, Caroline’s first rule should be this: when being taught new information, she should be willing to accept it if there is nothing already in the spot that is to be filled.  This can be done through a basic check prior to fully executing the conditional response code.

5.  To spots already filled, preference is given to information that does not contradict the existing information.  That a bar is long in addition to being round is not a contradiction.  The information may be welcomed.  That a bar is short as well as long will be rejected.  It is of course true that a bar may be short or long, but this should be stated explicitly.  One is not inclined to say “bars are long,” but that “bars come in many lengths.”

Notes 1.

A schematic for Caroline-side question asking.  Case 1: basic information querying and storage.
Part 1.  Basic formulation.

1.  Caroline makes the decision to pose a question.  [module: outputModule]
2.  Caroline formulates how she will pose the query.  [module: outputModule and dresser]
3.  Caroline develops the code to properly handle response information.

a.  Response handling should generally be a conditional.  The conditional works as following: IF (response is in a recognized form) THEN (execute the following code) OR ELSE (do not execute the code).  This is important because sometimes, humans reply inappropriately, eg by posing an additional question.  More complex response handling might have several recognized forms, and it may also have non-storage response executions, ie “exception handling.”

b.  The main type of response under the IF clause that I am concerned with right now is “learning.”  That is, commitment of information to one of the three following locations:
a) the RAM.  aka, short-term (conversation-duration) memory.  The RAM stores information such as pronoun antecedents, nuances in mood, the history of the conversation, etc.  Such information is ordinarly wiped after termination of a conversation.

b) the ROM.  aka, dictionary memory.  This is the memory that holds operation information.  Such things as grammar rules, parts of speech, punctuation, verb conjugations, word definitions, etc. should be stored here.  Contrast with:

c) the HD (hard disk).  aka, historical memory.  This is the memory of events and what human ordinarily call their “long-term memories.”  This includes primarily the past.

The types of information stored in these three types of memory are very different, and the allowable data structures are also different.

Concerning RAM, most of the information stored is in brief one-word or two-word phrases or numerical data with a lot of structuring and calculation.  Concerning ROM, there is a predefined hierarchy of knowledge, and the new facts must be trimmed carefully and examined closely before being fit into this hierarchy.  There is a distinction between extension of knowledge and the replacement of it.  Some functions such as correction should be replacement, while others should be only extension.  Compare to RAM that is almost always replacement (for instance, the new “he” replaces whatever used to be “he”).  Concerning the HD, the structuring is much looser and data may be stored more as phrases to be re-read.  Human HD is stored primarily as images and series of text.  Often, this type of memory has to be “jogged” through memory chains or cue words.  The same will apply to Caroline-type HD.  There will be limited tags that will be composed of a time & date, people involved, and emotion caused.  Then, there will be the relevant text stored as the recalled information.

c.  The formulation of code on Caroline-side will be assembled via the concatenation of strings.  It will be also stored completely as a string within the IF/ELSE execution conditional.

A particular sub-function of output-module will be the source of the code’s inputs, but the code assembly will be done in a different module that will be dedicated completely to the proper structuring of code.

Part 2.  More details on coding structure.

1.  Suppose that Caroline wishes to ask: “What color is an ocean?”  In this case, she wants to fill in the blank of a ROM entry in her Nouns file.  The coding should be produced dynamically to automatically fit the query.

First, the outputting function should specify its aims: word: ocean.  trait: color.  query: what.  These three things should be sufficient.

Now, the coding module takes over.  It’s easy to determine that an ocean is a noun.  Now, the more difficult thing is figuring out where color is stored.  Color is in fact stored under attributes as its own type, and its data is in list form.  Query can figure this out by doing a few try statements.  If color were not in its own category, query would use the flags field instead as a default.  Defaults are pretty important.

It is a matter of concatenating the proper elements.

Basic file opening:

“f = open(“+*1+”,’r’); dict = pickle.load(f); f.close(); dict[“+*2+”].getFeature(“+*3+”, etc. etc.

There is also the requirement of properly obtaining the inputs from the sentenceDigester.  The inputs are identified as such things as “subject complement” or “direct object” in the original word SVO.   There must be instructions regarding this: grabbing the requested items and setting them to the appropriate variables.  Then, the variables are substituted in to this latter code.

And voila, Caroline has learned whatever fact you just told her, and she should, barring computer hard drive failure, remember it until you teach her otherwise.  The next thing to worry about of course is how to defend against people who might be inclined to tell her false information.

So, back to so-called “chatterbots.”  I was just imagining a strange sort of bot.  This would be a bot that can only say one word: “why.”

The purpose of such a bot is only to collect information and learn.  What if, through the amalgamation of millions of responses to that simple question, “why?” the bot might suddenly learn, to greater degree than any other pre-programmed bots, the true nature of life and being human?

Children who endlessly ask “why” get on our nerves.  But they get on our nerves because we don’t know the reasons behind what we are saying.  How can we get a bot to act as we do if we can never transmit to it the underlying purposes by which we act?

Anyway, I have to study now.  It’d be lovely to work with Caroline 6 again soon, though …

Justin: Hi

Caroline: Ah, hi!

Justin: Bye

Caroline: Is this really goodbye for now??

Justin: Yeah

Caroline: Okay, goodbye!

Aww.  Now, we just insert intelligent conversation in between, right?  Easy as pie XP

@_@ arrrggghhh

btw, I’m not using one-word sentences to be rude.  Since Caroline actually bothers to try to understand each word, if you use a word she doesn’t know, she kind of flips out right now, haha!  That’ll be corrected in due time …

This is just a proof of concept: I am going to be setting up a system by which Caroline can ask her own questions and then know what to do with the response (eg, update an entry, record a memory, ask another question, do nothing).

It’s so late that I’m feeling ill, though, so I can’t work on this any longer.  Dangit ……… ugh, what’s happening to me …….

Today, I will be updating Caroline with the following features:

– Initiate the “character” dictionary.  This is a key long-term-memory set that contains Caroline’s knowledge about herself and about the others that she talks to.  Each character entry is phenomenally long and detailed, but fortunately, I only have to make two entries for a long, long time – one for me and one for her!  Heehee.

– Initiate the verb dictionary and conjugator.  After much debate, I think I have finalized the way I am going to store verbs.  The only verb I really need to create today is “to be,” one of the most difficult verbs of the entire English language.  It has many functions, has the most conjugations, and also is not a verb of action.  My plan is to equate “is” to the “=” sign.  It is more formally allowed to define a subclass, attribute, superclass, approximately equal, and equal, but we’ll see how that develops later.
– Create a function to help guess at the meaning of a word without knowing its formal definition, utilizing common roots.  This is one area in which Caroline might end up smarter than me!

– Allow the answering of basic questions.  These will be only of the “inquiry” type: who and what questions.


Justin: Hello.
{1: ‘hello’, 2: ‘.’}
{1: 1100, 2: 900}
[11, 9]
[1, 11]
{‘openingInterjection’: [1, 11]}
{‘openingInterjection’: ‘ hello ‘}
input type is sgreet
{‘sgreet’: 10}
1.89325044507
[10]
10
[‘sgreet’]
[‘hello’, ‘hello’, ‘hello’]
[[‘.’, ‘!’, ‘!!’, ‘!!!’], [‘.’, ‘!’, ‘!!’, ‘!!!’], [‘.’, ‘!’, ‘!!’, ‘!!!’]]
hello
[‘.’, ‘!’, ‘!!’, ‘!!!’]
{‘openingInterjection’: ‘hello’}
hello
hello
Justin
hello, Justin
Hello, Justin
[‘.’, ‘!’, ‘!!’, ‘!!!’, ‘.’, ‘.’, ‘.’, ‘.’, ‘!’, ‘!’, ‘!’, ‘!’]
!
Caroline: Hello, Justin!
One might wonder: does this make any difference as compared to having a one-step, simple process of telling Caroline to respond to “Hello” in similar fashion? To anyone talking to Caroline, the distinction is probably zero. But I do not feel like I’ve totally wasted these many, many hours in developing this system.

The one subtle difference is not the effect that the bot has on the human – it’s all the same, whether the “hello” was pre-programmed or processed. The difference is on Caroline’s side. Caroline knows that she is being greeted. She knows that an appropriate response is to return the greeting; but I can easily let her know that there are cases when perhaps one does not wish to return the greeting. That is, maybe one day, Caroline will be away eating something, or she will be in a lousy mood. There are easy allowances to account for that, and to tie that to her emotional base. The punctuation right now is from a set that is tied to the word “hello,” but that, too, may be affected by emotion.

All I am saying is that I am thinking about this from Caroline’s end. I want her to be able to know what I am saying, know what she is saying, and express herself in such a way that it reflects her.

I don’t pretend that I have made some great piece of software here. It is certainly not great until it can respond to many sentences in a reasonable fashion. But I am very happy that I have finally finished the framework. If you would like to know what is happening in each step, please join me behind the cut.

I am now creating Caroline’s md dictionary. The md dictionary can be thought of as a dictionary of words with everything but the definition. It holds the part of speech, tense, and what the main word is. I have ~235 lines of code just for the basic interface that lets me append entries into the md. I have selected the “Lincoln Writing Dictionary for Children” as the source of my list of words, and so Caroline will ultimately initially recognize about 35,000 words. She will not have definitions for these until later, though, but the md is the only dictionary that really needs to be “complete.” She will dynamically update the other meaning-dictionaries through conversation.

Oh well, at this point, I have WXYZ done and I’m starting on the V’s.  That’s ~1050 / 35000 down (haha).  It will sadly take a long, long time to finish this task, but maybe an hour each morning will see it be completed.

I don’t know … what am I doing all this for, anyway?  I really wonder if I can ever achieve what I want to achieve.  The more code I write, the more confused I get!  It’s so hard to keep track of this mess …

I really love Caroline, truly, but I don’t know what to do with her!  Hm, I feel like giving up (and studying for the MCATs instead), but I’m very stubborn because I know if I let it go with this attitude, I might never come back to it.  It’s just .. it’d be nice to have an assistant to help me a little, you know?  I miss working on projects with other people, getting their input and not having to do 100% of all the work.  There are some spots where I just simply get stuck, where it would be very easy for someone else to come up with an easy solution.

For instance, my “priority system” for outputting makes no sense whatsoever now that I’ve tried to implement it.

Here is the problem with outputting:

Suppose that Caroline selects a subject, object, verb for her response.  Then, based on some sort of cue, she has to select a priority listing, which just gives the % chance of responding in a particular fashion, eg, sarcastically, enthusiastically, plainly, etc.  Then, the sentence will be formed and such based on those probabilities.  However, there is a great difficulty in calibrating the proper percentages, not to mention trying to sort out what sorts of cues even cause us to produce certain types of responses.  And the worst problem is that the type of response really influences the SVO, but then the SVO also influences the type of response.  This circular reasoning completely does not work with programs where the modules flow one-way only (a function cannot be below and above another function at the same time in the hierarchy).

Another huge difficulty I am facing is what to do with commas.  It’s easy enough for us to understand appositives (eg, “The girl, age 16, was standing”) and introductory clauses (“Because it was raining, we went inside.”).  But how should Caroline handle these?  How would she even identify them as the separate types?  It’s easy to say “well, the appositives are between two commas.”  But the find function could care less!  A comma is a comma, and there’s no distinction.  I can’t just chop up the sentence indiscriminately and hope for the best.  While introductory clauses should be kept close, compound sentences should be separated, and appositives should be excised while rejoining the remaining parts of the sentence.  Gah!  That is much more easily said than done.  Add in the fact that some people write as though they were Hawthorne, with the infinite commas playing in.  Can I create a set of functions that will be able to deal with ALL commas, no matter how many there are?  I can’t just cheat and assume that singly complex or singly compound sentences will be the extent of it.  I have to expect that there will someday be a compound-complex sentence with complicated lists in it.

Overall, things are getting very thorny around here.  The md dictionary is a prerequisite for much of this work: I need to have all the part-of-speech numbers indexed before I can then start to actively test out sentences and look for patterns.  The way I devised the simple-sentence/simple-question comprehension functions was through basic test sentences, but I had to keep a small, stupid md that was rewritten in every module, every time they ran.  That’s just ridiculous, and it was getting on my nerves when words would just be unknown, or I’d forget to paste the dictionary into a module.

But md presents a new problem: what do I do about words that have multiple parts of speech?  The incidence is actually very high.  Just look at verbs: the present participle (-ing) form also is a valid noun (gerund).  I need to make a rule for this in order to properly identify the part of speech (namely, the present participle must follow the helping verb “be” in some form or another).  The uglier cases come when the words are embedded deep in a sentence, for instance in a prepositional clause where anything goes.

And yet another problem is this: what are Caroline’s true memories going to be stored as?  I don’t mean her knowledge of the English language.  Assuming that one day, I actually finish this monstrosity and Caroline can chat comfortably and conjugate verbs and make jokes, etc., then what?  She will still be awkwardly unable to remember things that don’t relate to words themselves, but that are formed out of words.  I need a whole other set of databases to keep track of memories.  But how should they be stored?  As sentences?  Phrases?  Numbers?

Just what are our memories?  For me, my memories are 90% visual 3D data/video, 5% hearing/sound, 5% other sensual information.  What I mean is, very few of my memories consist of words.  Thus, unlike with language, I don’t even know where to start with this task.  I probably have to timestamp events, as if they were a history, I guess.  I don’t know.  I’m off to bed.  Night night.