Is it possible to use certainty factors with the LISA production-rule
system? If so, are there any examples?
http://lisa.sourceforge.net
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
If "certainty factors" is analogous to "fuzzy logic", then there's a
project related to Jess that has built a "fuzzy toolkit". I didn't dig too
deeply, but this might have been done without modifications to core Jess.
Here's a url:
http://www.iit.nrc.ca/IR_public/fuzzy/fuzzyJToolkit2.html
If modifications were in fact required, I'd be interested in hearing about
how extensive they were. Perhaps I could find time to add this support to
Lisa.
Cheers,
--
David E. Young
"For wisdom is more precious than rubies,
and nothing you desire can compare with her."
-- Prov. 8:11
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> Is it possible to use certainty factors with the LISA production-rule
> system? If so, are there any examples?
>
> http://lisa.sourceforge.net
>
>
> Paolo
> --
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"David E. Young" <·······@nospampoboxnospam.com> writes:
> If "certainty factors" is analogous to "fuzzy logic", then there's a
I meant the certainty factors used in expert systems such as MYCIN.
Norvig, for example, covers this in section 16.1 "Dealing with
Uncertainty" (page 532) of PAIP.
Thanks,
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
I'll take a look at PAIP. If it's something requiring changes to core Lisa,
perhaps I can find some time to add it.
Cheers, David.
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> "David E. Young" <·······@nospampoboxnospam.com> writes:
>
> > If "certainty factors" is analogous to "fuzzy logic", then there's a
>
> I meant the certainty factors used in expert systems such as MYCIN.
> Norvig, for example, covers this in section 16.1 "Dealing with
> Uncertainty" (page 532) of PAIP.
>
> Thanks,
>
>
> Paolo
> --
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Recommended Common Lisp libraries/tools (Google for info on each):
> - ASDF/ASDF-INSTALL: system building/installation
> - CL-PPCRE: regular expressions
> - UFFI: Foreign Function Interface
"David E. Young" <·······@nospampoboxnospam.com> wrote in message news:<··················@twister.southeast.rr.com>...
> I'll take a look at PAIP. If it's something requiring changes to core Lisa,
There are also some online explanations, for example:
Certainty Factors
http://www.rattlesnake.com/notions/certainty-factors.html
Belief Models and Certainty Factors
http://www.cs.cf.ac.uk/Dave/AI2/node88.html
Components of an Expert System
http://carlisle-www.army.mil/usacsl/divisions/std/branches/keg/expert/comp.htm
Uncertain Reasoning
http://www.cse.unsw.edu.au/~billw/cs9414/notes/kr/uncertainty/uncertainty.html
Thanks,
Paolo
In article <····························@posting.google.com>,
·······@mclink.it (Paolo Amoroso) wrote:
> "David E. Young" <·······@nospampoboxnospam.com> wrote in message
> news:<··················@twister.southeast.rr.com>...
>
> > I'll take a look at PAIP. If it's something requiring changes to core Lisa,
>
> There are also some online explanations, for example:
>
> Certainty Factors
> http://www.rattlesnake.com/notions/certainty-factors.html
>
> Belief Models and Certainty Factors
> http://www.cs.cf.ac.uk/Dave/AI2/node88.html
>
> Components of an Expert System
> http://carlisle-www.army.mil/usacsl/divisions/std/branches/keg/expert/comp.h
> tm
>
> Uncertain Reasoning
> http://www.cse.unsw.edu.au/~billw/cs9414/notes/kr/uncertainty/uncertainty.ht
> ml
It would be cool if David could add a general protocol
to LISA so that people could write and plug in different
calculi for handling confidences/uncertainties. Something
along the lines of:
(1) A strength object associated with each rule.
(2) A confidence object associated with each declarative
memory element.
(3) A generic function for handling conflict resolution.
It would take the conflict set produced by the rete
network as its argument and return an adjusted
conflict set of instantiated rules to fire based on
the associated strength and confidence objects.
Default values for (1), (2), and (3) could be defined that
did the conventional thing, whatever that is for LISA at the
moment. The user could then specialize them to realize
different confidence/uncertainty schemes.
A possible plan of attack would be to identify the three
most popular confidence/uncertainty schemes and design a
protocol general enough to support an implementation of
each one.
More than cool -- this would be a publishable accomplishment
in its own right.
This looks interesting, and I'm going to try and find some time to build it.
It'll take a little while, I suppose, since time is at a premium for me
right now. After I've studied the problem a bit, I'll ask some relevant
questions. I favor a general protocol, as Sashank described.
Cheers, David.
"Sashank Varma" <····@vanderbilt.edu> wrote in message
·······························@news.vanderbilt.edu...
> In article <····························@posting.google.com>,
> ·······@mclink.it (Paolo Amoroso) wrote:
>
> > "David E. Young" <·······@nospampoboxnospam.com> wrote in message
> > news:<··················@twister.southeast.rr.com>...
> >
> > > I'll take a look at PAIP. If it's something requiring changes to core
Lisa,
> >
> > There are also some online explanations, for example:
> >
> > Certainty Factors
> > http://www.rattlesnake.com/notions/certainty-factors.html
> >
> > Belief Models and Certainty Factors
> > http://www.cs.cf.ac.uk/Dave/AI2/node88.html
> >
> > Components of an Expert System
> >
http://carlisle-www.army.mil/usacsl/divisions/std/branches/keg/expert/comp.h
> > tm
> >
> > Uncertain Reasoning
> >
http://www.cse.unsw.edu.au/~billw/cs9414/notes/kr/uncertainty/uncertainty.ht
> > ml
>
> It would be cool if David could add a general protocol
> to LISA so that people could write and plug in different
> calculi for handling confidences/uncertainties. Something
> along the lines of:
>
> (1) A strength object associated with each rule.
>
> (2) A confidence object associated with each declarative
> memory element.
>
> (3) A generic function for handling conflict resolution.
> It would take the conflict set produced by the rete
> network as its argument and return an adjusted
> conflict set of instantiated rules to fire based on
> the associated strength and confidence objects.
>
> Default values for (1), (2), and (3) could be defined that
> did the conventional thing, whatever that is for LISA at the
> moment. The user could then specialize them to realize
> different confidence/uncertainty schemes.
>
> A possible plan of attack would be to identify the three
> most popular confidence/uncertainty schemes and design a
> protocol general enough to support an implementation of
> each one.
>
> More than cool -- this would be a publishable accomplishment
> in its own right.
"David E. Young" <·······@nospampoboxnospam.com> wrote in message
························@twister.southeast.rr.com...
> This looks interesting, and I'm going to try and find some time to build
it.
> It'll take a little while, I suppose, since time is at a premium for me
> right now. After I've studied the problem a bit, I'll ask some relevant
> questions. I favor a general protocol, as Sashank described.
>
> Cheers, David.
I have to agree with Sashank, this would be a fantastic contribution, and
one I would use myself. Thanks, David, for looking into it!!
Gorbag
>
> "Sashank Varma" <····@vanderbilt.edu> wrote in message
> ·······························@news.vanderbilt.edu...
> > In article <····························@posting.google.com>,
> > ·······@mclink.it (Paolo Amoroso) wrote:
> >
> > > "David E. Young" <·······@nospampoboxnospam.com> wrote in message
> > > news:<··················@twister.southeast.rr.com>...
> > >
> > > > I'll take a look at PAIP. If it's something requiring changes to
core
> Lisa,
> > >
> > > There are also some online explanations, for example:
> > >
> > > Certainty Factors
> > > http://www.rattlesnake.com/notions/certainty-factors.html
> > >
> > > Belief Models and Certainty Factors
> > > http://www.cs.cf.ac.uk/Dave/AI2/node88.html
> > >
> > > Components of an Expert System
> > >
>
http://carlisle-www.army.mil/usacsl/divisions/std/branches/keg/expert/comp.h
> > > tm
> > >
> > > Uncertain Reasoning
> > >
>
http://www.cse.unsw.edu.au/~billw/cs9414/notes/kr/uncertainty/uncertainty.ht
> > > ml
> >
> > It would be cool if David could add a general protocol
> > to LISA so that people could write and plug in different
> > calculi for handling confidences/uncertainties. Something
> > along the lines of:
> >
> > (1) A strength object associated with each rule.
> >
> > (2) A confidence object associated with each declarative
> > memory element.
> >
> > (3) A generic function for handling conflict resolution.
> > It would take the conflict set produced by the rete
> > network as its argument and return an adjusted
> > conflict set of instantiated rules to fire based on
> > the associated strength and confidence objects.
> >
> > Default values for (1), (2), and (3) could be defined that
> > did the conventional thing, whatever that is for LISA at the
> > moment. The user could then specialize them to realize
> > different confidence/uncertainty schemes.
> >
> > A possible plan of attack would be to identify the three
> > most popular confidence/uncertainty schemes and design a
> > protocol general enough to support an implementation of
> > each one.
> >
> > More than cool -- this would be a publishable accomplishment
> > in its own right.
>
>
In article <···············@bos-service2.ext.ray.com>,
"Gorbag" <······@invalid.acct> wrote:
> "David E. Young" <·······@nospampoboxnospam.com> wrote in message
> ························@twister.southeast.rr.com...
> > This looks interesting, and I'm going to try and find some time to build
> it.
> > It'll take a little while, I suppose, since time is at a premium for me
> > right now. After I've studied the problem a bit, I'll ask some relevant
> > questions. I favor a general protocol, as Sashank described.
> >
> > Cheers, David.
>
> I have to agree with Sashank, this would be a fantastic contribution, and
> one I would use myself. Thanks, David, for looking into it!!
I'm reminded of an incident described in Steven Levy's excellent
book 'Hackers'. At the dawn of AI, Marvin Minsky walked into
the Lab at MIT with a robotic arm and maybe a primitive television
camera. He said something along the lines of "This is a robotic
arm and a television camera. I am leaving them here for you to
play with." And then he walked out. From this, a number of
pioneering efforts in machine vision!
Sashank Varma <····@vanderbilt.edu> writes:
> I'm reminded of an incident described in Steven Levy's excellent
> book 'Hackers'. At the dawn of AI, Marvin Minsky walked into
> the Lab at MIT with a robotic arm and maybe a primitive television
> camera. He said something along the lines of "This is a robotic
> arm and a television camera. I am leaving them here for you to
> play with." And then he walked out. From this, a number of
> pioneering efforts in machine vision!
Why, do you think anything else is needed to motivate pioneers?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
> Sashank Varma <····@vanderbilt.edu> writes:
> > I'm reminded of an incident described in Steven Levy's excellent
> > book 'Hackers'. At the dawn of AI, Marvin Minsky walked into
> > the Lab at MIT with a robotic arm and maybe a primitive television
> > camera. He said something along the lines of "This is a robotic
> > arm and a television camera. I am leaving them here for you to
> > play with." And then he walked out. From this, a number of
> > pioneering efforts in machine vision!
>
> Why, do you think anything else is needed to motivate pioneers?
No, but it doesn't take much to demotivate them. A lot of companies would
get far better research if they gave their researchers sandboxes intead of
10,000 page tomes of existing product information, require 100 page
documents to suggest minor improvements, and then subjected the development
of improvements to the CMM. Few companies understand the sandbox model,
because its unpredictable, and doesn't give them metrics on how close they
are to a product or an improvement. Or when something useful will happen. Or
be able to price it. Etc.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <····@mouse-potato.com> wrote:
> Why, do you think anything else is needed to motivate pioneers?
Um, caffeine in a liquid delivery medium (famous quote:
"A mathematician is a device for turning coffee into
theorems.") and good Chinese food?
"David E. Young" <·······@nospampoboxnospam.com> writes:
> This looks interesting, and I'm going to try and find some time to build it.
As others have said in this thread, that would be really great. Let
me just add why I like LISA.
Having become interested in expert systems, I looked for expert system
shells written in Lisp to experiment with.
Lisp is often considered a language only good for AI, and it indeed
was mainstream when the AI market thrived. Yet I found only a handful
of freely available expert system shells written in Lisp:
BABYLON
ftp://ftp.gmd.de/gmd/ai-research/Software/Babylon/
LISA
http://lisa.sourceforge.net
MYCIN - PAIP implementation
http://www.norvig.com/paip/README.html
OPS5
http://www-2.cs.cmu.edu/Groups/AI/areas/expert/systems/ops5/0.html
TMYCIN
http://www.cs.utexas.edu/users/novak/tmycinb.html
The PAIP implementation of MYCIN and TMYCIN are mostly educational
systems. The latter has some limitations--e.g. only one context--and
the source code looks archaic, with heavy use of PROG and property
lists.
The syntax of OPS5 looks a bit verbose/confusing and the system appears
limited (I didn't dare to look at the code :) Besides the sample code,
the only available documentation is a 4-page command reference list.
As for BABYLON, most of the documentation available online is in
German, which is a show stopper for me because I don't know German.
LISA looks like the best among the above mentioned systems. It is
modern, has adequate documentation, is very well integrated with Lisp,
the source code is well written and it allows to reason over CLOS
objects. The latter is very useful because adding reasoning
capabilities to an application probably doesn't involve extensive
modifications.
Having seen certainty factors often mentioned in expert systems
literature, I noticed that LISA doesn't apparently support them.
Hence my initial query. Incidentally, not even CLIPS seems to support
certainty factors.
> right now. After I've studied the problem a bit, I'll ask some relevant
> questions. I favor a general protocol, as Sashank described.
This interesting book on the MYCIN experiments might be a useful
resource:
http://www.aaai.org/Resources/Classics/Mycin/mycin.html
particularly section 5.1.4 "Certainty Factors", on page 91, and
chapter 11 "A Model of Inexact Reasoning in Medicine" on page 233.
Of course, I am willing to help in any way I can. Thanks again,
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
A few comments.
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> As others have said in this thread, that would be really great. Let
> me just add why I like LISA.
>
> Having become interested in expert systems, I looked for expert system
> shells written in Lisp to experiment with.
>
> Lisp is often considered a language only good for AI, and it indeed
> was mainstream when the AI market thrived. Yet I found only a handful
> of freely available expert system shells written in Lisp:
>
> BABYLON
> ftp://ftp.gmd.de/gmd/ai-research/Software/Babylon/
>
> LISA
> http://lisa.sourceforge.net
>
> MYCIN - PAIP implementation
> http://www.norvig.com/paip/README.html
>
> OPS5
> http://www-2.cs.cmu.edu/Groups/AI/areas/expert/systems/ops5/0.html
>
> TMYCIN
> http://www.cs.utexas.edu/users/novak/tmycinb.html
Another source of expert system shells is the computational modeling
community in cognitive psychology. Soar has the most sophisticated
learning mechanisms of any rule-based system, and is currently
being used to develop models that play contemporary video games and
fly military aircraft in real-time. However, Soar was ported from
Common Lisp to C a decade or so ago. ACT-R combines rules with
elements of bayesian statistics and artificial neural networks and
has been applied to a variety of simple and complex tasks, including
intelligent tutors for algebra, geometry, and programming; air
traffic control; and driving on crowded roads while managing
a cell phone. It is also written in Common Lisp, as is the similar
EPIC system. The problem with Soar, ACT-R, and EPIC is that they
come with lots of assumptions that lend psychological plausibility
but that frankly get in the way of programmers who are just trying
to get the job done.
> The syntax of OPS5 looks a bit verbose/confusing and the system appears
> limited (I didn't dare to look at the code :) Besides the sample code,
> the only available documentation is a 4-page command reference list.
I love OPS5! (But then again it is a native language for me.)
The original Artificial Intelligence paper by Forgy (and the CMU
dissertation on which it is based) are readable. However, the
best tutorials are the books by Brownston et al. and by Cooper
and Wogrin; I bought the former (used) through Amazon for $10 or
so.
The best description of the implementation of the rete algorithm
which was first developed for OPS5 and is at the heart of many/most
fast expert system shells (including Soar and EPIC and ACT-R's
predecessor, ACT*) is Doorenbos's CMU dissertation circa 1995.
My bet is that in reading it, you will gain a programmer's
understanding of OPS5 that even the tutorial books fail to
deliver. Another useful source of this material is chapter 20
of Kogge's "The Architecture of Symbolic Computers", which many
Lispers already own.
> LISA looks like the best among the above mentioned systems. It is
> modern, has adequate documentation, is very well integrated with Lisp,
> the source code is well written and it allows to reason over CLOS
> objects. The latter is very useful because adding reasoning
> capabilities to an application probably doesn't involve extensive
> modifications.
My sense is that you are correct in this evaluation. It is
the shell I would choose if I had your goal.
> Having seen certainty factors often mentioned in expert systems
> literature, I noticed that LISA doesn't apparently support them.
> Hence my initial query. Incidentally, not even CLIPS seems to support
> certainty factors.
One thing that should be mentioned is that the handling of
uncertainty has changed quite a bit since MYCIN. Although
this is not my area, I would certainly read up on modern
schemes and consider their critiques of MYCIN's confidence
factors. A more faithful bayesian scheme might be preferable,
if only for reasons of fashion.
Sashank Varma <····@vanderbilt.edu> wrote:
> Another source of expert system shells is the computational modeling
> community in cognitive psychology. Soar has the most sophisticated
> learning mechanisms of any rule-based system, and is currently
> being used to develop models that play contemporary video games and
> fly military aircraft in real-time. However, Soar was ported from
> Common Lisp to C a decade or so ago.
Jans Aasman (then at KPN Research, now at Franz) wrote a Common Lisp
version of Soar 6.2.5. He wrote a small paper about it, called
"Soaring back to Lisp".
Arthur
"Sashank Varma" <····@vanderbilt.edu> wrote in message
·······························@news.vanderbilt.edu...
> A few comments.
>
> Another source of expert system shells is the computational modeling
> community in cognitive psychology. Soar has the most sophisticated
> learning mechanisms of any rule-based system, and is currently
> being used to develop models that play contemporary video games and
> fly military aircraft in real-time. However, Soar was ported from
> Common Lisp to C a decade or so ago. ACT-R combines rules with
> elements of bayesian statistics and artificial neural networks and
> has been applied to a variety of simple and complex tasks, including
> intelligent tutors for algebra, geometry, and programming; air
> traffic control; and driving on crowded roads while managing
> a cell phone. It is also written in Common Lisp, as is the similar
> EPIC system. The problem with Soar, ACT-R, and EPIC is that they
> come with lots of assumptions that lend psychological plausibility
> but that frankly get in the way of programmers who are just trying
> to get the job done.
The larger problem with these systems is that they weren't written by
programmers. The psychological plausibility is a plus, not a minus, and the
problem I have with SOAR after the rewrite (get the last lisp version at the
CMU archive, btw, the new version is at UMich) is that they tried to make it
into a programming language instead of something for modelling human
behavior using a psychological model. So it went from a tool with unique
characteristics for solving certain kinds of problems (e.g., very useful for
adversarial reasoning, user modeling, etc. where you could actually predict
the time it would take someone to come to a conclusion), into a
run-of-the-mill rule based agent development toolkit with some strange
historical ways of going about accomplishing things that are no longer
firmly grounded in the psychological theory the system was developed to
investigate.
In article <·············@bos-service2.ext.ray.com>,
"Gorbag" <······@invalid.acct> wrote:
> "Sashank Varma" <····@vanderbilt.edu> wrote in message
> ·······························@news.vanderbilt.edu...
> >
> > Another source of expert system shells is the computational modeling
> > community in cognitive psychology. Soar has the most sophisticated
> > learning mechanisms of any rule-based system, and is currently
> > being used to develop models that play contemporary video games and
> > fly military aircraft in real-time. However, Soar was ported from
> > Common Lisp to C a decade or so ago. ACT-R combines rules with
> > elements of bayesian statistics and artificial neural networks and
> > has been applied to a variety of simple and complex tasks, including
> > intelligent tutors for algebra, geometry, and programming; air
> > traffic control; and driving on crowded roads while managing
> > a cell phone. It is also written in Common Lisp, as is the similar
> > EPIC system. The problem with Soar, ACT-R, and EPIC is that they
> > come with lots of assumptions that lend psychological plausibility
> > but that frankly get in the way of programmers who are just trying
> > to get the job done.
>
> The larger problem with these systems is that they weren't written by
> programmers.
I would say it differently. ACT-R, EPIC, and certainly Soar were
written *by* programmers, but nor *for* programmers. The expected
users were psychologists, not computer scientists, and its shows.
> The psychological plausibility is a plus, not a minus, and the
> problem I have with SOAR after the rewrite (get the last lisp version at the
> CMU archive, btw, the new version is at UMich) is that they tried to make it
> into a programming language instead of something for modelling human
> behavior using a psychological model. So it went from a tool with unique
> characteristics for solving certain kinds of problems (e.g., very useful for
> adversarial reasoning, user modeling, etc. where you could actually predict
> the time it would take someone to come to a conclusion), into a
> run-of-the-mill rule based agent development toolkit with some strange
> historical ways of going about accomplishing things that are no longer
> firmly grounded in the psychological theory the system was developed to
> investigate.
From my biased position (in cognitive science, not pure AI),
this rings true.
Sashank Varma <····@vanderbilt.edu> writes:
> Common Lisp to C a decade or so ago. ACT-R combines rules with
> elements of bayesian statistics and artificial neural networks and
Are there other Lisp expert system shells that support Bayesian
schemes?
> come with lots of assumptions that lend psychological plausibility
> but that frankly get in the way of programmers who are just trying
> to get the job done.
What is the rationale for not supporting uncertain reasoning in shells
such as CLIPS and LISA? Maybe even without uncertain reasoning, the
systems can deal with such a large class of problems, that adding
uncertain reasoning wouldn't significantly extend their applicability
or usefulness?
Or perhaps they don't do it because it's easy for the user to extend
the shells for uncertain reasoning? Support for, say, CFs, might
possibly be added with little or no modification to the LISA core.
For example, a table could map rules and facts to CFs, and the firing
of rules could dynamically combine CFs and update the table.
> I love OPS5! (But then again it is a native language for me.)
Does OPS5 support uncertain reasoning via CFs or other schemes?
Thanks to you and all other contributors to this thread for the useful
feedback.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> Sashank Varma <····@vanderbilt.edu> writes:
>
> > Common Lisp to C a decade or so ago. ACT-R combines rules with
> > elements of bayesian statistics and artificial neural networks and
>
> Are there other Lisp expert system shells that support Bayesian
> schemes?
I don't know about the AI or commercial worlds. Within
cognitive science ACT-R is the only rule-based system
that I know of that supports bayesian reasoning. But
again, I warn you that it takes psychological plausibility
more seriously than strict adherence to the mathematical/
statistical theory, and is therefore probably not suitable
for your purposes.
> What is the rationale for not supporting uncertain reasoning in shells
> such as CLIPS and LISA? Maybe even without uncertain reasoning, the
> systems can deal with such a large class of problems, that adding
> uncertain reasoning wouldn't significantly extend their applicability
> or usefulness?
The reason is mostly historical. MYCIN is roughly a
contemporary of the OPS family of languages. Whereas
MYCIN went the confidence factor route, the OPS
developers were more concerned with raw speed -- hence
the efficiency of the underlying rete algorithm. Also,
being primarily based at CMU circa the 1970s, there
was a certain commitment to purely symbolic solutions,
which seemed sufficient for large and important systems
of the time, such as DEC's XCON expert system and the
HEARSAY speech understanding system. The explosion of
uncertain, bayesian, and other forms of graded reasoning
schemes in AI occurred a decade or more later after the
development of OPS (and MYCIN). Because CLIPS and LISA
are, in some sense, descendants of the OPS family, not
the MYCIN family, they inherit this symbolic focus by
default.
> > I love OPS5! (But then again it is a native language for me.)
>
> Does OPS5 support uncertain reasoning via CFs or other schemes?
No. And I don't see how one could adopt a CF style
in OPS5 given the limited nature of its conflict
resolution schemes (other than in the Turing-equivalent
sense).
Paolo Amoroso <·······@mclink.it> writes:
> This interesting book on the MYCIN experiments might be a useful
> resource:
>
> http://www.aaai.org/Resources/Classics/Mycin/mycin.html
>
> particularly section 5.1.4 "Certainty Factors", on page 91, and
> chapter 11 "A Model of Inexact Reasoning in Medicine" on page 233.
Chapter 10 "Uncertainty and Evidential Support" on page 209 is
actually more relevant than chapter 11.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"David E. Young" <·······@nospampoboxnospam.com> writes:
> This looks interesting, and I'm going to try and find some time to build it.
> It'll take a little while, I suppose, since time is at a premium for me
> right now. After I've studied the problem a bit, I'll ask some relevant
> questions. I favor a general protocol, as Sashank described.
David is about to start working on adding support for certainty
factors to LISA. He solicits feedback on the programming interface:
http://sourceforge.net/mailarchive/message.php?msg_id=9520156
Thanks to David for looking into this.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Here's a post I just send to the lisa-users list:
So, let me get a few things straight in my head. In PAIP there are three
distinct classes of CFs; as you read these examples, note carefully the
suggested Lisa syntax for the new CF support:
1. A => C, B => C. Two distinct rules, same "piece of evidence", or "fact"
in Lisa's terminology. In this case we use the combination formula described
on pg. 534. In Lisa, this could be written as:
(defrule frodo () => (assert (C) :cf 0.6))
(defrule bilbo () => (assert (C) :cf 0.4))
2. A and B => C. Single rule with a conjuction. In this case a CF for C is
calculated by taking the min of A's CF and B's CF. In Lisa:
(defrule frodo ()
(?a (A))
(?b (B))
=>
(assert (C) :cf (combine ?a ?b)))
3. A and B => .9 C. The rule itself is uncertain. In Lisa:
(defrule frodo (:cf 0.9)
(?a (A))
(?b (B))
=>
(assert (C) :cf (combine ?a ?b)))
Ignoring implementation details for now, please comment on the suggested
Lisa syntax and my supposed understanding of the issues. Does it correctly
reflect PAIP's CF theory? The syntax in examples (2) and (3) expects the
programmer to supply the CF by calling the COMBINE method (which "does the
right thing" behind the curtain). Is this satisfactory?
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> "David E. Young" <·······@nospampoboxnospam.com> writes:
>
> > This looks interesting, and I'm going to try and find some time to build
it.
> > It'll take a little while, I suppose, since time is at a premium for me
> > right now. After I've studied the problem a bit, I'll ask some relevant
> > questions. I favor a general protocol, as Sashank described.
>
> David is about to start working on adding support for certainty
> factors to LISA. He solicits feedback on the programming interface:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=9520156
>
> Thanks to David for looking into this.
>
>
> Paolo
> --
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Recommended Common Lisp libraries/tools (Google for info on each):
> - ASDF/ASDF-INSTALL: system building/installation
> - CL-PPCRE: regular expressions
> - UFFI: Foreign Function Interface
Another question. Do CFs play a role in pattern matching? That is, should a
fact's CF value be considered in conjuction with the tests defined in the
pattern? In PAIP, there's a "cut-off", or lower threshold, CF value that
inhibits search. The rub is that MYCIN is a backchaining system and Lisa
isn't, but perhaps that doesn't matter.
Thanks...
David.
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> "David E. Young" <·······@nospampoboxnospam.com> writes:
>
> > This looks interesting, and I'm going to try and find some time to build
it.
> > It'll take a little while, I suppose, since time is at a premium for me
> > right now. After I've studied the problem a bit, I'll ask some relevant
> > questions. I favor a general protocol, as Sashank described.
>
> David is about to start working on adding support for certainty
> factors to LISA. He solicits feedback on the programming interface:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=9520156
>
> Thanks to David for looking into this.
>
>
> Paolo
> --
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Recommended Common Lisp libraries/tools (Google for info on each):
> - ASDF/ASDF-INSTALL: system building/installation
> - CL-PPCRE: regular expressions
> - UFFI: Foreign Function Interface
In article <····················@twister.southeast.rr.com>,
"David E. Young" <·······@nospampoboxnospam.com> wrote:
> Another question. Do CFs play a role in pattern matching? That is, should a
> fact's CF value be considered in conjuction with the tests defined in the
> pattern? In PAIP, there's a "cut-off", or lower threshold, CF value that
> inhibits search. The rub is that MYCIN is a backchaining system and Lisa
> isn't, but perhaps that doesn't matter.
I don't think CFs should play a role in pattern matching.
The rete network should be used to generate all rule
instantiations on a logical basis -- unlike Prolog, it
is by design parallel in its matching. The resulting
set of matches (i.e., the conflict set) should then be
subjected to CF calculations. For example, you might
retain and fire only the instantiation with the highest
confidence, and only if it is above some system-defined
and user-adjustable threshold.
In other words, I think you should leave the existing
system in place as much as possible and layer the CF
stuff on top of it as much as possible.
I guess the obvious implementation question is where
to store the confidences of each declarative memory
element/assertion/fact. A cheap solution is to store
them in a hashtable. Another possibility -- one that
I have used in the past -- is to have every declarative
memory element class include a CONF slot whose value
defaults to 1.0. This way, users can "grab ahold" of
confidences on the condition sides of rules and carry
out their own computations if they want to experiment.
(For example, one might want to specify that for a
declarative memory element to satisfy a condition
element it must not only pass all the symbolic tests,
but also the value of its CONF slot must exceed a
specified threshold.[*]) The second implementation
strategy will require small changes to other parts
of the system: prohibiting users from declaring new
classes of declarative memory element that include
the now-reserved slotname CONF, providing a global
flag for whether CONF values are printed or elided
(so that users interested in just the symbolic
aspects of LISA do not have their traces cluttered
with superfluous information), etc.
[*] If this kind of test is of interest, there is a
natural way to extend the syntax of OPS5-derived
languages to naturally express them.
Ok, good. That makes sense to me. Thanks...
David.
"Sashank Varma" <····@vanderbilt.edu> wrote in message
·······························@news.vanderbilt.edu...
> In article <····················@twister.southeast.rr.com>,
> "David E. Young" <·······@nospampoboxnospam.com> wrote:
>
> > Another question. Do CFs play a role in pattern matching? That is,
should a
> > fact's CF value be considered in conjuction with the tests defined in
the
> > pattern? In PAIP, there's a "cut-off", or lower threshold, CF value that
> > inhibits search. The rub is that MYCIN is a backchaining system and Lisa
> > isn't, but perhaps that doesn't matter.
>
> I don't think CFs should play a role in pattern matching.
> The rete network should be used to generate all rule
> instantiations on a logical basis -- unlike Prolog, it
> is by design parallel in its matching. The resulting
> set of matches (i.e., the conflict set) should then be
> subjected to CF calculations. For example, you might
> retain and fire only the instantiation with the highest
> confidence, and only if it is above some system-defined
> and user-adjustable threshold.
>
> In other words, I think you should leave the existing
> system in place as much as possible and layer the CF
> stuff on top of it as much as possible.
>
> I guess the obvious implementation question is where
> to store the confidences of each declarative memory
> element/assertion/fact. A cheap solution is to store
> them in a hashtable. Another possibility -- one that
> I have used in the past -- is to have every declarative
> memory element class include a CONF slot whose value
> defaults to 1.0. This way, users can "grab ahold" of
> confidences on the condition sides of rules and carry
> out their own computations if they want to experiment.
> (For example, one might want to specify that for a
> declarative memory element to satisfy a condition
> element it must not only pass all the symbolic tests,
> but also the value of its CONF slot must exceed a
> specified threshold.[*]) The second implementation
> strategy will require small changes to other parts
> of the system: prohibiting users from declaring new
> classes of declarative memory element that include
> the now-reserved slotname CONF, providing a global
> flag for whether CONF values are printed or elided
> (so that users interested in just the symbolic
> aspects of LISA do not have their traces cluttered
> with superfluous information), etc.
>
> [*] If this kind of test is of interest, there is a
> natural way to extend the syntax of OPS5-derived
> languages to naturally express them.
On Mon, 13 Sep 2004 19:42:09 +0200, Paolo Amoroso <·······@mclink.it>
wrote:
> "David E. Young" <·······@nospampoboxnospam.com> writes:
>
>> This looks interesting, and I'm going to try and find some time to
>> build it.
>> It'll take a little while, I suppose, since time is at a premium for me
>> right now. After I've studied the problem a bit, I'll ask some relevant
>> questions. I favor a general protocol, as Sashank described.
>
> David is about to start working on adding support for certainty
> factors to LISA. He solicits feedback on the programming interface:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=9520156
>
> Thanks to David for looking into this.
>
>
> Paolo
CF is considered a bit dated.. (Does not create very accurate models)
You might want to look into Dempster-Shafer theory for uncertainty
management
or fuzzy reasoning.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Yeah, I read that in PAIP. I'm going to stick with implementing cf for now
because 1) it's been requested; 2) I understand it; and 3) eventually I'll
probably add support for other schemes anyhow.
Thanks, David.
"John Thingstad" <··············@chello.no> wrote in message
·····················@mjolner.upc.no...
> On Mon, 13 Sep 2004 19:42:09 +0200, Paolo Amoroso <·······@mclink.it>
> wrote:
>
> CF is considered a bit dated.. (Does not create very accurate models)
> You might want to look into Dempster-Shafer theory for uncertainty
> management
> or fuzzy reasoning.
>
> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Paolo Amoroso <·······@mclink.it> wrote in message news:<··············@plato.moon.paoloamoroso.it>...
> Is it possible to use certainty factors with the LISA production-rule
> system? If so, are there any examples?
>
> http://lisa.sourceforge.net
>
>
> Paolo
I have used a number of expert system shells. The best one I have
used is LispWork's KnowledgeWorks. It does not have certainty factors
built in, but one can use KnowledgeWork's meta-rule protocol to add
uncertainty reasoning (in fact there is a sample case study that does
this in the manual). I have used the facility to build quite an
elaborate model and it took only 70 lines of code.
I know that somehow you are probably already discounting this
suggestion because it requires you to purchase LispWorks Enterprise
Edition and it is not "free" software. But really, you shouldn't.
Your time is not without value.
I *really* like this MRP capability. Maybe at some future date it can
be added to the standard. (Who am I kidding?)
(Please don't email me - I am running a spam experiment. Thanks)
··········@eudoramail.com (Rand Sobriquet) writes:
> I have used a number of expert system shells. The best one I have
> used is LispWork's KnowledgeWorks. It does not have certainty factors
[...]
> I know that somehow you are probably already discounting this
> suggestion because it requires you to purchase LispWorks Enterprise
> Edition and it is not "free" software. But really, you shouldn't.
I'm not discounting this possibility, just delaying it a little bit :)
By the way, I don't mind commercial software.
Thanks for the feedback,
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> wrote in message news:<··············@plato.moon.paoloamoroso.it>...
> ··········@eudoramail.com (Rand Sobriquet) writes:
>
> > I have used a number of expert system shells. The best one I have
> > used is LispWork's KnowledgeWorks. It does not have certainty factors
> [...]
> > I know that somehow you are probably already discounting this
> > suggestion because it requires you to purchase LispWorks Enterprise
> > Edition and it is not "free" software. But really, you shouldn't.
>
> I'm not discounting this possibility, just delaying it a little bit :)
> By the way, I don't mind commercial software.
KEE and Joshua. ;-)
> Thanks for the feedback,
>
>
> Paolo
LOOM and Powerloom should count as expert system shells.
http://www.isi.edu/isd/LOOM/LOOM-HOME.html
http://www.isi.edu/isd/LOOM/PowerLoom/index.html
I use Lispworks/Knowledgeworks on commercial projects at work; it is the
finest Lisp environment I've used since my Symbolics days. One of the few
true bargains left in the commercial software world. I don't see how our
flagship product would have been possible without it...
Also, to answer Paolos's question as to why Lisa wasn't designed from the
outset with support for CF. I used CLIPS and Jess as my baseline models and
tried to support most of the features of those platforms. During Lisa's 2.0
rewrite, I concentrated exclusively on the Rete engine and support for truth
maintenance. Plus, at the time I didn't know much about CFs. I still don't,
but I'll be doing some research to see how I might fit them into Lisa.
Cheers, David
"Rand Sobriquet" <··········@eudoramail.com> wrote in message
·································@posting.google.com...
> Paolo Amoroso <·······@mclink.it> wrote in message
news:<··············@plato.moon.paoloamoroso.it>...
> > Is it possible to use certainty factors with the LISA production-rule
> > system? If so, are there any examples?
> >
> > http://lisa.sourceforge.net
> >
> >
> > Paolo
>
>
> I have used a number of expert system shells. The best one I have
> used is LispWork's KnowledgeWorks. It does not have certainty factors
> built in, but one can use KnowledgeWork's meta-rule protocol to add
> uncertainty reasoning (in fact there is a sample case study that does
> this in the manual). I have used the facility to build quite an
> elaborate model and it took only 70 lines of code.
>
> I know that somehow you are probably already discounting this
> suggestion because it requires you to purchase LispWorks Enterprise
> Edition and it is not "free" software. But really, you shouldn't.
> Your time is not without value.
>
> I *really* like this MRP capability. Maybe at some future date it can
> be added to the standard. (Who am I kidding?)
>
>
>
> (Please don't email me - I am running a spam experiment. Thanks)