Slides for Chapter 10
Note to Instructors
This Keynote document contains the slides for “Ask Dr. Ruby”, Chapter 10 of Explorations in
Computing: An Introduction to Computer Science.
The book invites students to explore ideas in computer science through interactive tutorials where
they type expressions in Ruby and immediately see the results, either in a terminal window or a 2D
graphics window.
Instructors are strongly encouraged to have a Ruby session running concurrently with Keynote
in order to give live demonstrations of the Ruby code shown on the slides.
License
The slides in this Keynote document are based on copyrighted material from Explorations in
Computing: An Introduction to Computer Science, by John S. Conery.
These slides are provided free of charge to instructors who are using the textbook for their courses.
Instructors may alter the slides for use in their own courses, including but not limited to: adding new
slides, altering the wording or images found on these slides, or deleting slides.
Instructors may distribute printed copies of the slides, either in hard copy or as electronic copies in
PDF form, provided the copyright notice below is reproduced on the first slide.
© 2012 John S. Conery
Ask Dr. Ruby
A program that understands English (or does it?)
✦
Overview of ELIZA
✦
Sentence Patterns
✦
Building Responses
✦
Substitutions
✦
An Algorithm for Having a
Conversation
✦
Writing Scripts for ELIZA
✦
ELIZA and the Turing Test
Explorations in Computing
© 2012 John S. Conery
The Turing Test
✦
British mathematician Alan Turing was one of the founders of modern
computer science
✦
He wrote a paper in 1950 titled “Computing Machinery and Intelligence”
❖
✦
what would it mean for a computer to be called “intelligent” ?
What is now called the Turing Test:
❖
connect a terminal to a person in one room and a computer in a different room
❖
a user is allowed to type questions on the terminal and send them to either room
Room #1
User
Room #2
The Turing Test
✦
✦
Think of the test as a game with three players
❖
Player A is a person typing questions on the terminal -- they win if they correctly guess
which room has the computer
❖
Player B is the human in one of the rooms -- try to prevent the computer from winning
❖
Player C is the computer -- it wins if it can fool A into thinking it is a human
C passes the Turing Test if it wins the game
❖
claim: it would have to have a fairly high degree of “artificial intelligence” to win....
Player B
Player A
Player C
Chatbots
✦
For over 50 years the Turing Test was
simply an intellectual exercise
✦
In the last few years “chatbots” have
appeared on the Internet
❖
generate spam and other advertising
in chat rooms and instant messaging sites
✦
Some chatbots identify messages as
being automatically generated
✦
Malicious ‘bots try to fool people
❖
entice them away to join other chat rooms
❖
send credit card or other bank information
❖
“419” scams
‣
“Dearest, my husband died and
left millions of dollars....”
jabberwacky.com
ELIZA
✦
One of the first programs to attempt to carry on a conversation was named
ELIZA
❖
✦
written by Joseph Weizenbaum at MIT in 1966
Applied simple “transformation rules” to create a response to each
sentence typed by a user
H:
My father wouldn’t buy me a puppy.
C:
Tell me more about your family.
In these slides H and C indicate strings typed by the
(human) user and the computer’s response
✦
The program does not need to know about parents, kids, pets, buying
things, or anything else implied by the input sentence
❖
just respond to any sentence with the word “father” by “tell me more....”
The ELIZA Effect
✦
Weizenbaum was amazed at how involved people got in their
“conversations” with ELIZA
✦
Computer Power and Human Reason, published in 1976, includes several
anecdotes
✦
❖
even when people knew they were talking to a computer they would open up and type
very personal details
❖
people often refused to give him transcripts, saying they were “private communications”
Weizenbaum compared using ELIZA to going to the theater
❖
“willing suspension of disbelief”
❖
we know people on the stage are actors, but we are drawn in and think of the characters
as real people
ELIZA Scripts
✦
The name “ELIZA” comes from the character
Eliza Doolittle in G B Shaw’s Pygmalion
✦
ELIZA the program has no built-in knowledge
✦
❖
the rules for transforming sentences are defined
in a script
❖
the more rules there are in a script, the better the
program (presumably) becomes at carrying on
a conversation
❖
there can be different scripts for different situations
A script designed to act like a psychotherapist
would have rules that react to sentences with
words like “sad”, “depressed”, “dream”, etc
My Fair Lady (play and
movie) was based on
Pygmalion
The Eliza Module
✦
The implementation of ELIZA that we will
use for projects in this chapter is a Ruby
module
❖
✦
Modules are like classes
❖
✦
the module is named ElizaLab
a collection of related methods
To call a method in a module, put the
name of the module in front of the
method name
❖
call Eliza.info to see information
about the script currently being used
❖
call Eliza.run to start a conversation
The Eliza Module
✦
When ElizaLab is first loaded there is
no script
✦
It’s possible to start a conversation,
but the results are pretty boring
>> include ElizaLab
=> Object
>> Eliza.run
H: Hi there
C: Hi there
H: Stop repeating what I say
With no script all input
sentences are simply echoed
C: Stop repeating what I say
H: Mom!!! Eliza is making fun of me!
C: Mom!!! Eliza is making fun of me
H: quit
=> nil
[ Live Demo ]
Doctor
✦
The script we will use for our project
is named Doctor
❖
✦
it is based on the script Weizenbaum
first wrote for ELIZA in 1966
Use the load method in the Eliza
module to load a script file
Doctor
>> Eliza.load :doctor
=> true
>> Eliza.run
A symbol (e.g. :doctor) refers to a
script in ElizaLab
How do you do. Please tell me your problem.
H:
A string (e.g. “doctor.txt”) refers
to a file in your project directory
[ Live Demo ]
Doctor
✦
The Doctor script is a set of rules that
play the role of a Rogerian psychotherapist
❖
the doctor urges the patient to talk
about what is bothering them
✦
The simplest responses are statements like
“tell me more” or “go on”
✦
Slightly more complicated responses use
part of the patient’s sentence
H: I need a hug.
C: Why do you need a hug?
H: I need a new drug.
C: Why do you need a new drug?
A Session with the Doctor
>> Eliza.run
How do you do. Please tell me your problem.
H: I had a dream about cows.
C: What does that dream suggest to you?
H: I think it means I am afraid of them.
C: Is it because you are afraid of them that you came to me?
H: Yes.
C: You seem quite positive.
H: Cows terrify me.
C: I am not sure I understand you fully.
H: I can't go past a farm without breaking out in sweat.
C: How do you know you can't go past a farm without breaking out in
sweat?
A Session with the Doctor
✦
A session can quickly degenerate...
H: Do you have a recipe for eggplant parmigiana?
C: Oh, I have a recipe for eggplant parmigiana?
H: You're a cooking expert, aren't you?
C: You're not really talking about me, are you?
H: Yes.
C: You are sure?
H: I thought I was talking to a chef.
C: That's quite interesting.
H: Are you a computer?
C: Why do you mention computers?
Getting Information About a Script
✦
For a conversation to be realistic the user needs to enter sentences that
have words the script reacts to
✦
To get information about the current script:
>> Eliza.info
Script: ./../data/eliza/doctor.txt
28 rules with 51 sentence patterns
78 key words: alike, always, am, are, because, believe, better,
brother, can, cannot, certainly, child, children, computer,
computers, dad, depressed, deutsch, do, dream, dreamed, dreams,
dreamt, elated, ...
Pattern Objects
✦
To make it easier to write scripts ElizaLab defines a new type of object
called a Pattern
❖
✦
✦
think of a Pattern as an association between a word in an input sentence and the
responses Eliza should make
The two parts that define the association are
❖
a word or set of words that need to be in the sentence
❖
one or more output strings that define the responses
Example: a pattern that responds to sentences about cows:
p = Pattern.new( "cow" )
Pattern Objects (cont’d)
✦
Example:
>> p = Pattern.new( "cow" )
=> cow: []
✦
The empty list means there are no responses yet. Call a method named
add_response to add sentences:
>> p.add_response("Tell me more about your farm")
>> p.add_response("Why do you mention your farm?")
✦
Now when you ask for the value of p you can see there are two possible
replies to sentences containing the word “cow”
>> p
=> cow: ["Tell me more about your farm",
"Why do you mention your farm?"]
Applying a Pattern
✦
After you make a Pattern object you can apply it to sentences
>> p.apply("Our cow slept in the barn")
=> "Tell me more about your farm"
>> p.apply("He had a cow")
=> "Why do you mention your farm?"
Note the Pattern object
cycles through the
responses
>> p.apply("The cow jumped over the moon")
=> "Tell me more about your farm"
✦
If a sentence does not contain the key word the apply method returns nil
>> p.apply("We had a pig, too")
=> nil
Pattern Matching
✦
The easiest way to implement the apply method is to simply have it call
include?
>> s = "The cow jumped over the moon"
>> s.include?("cow")
=> true
>> s.include?("pig")
=> false
✦
But there’s a problem:
>> t = "The cat was scowling"
>> t.include?("cow")
=> true
Regular Expressions
✦
Ruby has a special type of object to use for pattern-based string matching
✦
A regular expression is a string that describes a pattern
❖
✦
in Ruby a regular expression is a string surrounded by / characters instead of quote
marks
A pattern can have letters:
/cow/
✦
A pattern that only matches
sentences with “cow”
It can also have symbols with special meaning
❖
example: the vertical bar means “or”
/cow|pig|horse/
Matches sentences with
“cow”, “pig”, or “horse”
Regular Expressions (cont’d)
✦
A method named match will see if a string matches the pattern described
by a regular expression
>> s1 = "The cow jumped over the moon"
>> s2 = "We had a pig, too"
>> s3 = "The goat was in the pen"
>> s1.match(/cow|pig|horse/)
=> #<MatchData "cow">
>> s2.match(/cow|pig|horse/)
=> #<MatchData "pig">
A MatchData object holds the
results from a successful
pattern match
>> s3.match(/cow|pig|horse/)
=> nil
nil means the match failed
Meta-Symbols
✦
✦
Symbols like | that have a special meaning in a regular expression are
called meta-symbols
❖
they help make a description of what to find
❖
they are not symbols expected to be found in the sentence
There are dozens of special symbols and constructs, e.g.
❖
match any character
❖
match a digit
>> ssn = /\d{3}-\d{2}-\d{4}/
\d is the meta-symbol for “digit”
>> s5 = "His SSN is 123-45-6789"
\d{3} means “three digits in a row”
>> s5.match(ssn)
=> #<MatchData "123-45-6789">
Meta-Symbols (cont’d)
✦
One very useful meta-symbol tells Ruby that a character must occur at a
word boundary
✦
This symbol would let us make a pattern that matches “cow” but not “scowl”
❖
✦
put the meta-symbols on either side of the letters “cow”
The Pattern class automatically adds the word boundary markers
>> p = Pattern.new( "cow" )
>> p.regexp
you supply a word to
use in a pattern
=> /\bcow\b/i
>> p.apply("The cow jumped over the moon")
=> "Why do you mention your farm?"
>> p.apply("The cat was scowling")
=> nil
the Pattern class
converts it into a regular
expression
Recap
✦
Summary of what we’ve seen so far:
❖
Eliza is a program that uses a script to
reply to input sentences
❖
we will use Pattern objects to generate
replies
❖
to make a Pattern that will do something
with sentences containing word w:
p = Pattern.new(w)
❖
to use p to get a response to an input
sentence s:
p.apply(s)
Pattern objects automatically turn
words into regular expressions
Groups
✦
In Ruby a set of words separated by vertical bars is called a group
✦
When the apply method compares its pattern to an input sentence, it saves
the word that matches a group
✦
❖
words are saved in a placeholder variable
❖
we can use these variables in response strings
Example:
>> p = Pattern.new("cow|pig|horse")
>> p.add_response("You had a $1?")
>> p.apply("The cow slept in the barn")
=> "You had a cow?"
>> p.apply("The horse jumped over the fence")
=> "You had a horse?"
a placeholder
Fill in the Blanks
✦
Placeholders are exactly what we need to make sentence patterns for Eliza
✦
The idea is to make a Pattern object that describes a “template”
Pattern: “I don’t _____”
Response: “Why don’t you _____ ?”
✦
Pattern: “I need _____”
Response: “Why do you want _____ ?”
The apply method will use pieces of the input sentence to fill in the blanks
>> p.apply("I need a hug")
$1: a hug
=> "Why do you want a hug?"
Why do you want $1?
>> p.apply("I need a new drug")
=> "Why do you want a new drug?"
$1: a new drug
Why do you want $1?
Wild Cards
✦
The pattern that saves a group of words in a placeholder uses a wild card
✦
In a pattern the symbols .* mean “any number of words fit here”
>> p = Pattern.new("I need .*")
=> I need (.*): []
✦
Since the piece of the input sentence that matches a wild card are saved in
a placeholder, the response can include placeholder variables
>> p.add_response("Why do you want $1?")
>> p.apply("I need a cup of coffee")
=> "Why do you want a cup of coffee?"
$1: a cup of coffee
Ambiguity in Groups
✦
There can be any number of groups and wild cards in a pattern
✦
But if we can have more than one group, how does Ruby know where one
group stops and the next one starts?
✦
Does this pattern have one group or two?
>> q = Pattern.new("gerbil|guinea pig|horse")
✦
What do you think will happen here?
>> q.add_response("A $1?")
>> q.apply("He bought a pig")
=> nil
>> q.apply("He bought a guinea pig")
=> "A guinea pig?"
Ruby thinks this is all
one big group
Resolving Ambiguity
✦
If you want your pattern to have two groups, use parentheses to surround
each group
>> q = Pattern.new("I (love|adore) my (cat|dog|ducks)")
>> q.add_response("You $1 your $2?")
>> q.apply("I adore my cat")
Two groups, two placeholders
=> "You adore your cat?"
>> q.apply("I love my ducks")
=> "You love your ducks?"
✦
These parentheses are just like parentheses in an arithmetic expression
❖they
alter the precedence of the pattern matching algorithm
❖parentheses
are meta-symbols: they tell Ruby how to do the pattern matching, instead of
characters Ruby looks for in the input
What would this pattern match if the
parentheses were left out of the string?
Recap II
✦
Simple patterns just have single words
or groups of words to find in a sentence
(cow|pig|horse)
✦
Patterns can also have wild cards to
match more than one word
I need .*
✦
✦
Parts of the input that match a group
or a wild card are saved in placeholders
Response strings can use placeholder
variables
“Why do you want $1?”
❖the
value of a placeholder is used to
fill in the blanks in the response
Pattern: “I need _____”
Response: “Why do you want _____ ?”
A Problem with Placeholders
✦
There is something funny about some of these responses:
>> p = Pattern.new("I like .*")
>> p.add_response("Do you really like $1?")
>> p.apply("I like crossword puzzles")
=> "Do you really like crossword puzzles?"
>> p.apply("I like your hat")
=> "Do you really like your hat?"
>> p.apply("I like my new computer")
=> "Do you really like my new computer?"
What do the unrealistic responses have in
common?
Personal Pronouns
✦
Our sample pattern doesn’t do a very good job with this sentence:
>> p = Pattern.new("I need .*")
>> p.add_response("Why do you need $1?")
>> p.apply("I need to take my pills")
=> "Why do you need to take my pills?"
✦
English speakers typically change first person pronouns to second, and
vice versa
I ⇆ you
me ⇆ you
my ⇆ your
Why do you need to
take your pills?
Postprocessing
✦
This sort of thing is easily fixed by postprocessing
❖
create a “dictionary” that contains words to change
❖
after a match, scan each placeholder variable
❖
replace each word in the dictionary by an associated word
>> p.apply("I need to take my pills")
=> "Why do you need to take your pills?"
/I need .*/
$1:
to take my pills
$1:
to take your pills
“my” => “your”
Why do you need $1?
Associative Arrays
✦
Ruby makes it easy to implement the dictionary as an associative array
✦
The object is usually called a “hash”
✦
❖
a set of key-value pairs enclosed in braces
❖
any number of pairs can be given, separated by commas
The words to replace during postprocessing are in an object named post:
>> Eliza.post
=> {"yourself"=>"myself", "my"=>"your", "am"=>"are", ...}
Associations don’t have
to be pronouns....
Eliza.post
✦
To look up a word in this “dictionary” just use the usual indexing operator
>> Eliza.post["my"]
=> "your"
>> Eliza.post["you"]
=> "I"
>> Eliza.post["we"]
=> nil
✦
The index operator can also be used to add words to the dictionary:
>> Eliza.post["we"] = "you"
=> "you"
Preprocessing
✦
Another “cut-and-paste” operation takes place before Eliza looks for
patterns to apply
❖
✦
a preprocessing phase is used to expand contractions
Example:
>> p = Pattern.new("I won't .*")
>> p.add_response("Why won't you $1?")
>> p.apply("I won't do it")
=> "Why won't you do it?"
>> p.apply("I will not be a part of this")
=> nil
Without preprocessing, Eliza
doesn’t know that “won’t” is a
colloquial form of “will not”
Eliza.pre
✦
A second dictionary, named Eliza.pre, has a set of contractions and the
words they should expand into
>> Eliza.pre
=> {"i'm"=>"I am", "you're"=>"you are", "won't"=>"will not",
"can't"=>"can not", "don't"=>"do not"}
>> Eliza.pre["I'll"] = "I will"
=> "I will"
✦
You can also add new items
to Eliza.pre
The preprocessing step is mostly a convenience
❖it
❖it
doesn’t make Eliza appear any “smarter”
does make it easier to write scripts, since we don’t have make separate patterns for /I
will not/ and /I won’t/
Recap III
✦
To see if a sentence pattern applies
to an input:
❖
do a preprocessing step for contractions
(cut and paste from Eliza.pre)
“I’ll need to check your ID” => “I will need to check your ID”
❖
see if the input matches the regular
expression in a Pattern object
Pattern: /I will need .*/
❖
do a postprocessing step using
Eliza.post on each placeholder
$1: “to check your ID” => “to check my ID”
❖
insert placeholders into the response
“Why do you need to check my ID?”
An Algorithm to Make Responses
✦
One way to implement Eliza would be to make an array of Pattern objects
patterns = [ ]
patterns << Pattern.new( /.../, [“...”] )
...
✦
The main loop would read a sentence and then find a pattern to apply
while sentence = readline
patterns.each do |p|
result = p.apply(sentence)
return result if result != nil
end
end
end
This loop is basically a
linear search
An Algorithm to Make Responses
✦
✦
There are two problems with this algorithm
❖
it will not be very efficient if a script grows to contain several hundred patterns
❖
patterns that appear early in the list will be applied more often
❖
patterns at the end of the list may never be used
To solve these problems, Weizenbaum used a different search strategy
❖
create a table of key words to look for in an input sentence
❖
associate each key word with one or more patterns to try when that word is seen in the
input
(see next slide)
Rules
✦
A rule is an association between a key word and one or more patterns
❖
store key words in a hash table
❖
associate words with a list of Pattern objects that transform sentences containing those
keys
The rule for remember
The rule for dream
Finding Rules
✦
If you want to see if a script has a rule for a particular word, call a method
named rule_for
>> Eliza.rule_for("remember")
=>
[5] --> [
/I remember (.*)/
"Do you often think of $1?"
"Does thinking of $1 bring anything else to mind?"
"What else do you remember?"
/do you remember (.*)/
"Did you think I would forget $1?"
"Why do you think I should recall $1 now?"
"What about $1?"
]
There are two patterns that will apply to
sentences with the word “remember”
The Eliza Algorithm
✦
Eliza checks the table of rules to see if there is a rule for a word
✦
If there is a rule for a word, it is saved in a priority queue
❖
✦
Rules can be assigned a priority
❖
✦
think of it as a list that is automatically re-sorted each time something is added
higher priority rules end up
at the front of the list
After scanning the input
sentence the rules in the
queue are tried in order
❖
if a rule does not apply
move on to the next one
queue = PriorityQueue.newqueue <<
default s.scan(/\w+/) { |x| queue
<< x }while queue.length > 0
rule = queue.shift result =
rule.apply(s) return result if
result != nilend
See elizalab.rb for the actual code...
The Eliza Algorithm
✦
If you want to see this process in action, tell Eliza to work in “verbose mode”
>> Eliza.verbose
=> true
H: I think I’m afraid of cows.
preprocess: line = 'i think i am afraid of cows'
add rule for 'i' to queue
["i", "$noncommittal"]
applying rule: key = 'i'
trying pattern /\bi (want|need) (.*)/i
trying pattern /\bi am .*(sad|unhappy|depressed|sick)(.*)/i
trying pattern /\bi was\b/i
trying pattern /\bi (believe|feel|think|wish) i (.*)/i
reassembling 'But you are not sure you $2?'
postprocess am afraid of cows
C: But you are not sure you are afraid of cows?
Interactive Demo
✦
Let’s watch how Eliza processes some sample sentences
I’m afraid of cows
I had a dream about cows
I remember my sister had a dream about a computer
Do you have a recipe for eggplant parmigiana?
What’s happening?
When in the course of human events...
Before trying a sentence, can you predict (in
general) how Eliza will respond?
Challenge: The Argument Clinic
Patient: Is this the right room for an argument?
Clinician: I told you once.
Patient: No you haven't.
Clinician: Yes I have.
Patient: When?
Clinician: Just now.
Patient: No you didn't.
Clinician: Yes I did.
Patient: You did not!!
Clinician: Oh, I'm sorry, just one moment. Is this
a five minute argument or the full half hour?
http://www.youtube.com/watch?v=teMlv3ripSM
Copyright (?)
Find full text by Google search for
“python ‘all the words’”
or watch the skit on YouTube
An Argument Script
✦
Can you make a script that teaches Eliza how to argue with the user?
>> Eliza.run
Come in.
H: I'd like to have an argument, please.
C: No you wouldn't.
H: Yes I would.
C: I already told you once.
H: No you didn't.
C: Did so.
H: This is futile.
C: It is not.
H: Yes it is.
C: Is not.
H: Is.
C: Not at all.
H: Are you a computer?
C: Nonsense!
H: You sound like one.
C: Look, if I argue with you, I must
take up a contrary position.
P: Argument is an intellectual process. Contradiction is just the
automatic gainsaying of any statement the other person makes.
C: No it isn't.
Magic Tricks
✦
If you know how the secrets behind a magic trick it doesn’t seem as
impressive
✦
We now know the trick behind Eliza
✦
✦
❖
it wasn’t ever going to pass the Turing Test
❖
but some “conversations” that seemed realistic aren’t as surprising any more
Will Eliza ever pass the Turing Test?
❖
is it just a matter of putting lots of rules in a script?
❖
if we make a more elaborate magic trick -- e.g. with more features for handling a wider
variety of sentences -- will Eliza ever become smart enough?
The short answer: No
❖
some program, eventually, might pass the TT, but not
Eliza
Limitations
✦
The Eliza algorithm is basically “cutting and pasting” to transform an input
sentence into a response
✦
Here are a few of the limitations of this approach:
1. it only works for simple sentences
2. it has no memory of what was said earlier in the conversation
3. responses are based only on syntax, not on semantics (meanings of words)
4. Eliza cannot make inferences
5. Eliza has no “real world knowledge” (aka “common sense”)
✦
The following slides will explain these limitations in more detail
①
Sentence Structure
✦
✦
The idea that sentence patterns are templates does not work for complex
sentences
❖
templates have a few words interspersed with groups and wild cards
❖
it is impossible* to define a template for all but the simplest sentences
Example:
I remember when I lived in the country and there were cows everywhere.
✦
✦
What is the main verb in this sentence?
❖
“remember”? “lived”? “were”?
❖
which one should Eliza try to match?
Many sentences have multiple phrases
and clauses, and templates won’t work
for such complex sentences
* a result from formal grammar
theory: there are limits to the
complexity of patterns that can
be matched by regular
expressions
Parsers
✦
✦
There are algorithms, called parsers, that will analyze sentence structure
❖
computer scientists design parsers for programming languages
❖
linguists and researchers in NLP have developed parsers for English and other human
languages
Structure of the example sentence:
(S (NP I)
(VP remember
From the Link parser (CMU):
(SBAR (WHADVP when)
http://www.link.cs.cmu.edu/link/index.html
(S (S (NP I)
(VP lived
(PP in
(NP the country))))
and
(S (NP there)
(VP were
(NP cows)
(PP everywhere))))))
.)
Eliza Has No Memory
✦
②
Consider this conversation:
H: I’m afraid of cows.
C: Is it because you are afraid of cows that you came to me?
H: I really dislike them.
C: You say you really dislike them?
✦
A more natural response would be “you really dislike cows?”
✦
But Eliza has no way of remembering earlier sentences
✦
❖it
has no memory for storing what was said earlier
❖it
can’t go back and get the word “cows” from the first sentence
A more sophisticated algorithm would build up a context as the
conversation goes on, and be able to use words from earlier sentences
Language is More than Syntax
✦
Here is another example conversation:
H: That cow was huge.
C: How big was it?
H: I was chased by a bull once.
C: Did it have horns?
✦
These responses require the computer to know the meaning of words
❖it
needs to know “huge” means “very large” or “very big”
❖it
needs to know that a bull is an animal, and that bulls often have horns
Computer scientists refer to sentence syntax (structure)
and semantics (meaning)
③
Semantics
✦
Adding semantics to the program is more than just adding a dictionary or
list of synonyms:
H: That cow was at least as tall as an elephant.
C: Was it really 10 feet tall?
H: Our parents got mad when we tipped the cows.
C: Did you really push over a cow?
✦
The first response is possible only if the computer knows what an elephant
is
❖elephants
✦
are animals, elephants are much larger than cows, and they can be 10 feet tall
The second response depends on the meaning of “tip”
❖in
this case it means “push”, as in “he tipped the cup”
❖contrast
that with “he tipped the waiter”....
Inference
✦
Even if a program was able to
❖
analyze sentence structure using a parsing algorithm, and
❖
build up a context by remembering sentences, and
❖
know the meanings of words
it would still lack a very important mechanism in language understanding
✦
People continually make inferences when they read sentences
✦
Consider this story:
The cows walked across the pasture.
George was waiting at the barn.
✦
How would you answer the question: “Where were the cows going?”
④
Inference (cont’d)
✦
An intelligent program should be able to make inferences:
H: The cows walked across the pasture while George waited at the
barn.
C: What happened when the cows got to the barn?
✦
The computer was able to “connect the dots” and infer that George was
waiting for the cows so the cows must be walking toward George.
✦
Contrast that with:
H: The cows walked across the pasture while I hid behind the barn.
C: Did they see you?
✦
A very different inference!
Real-World Knowledge
✦
Answers to the question about George and the cows are based on
common sense knowledge
❖
✦
if George was waiting for the cows the cows must have been going to where George was
standing
Other answers might be based on expert knowledge of farms and cows
❖
✦
⑤
cows walk to the barn when they know it’s time to be milked, cows are often milked late in
the day, ...
Paradoxically, more progress has been made in creating programs that use
expert knowledge
❖
medical diagnosis
❖
engineering (e.g. tracking down faults in systems)
❖
business and finance
NLP is a Very Hard Problem
✦
Several hard problems were described in Ch 1 of the textbook
✦
Playing the perfect game of chess:
✦
✦
❖
a problem of scalability
❖
there is an algorithm, but there are too many alternatives to consider
❖
we’ll see a similar problem -- the traveling salesman -- later this term
The “halting problem”:
❖
will a program ever terminate?
❖
a mathematically impossible problem
Natural language processing is hard (impossible?) for different reasons
❖
a problem that is very hard to define, much less solve
NLP is a Very Hard Problem (cont’d)
✦
✦
Some of the things that make an algorithm for carrying on a conversation
so difficult:
❖
sentence complexity
❖
building up a context (remembering previous sentences)
❖
representing the meanings of words
❖
the need to be able to make inferences (“connect the dots”)
❖
real-world knowledge (e.g. an elephant is a very large animal)
Other difficult aspects of language:
❖
social context
❖
non-verbal aspects (gestures, inflection, facial expressions, ...)
Summary
✦
ELIZA was the first “chat” program
❖
✦
written in 1966 by Joseph Weizenbaum
The main idea:
❖
extract key words and phrases from input sentences
❖
do some minor “cutting and pasting” (postprocessing)
❖
insert these pieces into predefined “templates”
✦
This simple strategy is still used in
some “chatbots”
✦
The directions for how to extract key words
and phrases are embodied in a set of rules
❖
rules are saved in a script file
❖
how well Eliza carries on a conversation
depends on the rules in a script
Summary (cont’d)
✦
✦
✦
There are some obvious limitations to this approach:
❖
it only works for simple sentences
❖
no memory of previous sentences (no context)
❖
Eliza does not know the meaning of words (no semantics)
Other limitations:
❖
Eliza does not have an algorithm for making inferences
❖
Eliza has no real world knowledge (“common sense”)
No program has yet solved all of these problems