Guide to Intelligent Systems; Second Edition; Michael Negnevitsky



Download 281.84 Kb.
Page2/5
Date06.08.2017
Size281.84 Kb.
#27182
TypeGuide
1   2   3   4   5

LISP


  1. LISP

    • Second high level language developed. FORTRAN was the first.

    • Program and data take the same form.

Functions:




  • (car )

    • (car (1 2 3)) => 1

  • (cdr )

    • (cdr (1 2 3)) => (2 3)

    • (cdr (1)) => NIL

  • (list )

    • (setf fullhouse (list 2 2 3 3 3)))

  • (setf )

    • (setf eat 8)

    • (setf eatthis (list pie cake))

  • (length )

    • (length fullhouse) => 5

  • (defun (exp1) (exp2) (exp3) ….(expN) )

  • (cond ( (condition 1) (exp1)..(expN)) ( (condition 2) (exp1)..(expN)) (t (exp1)..(expN)) )

  • (append (list1) (list2))

    • (append (list 1 2 3) (list 4 5)) => (1 2 3 4 5)

  • (cons (list1) (list2))

    • (cons (list 1 2 3) (list 4 5)) => ((1 2 3) 4 5)

  • (eval (list))

    • (eval (car (1 2 3)) => 1

  • (mapcar ….)

    • (mapcar 'car '((1 a) (2 b) (3 c))) => (1 2 3)

    • (mapcar 'abs '(3 -4 2 -5 -6)) => (3 4 2 5 6)

    • (mapcar 'cons '(a b c) '(1 2 3)) => ((A . 1) (B . 2) (C . 3))

Examples:


(defun init ()

(setf big (list 1 2 3 4 5 6 7 8 9 10))

(setf fullhouse (list 2 2 2 3 3))

)
(defun lastone (list)

(cond

(( = (length list) 1)



(first list)

)

( t



(print list)

(lastone (cdr list))

)

)

)


(defun sumList(addlist)

(cond


((= (length addlist) 1)

(car addlist)

)

(t

(+ (car addlist)(sumList(cdr addlist)))



)

)

)



(defun average (list)

(/ (sumList list) (length list))

)
(defun middleNum (nums)

(setf mid (/ (length nums) 2))

(getNum mid nums)

)
(defun getNum (mid nums)

(cond

((= 1 mid)



(car nums)

)

(t



(getNum (- mid 1) (cdr nums))

)

)



)
(defun insultMe (message)

(append (list 'Yo 'Mamma) message)

)
Link to LISP Help

http://www.lisp.org/HyperSpec/FrontMatter/Chapter-Index.html

; Homework assigment 2

; Lisp review

; Fall 2007


(setf big '(1 2 3))
(defun revMe (rlist)

(cond


((= (length rlist) 1)

rlist


)

( t


(append (revMe (cdr rlist)) (list (car rlist)))

)

)



)
; (1 2 3)

; (2 3)


; (3)

; (append (3) (list 2)) => (3 2)

; (append (3 2) (list 1)) = > (3 2 1)
(defun countMe (rlist)

(cond


((equal NIL (cdr rlist))

1

)



(t

(+ 1 (countMe (cdr rlist)))

)

)

)



(defun fact (num)

(cond


((= 1 num)

num


)

(t

(* (fact (- num 1)) num)



)

)

)


(defun funTheList (op nums)

(setf comList (append (list op) nums))

(print comList)

(eval comList)

)

  1. Classic AI Systems (Rule-Based Systems)

While important to our study, we don’t want to spend the whole semester on this topic. We will concentrate on rule-based reasoning and do some LISP.


Here is a link to some LISP literature from Wikipedia:
http://en.wikipedia.org/wiki/Lisp_programming_language#Syntax_and_semantics
Early methods were based on providing the computer general methods of problems solving broad classes of problems. The computer searched for solutions using these general methods. This approach is referred to as a “weak method”. They applied “weak” as in non-problem specific information to a task domain. The results were not satisfactory.
Domain specific systems showed success so we will talk about those.
Summary – Weak methods relied upon general problem solving techniques and little to no a-priori domain specific information. This approach has shown merit for more trivial problems, but has not been shown to be scaleable to larger more complex problems.
Expert systems operate with an abundance of domain specific knowledge and are very narrow in their abilities and are quite inflexible. They have had good success in several areas, such as medicine and prospecting.
Key points of interest:


  1. Knowledge (page 25)

    • What is it?

    • Where does it come from

    • How do we represent it?

      • Production rules (if – then statements)

  2. Structure of AI program (page 31)

The production rules are rules of thumb that we obtained through research; reading books and papers; experimentation; asking experts what they would do in a variety of situations.


The short-term memory consists of a set of facts that describes the current problem to be solved.
The reasoning function acts as an inference engine, user interface, and a tracing mechanism that can be used to explain the programs line of reasoning.

  • Inference engine – matches facts in the short-term memory against the rules in the long-term memory.

  • User interface – communicates to the user. Typically its job would be collect facts from the user and store them in the short-term memory. When it draws conclusions from its rules, these may also be stored as facts. If the inference engine comes to impasse before drawing a conclusion, it may direct the user interface to ask the user for more information so it can continue.

  • Explanation facility – tracks the rule/fact matching process so that the system can show its line of reasoning.

Other modules may include:



  • External databases

  • Models/programs

  • Developer interface

The key to the functionality of the system is the inference engine. The diagram below shows the inference engine operational procedure.





  1. Forward chaining – The accumulation of facts to support a conclusion. We gather information and then infer whatever we can from it. Data driven reasoning.

Database Facts:


{a, b, c, d, e}
Rules:
/* Rule 1. */

If (y == TRUE) && (d == TRUE) {

Z = TRUE;

}
/* Rule 2. */

If (x == TRUE) && (b == TRUE) && (e == TRUE) {

Y = TRUE;

}
/* Rule 3. */

If (a == TRUE) {

X = TRUE;

}
/* Rule 4. */

If (c == TRUE) {

L = TRUE;

}
/* Rule 5. */

If (l == TRUE) && (M == TRUE) {

N = TRUE;

}
Step 1:

Facts = {a, b, c, d, e}

Rule 3 fires => Facts = {a, b, c, d, e, x}


Step 2:

Facts = {a, b, c, d, e, x}

Rule 4 fires => Facts = {a, b, c, d, e, x, l}
Step 3:

Facts = {a, b, c, d, e, x, l}

Rule 2 fires => Facts = {a, b, c, d, e, x, l, y}
Step 4:

Facts = {a, b, c, d, e, x, l, y}

Rule 1 fires => Facts = {a, b, c, d, e, x, l, y, z}


  • Here our rule search pattern always picked up from the last rule that fired and continued down the list.




  • When hit the bottom of the list we started at the top again.




  • What would happen if we always started at rule 1 and searched downward.




    • Would the results be different?

    • Would the path of reasoning be different?

    • Does it matter?




  1. Backward chaining – Given a likely conclusion, can we find the facts to support it. Goal driven reasoning.

Database Facts:


{a, b, c, d, e}
Rules:
/* Rule 1. */

If (y == TRUE) && (d == TRUE) {

Z = TRUE;

}
/* Rule 2. */

If (x == TRUE) && (b == TRUE) && (e == TRUE) {

Y = TRUE;

}
/* Rule 3. */

If (a == TRUE) {

X = TRUE;

}
/* Rule 4. */

If (c == TRUE) {

L = TRUE;

}
/* Rule 5. */

If (l == TRUE) && (M == TRUE) {

N = TRUE;

}
Step 1:

Facts = {a, b, c, d, e}

Goal = z; Rule 1 => z ; sub-goal required => y


Step 2:

Facts = {a, b, c, d, e}

Goal = y; Rule 2 => y ; sub-goals required => x, b, e; b and e exist, x is required
Step 3:

Facts = {a, b, c, d, e}

Goal = x; Rule 3 => x ; sub-goals required => none
Now we start forward chaining process to confirm that the goal z is supportable with the existing fact set.
Step 4:

Facts = {a, b, c, d, e}

Rule 3 fires => Facts = {a, b, c, d, e, x}
Step 5:

Facts = {a, b, c, d, e, x}

Rule 2 fires => Facts = {a, b, c, d, e, x, y}
Step 6:

Facts = {a, b, c, d, e, x, y}

Rule 1 fires => Facts = {a, b, c, d, e, x, y, z}



  1. Download 281.84 Kb.

    Share with your friends:
1   2   3   4   5




The database is protected by copyright ©ininet.org 2024
send message

    Main page