Models of expert and novice behavior

(Reference: Science, 20 June 1980, Vol. 208. no. 4450, pp. 1335 - 1342 "Expert and Novice Performance in Solving Physics Problems", Jill Larkin, John McDermott, Dorothea P. Simon, and Herbert A. Simon. )

Much of the early AI research was informed by a cognitive psychology model of human expertise. The model has two parts:

• LTM: A large long term memory (100,000s of patterns)
• STM: A (much) smaller short term memory (seven, plus/minus two)

Reasoning was, according to this mode: a match-act cycle:

1. Content of the STM matches patterns in the LTM
2. LTM patterns have actions when, when they fire, rewrites the STM contents
3. Goto 1.

In this model

• experts and experts because of the "power" patterns they have laboriously learned and added to their long term memory.
• novices are novices because they clog short term memory with irrelevant goals
• experts dodge that since their LTM patters tell them

Q: How to experts know what is relevant?

• A: feature extractors- gizmos that experts learn to let them glance at a situation and extract the salient details.
• E.g. chess experts can reproduce form memory all the positions on a chess board
• But if you show the same experts a gibberish game (one where all the rules are broken- e.g white pawns on white's back row) then they can't reproduce the board.
• Why? Well, when they glance at a board, their feature extractors fire to offer them a succinct summary. Gibberish boards baffle the feature extractors, so no summary

Enter rule-based programming

Much, much work on mapping this cognitive psychological insight into AI programs

Success story #1: PIGE (not well known)

(Reference: "An Expert System for Raising Pigs" by T.J. Menzies and J. Black and J. Fleming and M. Dean. The first Conference on Practical Applications of Prolog 1992 . Available from http://menzies.us/pdf/ukapril92.pdf )

PIGE: Australia's first exported rule-based expert systems

Written by me, 1987 who trapped the expertise of pig nutritionists in a few hundred rules.

• PIGE would find factors to control, try them on a simulator of a farm, then adjust its factors accordingly.
• Here's PIGE out-performing the experts:
• Why did PIGE success so well? Limits to short-term-memory. PIGE had none. The humans, on the other hand, had the standard human limitations

Success story #2: MYCIN (famous)

( V.L. Yu and L.M. Fagan and S.M. Wraith and W.J. Clancey and A.C. Scott and J.F. Hanigan and R.L. Blum and B.G. Buchanan and S.N. Cohen, 1979, Antimicrobial Selection by a Computer: a Blinded Evaluation by Infectious Disease Experts, Journal of American Medical Association, vo. 242, pages 1279-1282)

Given patient symptoms, what antibiotics should be prescribed?

Approx 500 rules.

Extensively studied:

Compared to humans, performed very well:

Why did it perform so well?

• Not because of the power of its algorithm (recursive descent through the rules- backward chaining)
• But only because of the knowledge in its rules
• In this case, algorithms, not knowledge, is power.

Success story #3: XCON and VT (very famous)

John McDermott, DEC, 1980s. Two systems:

• XCON, early 1980s, auto-configured DEC computers for customers. At its peak, 8,000 to 12,000 rules. Maintained by a team of 20 developers. Saving DEC (approx) $20M/year.
  (Reference: J. McDermott, 1993, R1 ("XCON") at age 12: lessons from an elementary school achiever, Artificial Intelligence, 59, 241-247)
• VT, mid to late 1980s, designer of elevators, 7000 rules.
  (Reference: ". Marcus and J. McDermott, 1989, (SALT): A Knowledge Acquisition Language for Propose-and-Revise Systems, Artificial Intelligence, 39, 1, pages1-37.)

The First AI Bubble

With strong theoretical support and excellent industrial case studies, the future for AI seemed bright.

Begin the AI summer (mid-1980s). Just like the Internet bubble of 2000: fledging technology, over-hyped, immature tool kits.

And after the summer, came the fall. Enough said.

Happily, then came the 1990s, data mining, and results from real-time AI planners, and stochastic theorem provers.

By 2003, I could say I was an AI-nerd and people would not run away.

Inside Rule-based programming

Here's a good introduction on rule-based programming. Read it (only pages 1,2,3,4,5,6,7) carefully to learn the meaning of:

• Conditions,
• Actions
• Backward chaining
• Forward chaining
• Working memory

Backward chaining supports how and why queries:

• How did you prove this goal?
• Why are you trying to prove this goal?

Forward chaining supports only how not why.

• Explain.

Define match, resolve, act

• With respect to the BAGGER system, define with examples conflict resolution using:
  • Rule ordering
  • Data ordering
  • Size ordering
  • Specificity ordering
  (Note: BAGGER is a toy example of how XCON configured computers.)

Rules: the Real Story

Rules- the good news

Some nice advantages for software engineering:

• Uniform representation simplified tool construction:
  • Rules are rules;
  • Feature extractors could be written as rules that run before anything else runs;
  • Conflict resolution operators could be written as rules.
• For example, CMU's SOAR language added a whole meta-layer called TAQL to handle:
  • Within each problem space: problem space proposal, problem space initialization;
  • For each state in a problem space: state initialization, state elaboration, state evaluation
  • For each operator that can jump you between states: operator proposal, operator selection, operator implementation, how to handle operator failure, operator evaluation
  And guess what- all this was code with rules!

But Rules Have Problems

As rule-based programs became more elaborate, their support tools more intricate, the likelihood that they had any human psychological connection became less and less.

As we built larger and larger rule bases, other non-cognitive issues became apparent:

• Speed: within match-resolve-act, 80% of the time is spend in match.
• Maintenance: any rule can change the working memory to effect any other rule. XCON was the commercial AI success story of the early 1980s and the maintenance nightmare of the mid-1980s.
  • What works for 400 rules does not work for 8000
  • At its peak, DEC was claiming it saved the, $20M/year but if any of XCON's 20 developer's left, ouch!

Note that both these problems come from the global nature of match: all rules over all working memory.

• A search by all rules through all possible working memory contents is slowwww.
• When humans maintain rules, understanding the connections between rules is difficult.

Improving Rule-based Programming

Solution #1: throw away rules.

Go to simpler representations. e.g. state machines (used in gaming, next lecture)

Solution #2: the RETE network

As used in many rule-based tools including OPS5, ART, JESS. Compile all the rules into a big network wiring all the conditions together.

• If 10 rules make the same test, represent the test once in the network.
• New facts get dropped into the top, bubble over the network, and matched actions pop out at the bottom.
• A little complex to implement (to say the least):
  
  • Alpha nodes; matching within one test (e.g. a ≤ 7);
  • Beta nodes: matching between tests (joins across tables)
  • But what is Type? select?dummy?
• RETE supports standard resolution operators: e.g.:
  • Specificity: number of links in the network;
  • Data ordering: when advancing over the net, work left to right, most recent to oldest
• Note: RETE changes some constant time factors in the search but does not tame the fundamental problem of all rules looking in all places all the time.

Solution #3: divide the global space

If searching/understanding all is too much, find ways to built the whole from local parts. Have separate rule bases for each part.

Q: How to divide the system?

1. A1: Using domain knowledge; e.g. from [Tambe91]:
2. A2: using background knowledge of problem solving types. Add tiny little specialized rule bases to the implement knowledge-level operators.

   E.g. here's Clancy's abstraction of MYCIN:

   And here's his abstraction of an electrical fault localization expert system:

   Note that the same abstract problem solving method occurs in both

   A whole mini-industry arose in the late 1980s, early 1990s defining libraries of supposedly reusable problem solving methods.

   e.g. Here's "diagnosis"
   

   Here's "monitoring":
   Note that you could write and reuse rules based to handle select, compare, specify.

   And there's some evidence that this is useful. Marcus and McDermott built rule bases containing 7000+ rules via role-limiting methods. That is, once they knew their problem solving methods, they write specialized editors that only let users enter in the control facts needed to just run those methods.

   • If you can't use it...
   • ... don't ask for it.

   For a catalog of problem solving methods, see Cognitive Patterns By Karen M. Gardner (contributors James Odell, Barry McGibbon), 1998, Cambridge University Press

Patch in context

We study AI to learn useful tricks. Sometimes, we also learn something about people. Here's a radically different, and successful, method to the above. What does it tell us about human cognition?

Ripple-down rules is a maintenance technique for rule-based programs initially developed by Compton. Ripple-down rules are best understood by comparison with standard rule-based programming. In standard rule-based programming, each rule takes the form

 rule ID IF condition THEN action

However, as these systems grew in size, it became apparent that rules were surprisingly harder to manage. One reason for this was that, in standard rule-based programming, all rules exist in one large global space where any rule can trigger any other rule. Such an open architecture is very flexible. However, it is also difficult to prevent unexpected side-effects after editing a rule. Consequently, the same rule-based programs hailed in early 1980s (XCON) became case studies about how hard it can be to maintain rule-based systems.

Many researchers argued that rule authors must work in precisely constrained environments, lest their edits lead to spaghetti knowledge and a maintenance nightmare. One such constrained environment is ripple-down rules that adds an EXCEPT slot to each rule:

 rule ID1 IF condition THEN EXCEPT rule ID2 THEN conclusion because EXAMPLE

Here, ID1,ID2 are unique identifiers for different rules; EXAMPLE is the case that prompted the creation of the rule (internally, EXAMPLEs conjunction of features); and the condition is some subset of the EXAMPLE, i.e., condition ⊆ EXAMPLE (the method for selecting that subset is discussed below). Rules and their exceptions form a ripple-down rule tree:

At run time, a ripple-down rule interpreter explores the rules and their exceptions. If the condition of rule ID1 is found to be true, the interpreter checks the rule referenced in the except slot. If ID2's rule condition is false, then the interpreter returns the conclusion of ID1. Else, the interpreter recurses into rule ID2.

(Note the unbalanced nature of the tree, most patches are shallow. This is a common feature of RDRs).

Ripple-down rules can be easier to read than normal rules:

But in practice, Compton advises hiding the tree behind a difference-list editor. Such an editor constrains rule authoring as follows:

• Recall that these rules are only ever added in response to some new EXAMPLE. That is, each rule is useful for at least one example.
• Hence ripple-down rules never delete old rules; rather they are patched with EXCEPT rules.
• These EXCEPT rules cover the special case that confused the parent rule. If the parent rule with condition1 has EXAMPLE1 and the new rule is being created in response to EXAMPLE2, then the new rule's condition2 must be formed from the features not used in the parent rule and must hold for the new EXAMPLE2; i.e.

  condition2 = EXAMPLE1 - condition1
  condition2 ⊆  EXAMPLE2
  

When users work in a difference list editor, they watch EXAMPLEs running over the ripple-down rules tree, intervening only when they believe that the wrong conclusion is generated. At that point, the editor generates a list of features to add to condition2 (this list is generated automatically from the above equations). The expert picks some items from this list and the patch rule is automatically to some leaf of the ripple-down rules tree.

Ripple-down rules are a very rapid rule maintenance environment. Compton et.al. report average rule edit times between 30 to 120 seconds for rule bases up to 1000 rules in size [Compton 2005]

AFAIK, ripple-down-rules are the current high-water mark in knowledge maintenance.

Q: what does this tell us about human knowledge?

1. Distinguish between classical logic and fuzzy logic. Your answer should include "membership function", "crisp", "fuzzy" and "set".
2. Define with examples, fuzzification, rule evaluation, de-fuzzification
3. Write down the three Zadeh operators. Illustrate each with a diagram.
4. Here is the truth table for classical logic

   A	B	A and B		A or B		not A
   --	--	-----------	--------	-------
   0	0	0		0		1
   0	1	0		1		1
   1	0	0		1		0
   1	1	1		1		0
   

   Reproduce this table using the Zadeh operators for (A B) = (0.3 0.7).
5. Define the extension principle and its implications for the connection of classical logic to fuzzy logic. Using the Zadeh operators, demonstrate the extension principle for row 2 or the above table. Show all calculations
6. Draw the following membership function for
   1. (a b crisp)= ( -50,50,0.1) and
   2. (a b crisp)= ( -50,50,1)

   (defun crisp (x a b crisp)
     "Return a point in a sigmoid function centered at (a - b)/2"
     (labels ((as100 (x min max)
   	     (+ -50 (* 100 (/ (- x min) (- max min))))))
       (/ 1 (+ 1 (exp (* -1 (as100 x a b) crisp))))))
   

   Mark on the x-axis the key points of the function.
7. Draw the following membership function for (x a b c) = (x 10 20 30).

   (defun fuzzy-fun1 (x a b c) 
     (max 0 (min (/ (- x a) (- b a))
   	      (/ (- c x) (- c b)))))
   

   Mark on the x-axis the key points of the function.
8. Draw the following membership function for (x a b c d) = (x 10 20 30 60).

   (defun fuzzy-fun2 (x a b c d)
     (max 0 (min (/ (- x a) (- b a))
   	      1
   	      (/ (- d x) (- d c)))))
   

   Mark on the x-axis the key points of the function.
9. On one plot, draw the following membership functions for (dist 'close) (dist 'medium) (dist 'far)

   (defun dist (d what)  
     (case what
       (range    '(close medium far))
       (close     (fuzzy-triangle   d -30 0 30))
       (medium    (fuzzy-trapezoid  d 10 30  50 70))
       (far       (fuzzy-grade      d 0.3  50 100))
       (t         (warn "~a not known to dist" what))))
   

   Mark on the x-axis the key points of these functions.

1. DFID
   1. Describe DFID
   2. Contrast DFID with breadth-first and depth-first search. Your answer should define breath-first an depth-first search, and the maximum running time and memory of each method.
   3. It can be shown that DFID visits all nodes with maximum frequency M(b,d) ≤ b^d*(1 - 1/b)^(-2) where b is the branching factor of the search space and d is the depth of the search, Here are some values from M(b,d)
      • When b=2, M(b,d) ≤ 4 * b^d
      • When b=3, M(b,d) ≤ 9/4 * b^d
      • When b=4, M(b,d) ≤ 16/9 * b^d
      • When b=5, M(b,d) ≤ 25/16 * b^d
      Using these values, describe when you would or would not recommend DFID. Make sure you explain your answers
2. ISSAMP
   1. Write down the pseudo-code for ISSAMP Make sure your code has line numbers. (Note the pseudo code for ISSAMP includes a "unit propagation" step which is a black box to you. Just assume it means "see what can be quickly inferred from the current solution").
   2. Explain the following using a paragraph or two of English and line numbers into your pseudo-code: ISSAMP search is
      • uniformed,
      • incomplete,
      • stochastic
      • does not use local search
      • uses restarts
      • and uses very little memory.
3. A* is a best-first search of graph with a *visited* list where states are sorted by "g+h". Explain all the terms in the prior sentence
4. MAXWALKSAT
   1. Write down the pseudo-code for MAXWALKSAT Make sure your code has line numbers.
   2. Explain the following using a paragraph or two of English and line numbers into your pseudo-code: MAXWALKSAT search is
      • sometimes uniformed,
      • incomplete,
      • stochastic
      • sometimes, uses local search
      • uses restarts
      • and uses very little memory.

A Sudoku puzzle:

One of the hardest Sudoku's ever found: the dreaded Al Escargot problem:

Encoding Sudoku into CNF (so it can be solved by,say, MAXWALKSAT.

Here s[x,y,z]=true means that the square at x,y has value z. The following rules expand into propositional formulae:

• and [x=0..8] and [y=0..8] or [z=1..9] then s[x,y,z]
• and [x=0..8] and [y=0..8] and [z=1..9] and [x'=0..8] s[x,y,z] -> x == x' or not s[x',y,z]
• and[x=0..8] and[y=0..8] and[z=1..9] and[y'=0..8] s[x,y,z] -> y == y' or not s[x,y',z]
• and[x=0..2] and[y=0..2] and[x'=0..2] and[y'=0..2] and[x''=0..2] and[y''=0..2] s[3*x + x', 3*y + y', z] -> x' == x'' and y' == y'' or not s[3*x + x'', 3*y + y'', z]

Note that the encoding can be very large. But that is the game with using MAXWALKSAT (how to encode a domain into the low level representation used by the solver).

Meta-lesson

As engineers, you need to sensibly select technologies. Some exciting candidate technologies are too bleeding edge, or too slow or cumbersome to use in practice. And you have to decide which is which.

The next two lectures offer examples of this process. Note that in both case, the gaming industry uses technology (b) while theoreticians prefer (a).

1. Handling uncertainty: from (a) abduction to (b) fuzzy logic;
2. Simulations: from (a) rule-based systems to (b) state machines

In your career you'll have to strike your own balance between the limitations of the simpler method (b) vs the extra functionality offered by the more complex method (a).

Reasoning and Uncertainty

The words figure and fictitious both derive from the same Latin root, fingere (to form, create). Beware! --M.J. Moroney

Everything is vague to a degree you do not realize :till you have tried to make it precise. --Bertrand Russell

I'm pretty certain that I need better ways to handle uncertainty. Many expressions of human knowledge are not crisp ideas. Rather, they are hedges, shades of gray.

Consider four problems in programming a game:

• Threat assessment: How many battalions to deploy when you don't have total knowledge of the enemies movements?
• Control: when chasing a target, you want to see some fluid gradual changes in tactics. Abrupt straight-line movements that suddenly change course would appear unnatural.
• Classification: how to combine information to yield hedge information like wimpy, easy, moderate, tough, formidable? How to combine these hedged classifications with other hedges to infer further information?
• How to do all the above that introduces some measure of unpredictability into the game?

The problem is that conventional principles of logic are very unfriendly towards uncertainty. In classical logic, things are either true or false. You do, you don't. Worse, if a model contains a single inconsistency, the whole theory is false. So one little doubt, one little "this or not this" and you are screwed. Not very helpful for introducing gradual degrees of hedged knowledge that may be contradictory.

This is not just a game playing problem. The drawbacks of classical logic are well known. Theoreticians like Lofti Zadeh offer a Principle of Incompatibility :

• "As the complexity of a system increases, our ability to make precise and yet significant statements about its behavior diminishes until a threshold is reached beyond which precision and significance (or relevance) become almost mutually exclusive characteristics."

• "It is in this sense that precise quantitative analyzes of the behavior of humanistic systems are not likely to have much relevance to the real worlds societal, political, economic and other types of problems which involve humans either as individuals or in groups."

Philosophers like Karl Popper claim that accessing 100% evidence on any topic a fool's goal. All "proofs" must terminate on premises; i.e. some proposition that we accept as true without testing, but which may indeed be wrong. In terms of most human knowledge, a recursion to base premises is fundamentally impractical. For example:

• Consider one individual trying to reproduce all the experiments that lead to our current understanding of atomic physics.
• Such an undertaking could longer than a lifetime and would be beyond the resources of most individuals (e.g. building a five kilometer long linear accelerator).
• Such a task has to be divided up and, sooner or later, our single researcher would have to accept on faith the validity of another researcher's statement that "while you were busy elsewhere, I did this, and I saw that. Trust me.".

There is much evidence for Popper's thesis. Gathering all the information required to remove all uncertainties can be very difficult:

• In the first study that isolated the thyroptin-releasing hormone (used in the brain), 300,000 sheep brains had to be filtered. This yielded 1.0 milligrams of purified hormone.
• The premise of the cs572 project is that we can't collect the information required to tune 28 variables in a software process model. I am continually surprised that this is the case. All software development organizations collect information but just try to access consistent samples of it!
• The (in)famous "Limits to Growth" study attempted to predict the international effects of continued global economic growth. Less than 0.1% of the data required for the models was available
• If the planet is too big, when is small small enough? In a complex system of only a modest number of variables and interconnections, any attempt to describe the system completely and measure the magnitude of all the links would be the work of many people over a lifetime

Experience with mathematical simulation suggest that an over-enthusiasm for quantitative analysis can confuse, rather than clarify, a domain. For systems whose parts are not listed in a catalog, which evolve together, which are difficult to measure, and which show unexpected capacity to form new connections, the results of (quantitative) simulation techniques have been less than impressive:

• The masses of data required make the procedure very costly.
• The demand for qualitative precision often forces the exclusion of many variables (e.g. stress in diabetes: poorly quantified but vitally important);
• the predictions apply only to the original single system from which the models were derived, and are not easily extended even to similar systems ([207], p4).

Anyway, why seek total knowledge? Some levels of uncertainty are a good thing:

• In a game simulation, you want some higglety pigglety . It would look unnatural if all leaves on all the trees all blow this way then that like soldiers on parade.
• When co-ordinating multiple agents, it is good to leave some room for local improvisation. Consider the phrase "close enough for jazz":
   
  While "close enough for jazz" sounds disparaging, it really isn't, in my view. The nature of jazz is to improvise on the basis of a known musical core, whether it's a melody or a set of harmonies. If it is TOO close to the original melody or other musical archetype, or too close for too long, it is no longer jazz, it's the original. "Close enough," it seems to me, would be close enough to recognize the musical skeleton behind what's being played, but not so close as to hamper the improvised self-expression at the heart of jazz.
  From SS.

Sometimes we can learn more by allowing some uncertainties. Creative solutions and insights can sometimes be found in a loosely constrained space than may be impossible in tightly constrained, certain spaces. For example,

• Enabling random search is a very useful tool. We have seen before that stochastic theorem provers have very nice generality properties.
• If we over fit our solutions to old data then our solutions may be brittle if any part of that old data changes. That is, even if total knowledge is available for a system, it can be useful to mutate that knowledge to see how changes to the background knowledge effect the outcome.
  • The premise of the NOVA project is that we don't want one solution. Rather, we want to find actions that are stable across the space of all possible solutions
  • In diagnosis, we may not want to explore scenarios that are exactly like prior knowledge of normal behavior. Rather, we want to explore abnormal deviations from normal. Also, in diagnosis, you can't reflect over multiple options unless your models can generate multiple options. That is, for diagnosis, you want models that can handle "don't know, it could be this or that".

• Q: do we call out the marines?
• A: depends on the size and proximity of the invading forces

             PROXIMITY
  SIZE       close   medium  far
  --------   ----------------------
  tiny       medium  low     low
  small      high    low     low
  moderate   high    medium  low
  large      high    high    medium
  

• (But how do we give meaning to all these symbols?.... see below.)

So we need to change classical logic. Uncertainty is unavoidable. Despite this, we persist and continue building systems of increasing size and internal complexity. Somehow, despite uncertainty, we can handle uncertainty and doubt and predict the future a useful percent of the time. How do we do it? How can we teach AI algorithms to do it?

Method #1: Fuzzy Logic

Officially, there are rules. Unofficially, there are shades of gray. Fuzzy logic is one way to handle such shades of gray.

For example, consider the rule ``if not raining then play golf''. Strange to say, sometimes people play golf even in the rain. Sure, they may not play in a hurricane but a few drops of rain rarely stops the dedicated golfer.

Fuzzy logic tries to capture these shades of gray. Our golf rule means that we rush to play golf in the sunshine, stay home during hurricanes, and in between we may or may not play golf depending on how hard it is raining.

Fuzzy logic uses fuzzy sets. Crisp sets have sharp distinctions between true and falsehood (e.g. it is either raining or not). Fuzzy sets have blurred boundaries (e.g. it is barely raining). Typically, a membership function is used to denote our belief in some concept. For example, here are some membership functions for the belief that a number is positive. All these beliefs have the same membership function:

 1/(1+exp(-1*x*crisp))

Or, in another form...

(defun crisp (x a b crisp)
  "Return a point in a sigmoid function centered at (a - b)/2"
  (labels ((as100 (x min max)
	     (+ -50 (* 100 (/ (- x min) (- max min))))))
    (/ 1 (+ 1 (exp (* -1 (as100 x a b) crisp))))))

(defun fuzzy-grade (x &optional (a 0) (b 1) (slope 0.1))
  (crisp x a b slope))

where the crisp parameter controls how sharp is the boundary in our beliefs:

Note that for large crisp values the boundary looks like classical logic: at zero a number zaps from positive to negative. However, in the case of our golfing rule, there are shades of gray in between sunshine and hurricanes. We might believe in playing golf, even when there is a little rain around. For these situations, our beliefs are hardly crisp, as modeled by setting crisp to some value less than (say) one.

The crisp value lets us operationalize a set of linguistic variables or hedges such as ``barely'', ``very'', ``more or less'', ``somewhat,'' ``rather,'' ``sort of,'' and so on. In this approach, analysts debrief their local experts on the relative strengths of these hedges then add hedge qualifiers to every rule. Internally, this just means mapping hedges to crisp values. For example:

  definitely: crisp=10
  sort of:    crisp=0.5
  etc

Alternatively, analysts can ask the local experts to draw membership functions showing how the degrees of belief in some concept changes over its range. For example:

Sometimes, these can be mapped to mathematical functions as in the following:

(defun fuzzy-triangle (x a b c) 
  (max 0 (min (/ (- x a) (- b a))
	      (/ (- c x) (- c b)))))

(defun fuzzy-trapezoid (x a b c d)
  (max 0 (min (/ (- x a) (- b a))
	      1
	      (/ (- d x) (- d c)))))

Note that the function need not be represented mathematically. If the local experts draw any shape at all, we could read off values from that drawing and store them in an array. For example, an analyst can construct an array of values for various terms, either as vectors or matrices. Each term and hedge can be represented as (say) a 7-element vector or 7x7 matrix. Each element of every vector and matrix a value between 0.0 and 1.0, inclusive, in what might be considered intuitively a consistent manner. For example, the term ``high'' could be assigned the vector

     0.0 0.0 0.1 0.3 0.7 1.0 1.0

and ``low'' could be set equal to the reverse of ``high,'' or

     1.0 1.0 0.7 0.3 0.1 0.0 0.0

Zadeh Operators

The AND, OR, NOT operators of boolean logic exist in fuzzy logic, usually defined as the minimum, maximum, and complement; i.e.

    [1]  truth (not A)   = 1.0 - truth (A)
    [2]  truth (A and B) = minimum (truth(A), truth(B))
    [3]  truth (A or B)  = maximum (truth(A), truth(B))

Or, in another form...

(defmacro $and (&rest l) `(min ,@l))
(defmacro $or  (&rest l) `(max ,@l))
(defun    $not (x)       (- 1 x))

When they are defined this way, the are called the Zadeh operators, because they were originally defined as such in Zadeh's original papers.

Here are some examples of the Zadeh operators in action:

 [1] truth (not A)   = 1.0 - truth (A)

 [2] truth (A and B) = minimum (truth(A), truth(B))

 [3]  truth (A or B)  = maximum (truth(A), truth(B))

Here are some more examples:

Here's yet another example

Some researchers in fuzzy logic have explored the use of other interpretations of the AND and OR operations, but the definition for the NOT operation seems to be safe.

Note that if you plug just the values zero and one into the definitions [1],[2],[3], you get the same truth tables as you would expect from conventional Boolean logic. This is known as the EXTENSION PRINCIPLE, which states that:

The classical results of Boolean logic are recovered from fuzzy logic operations when all fuzzy membership grades are restricted to the traditional set {0, 1}.

Example 1

Assume that we have some fuzzy sub membership functions for combination of TALL and OLD things defined as follows:

 function tall(height) {
  if (height < 5 ) return Zero;
  if (height <=7 ) return (height-5)/2;
  return 1;
 }

 function old(age) {
   if (age <  18) return Zero;
   if (age <= 60) return (age-18)/42;
   return 1;
 }

 function a(age,height)   { return FAND(tall(height),old(age)) }
 function b(age,height)   { return FOR(tall(height), old(age)) }
 function c(height)       { return FNOT(tall(height)) }
 function abc(age,height) { 
        return FOR(a(age,height),b(age,height),c(height)) }

(The functions FNOR, FAND, FOR are the Zadeh operators.)

For compactness, we'll call our combination functions:

    a = X is TALL and X is OLD
    b = X is TALL or X is OLD
    c = not (X is TALL)
    abc= a or b or c

Here's the OLDness functions:

Here's the TALLness function:

Here's (c); i.e. the not TALLness function:

Here's (a): TALL and OLD

Here's (b): TALL or OLD

Here's (abc): a or b or c

In practice

Methodology, a fuzzy logic session looks like this:

Fuzzification:

Using membership functions, describe a situation.

Rule evaluation:

Apply fuzzy rules (e.g. using the Zadeh operators)

Defuzzification:

Obtaining the crisp or actual results:

• Apply some threshold to declare than any fuzzy belief over (e.g.) 0.2 is true and all others are false.
• Translate the resulting beliefs back through the membership functions to get a linguistic summary of the conclusion; e.g. happy is sort of true.
• Return the centroid of the computed membership function. This process can be very complex (using full integrals) or, as the following example shows, very simple.

  Suppose we have an output fuzzy set AMOUNT which has three members: ZERO, MEDIUM, and HIGH. We assign to each of these fuzzy set members a corresponding output value, say 0 for Zero, 40 for MEDIUM, and 100 for HIGH. A Defuzzification procedure might then be:

   return (ZERO*0 + MEDIUM*40 + HIGH*100)/(0+40+100)

Example 2: Do we Call out the Marines?

How close is the enemy?

• Close, medium, far?

How large is the enemy's forces?

• Tiny, small, moderate, large?

What is the size of the threat?

           PROXIMITY
SIZE       close   medium  far
--------   ----------------------
tiny       medium  low     low
small      high    low     low
moderate   high    medium  low
large      high    high    medium

We need some membership functions:

(defun dist (d what)  
  (case what
    (range    '(close medium far))
    (close     (fuzzy-triangle   d -30 0 30))
    (medium    (fuzzy-trapezoid  d 10 30  50 70))
    (far       (fuzzy-grade      d 0.3  50 100))
    (t         (warn "~a not known to dist" what))))

(defun size (s what)
  (case what
    (range    '(tiny small moderate large))
    (tiny      (fuzzy-triangle  s -10 0 10))
    (small     (fuzzy-trapezoid s 2.5 10 15 20))
    (moderate  (fuzzy-trapezoid s 15 20 25 30))
    (large     (fuzzy-grade     s 0.3 25 40))
    (t         (warn "~a not known to size " what))))

And we'll need to model the above table:

(defun fuzzy-deploy (d s what)
  (macrolet (($if (x y) `($and (dist d ',x) (size s ',y))))
    (case what
      (range    '(low medum high))
      (low       ($or ($if medium tiny)
		      ($if far    tiny)
		      ($if medium small)
		      ($if far    small)))
      (medium    ($or ($if close  tiny)
		      ($if medium moderate)))
      (high      ($or ($if close  small)
		      ($if close  moderate)
		      ($if close  large)
		      ($if medium moderate)))
      (t         (warn "~a not known to fuzzy-deploy" what)))))

Finally, we need a defuzzication function:

(defun defuzzy-deploy (&key distance size)
  "Return how many marines to deploy?"
  (let ((low    (fuzzy-deploy distance size 'low   ))
	(medium (fuzzy-deploy distance size 'medium))
	(high   (fuzzy-deploy distance size 'high  )))
    (round 
     (/ (+ (* 10 low) (* 30 medium) (* 50 high))
	(+ low medium high)))))

So, how many marines to deploy?

(defuzzy-deploy :distance 25 :size 8)) ==> 19

Method #2: Abduction

Digression

(What I'm about to say seemed like a good idea at the time- early 1990s. But most folks who took this seriously ran into computational problems and had to switch from discrete-space logic to some continuous variant. However, IMHO, recent empirical stochastic results suggest that this all might be worth a second look. And, much to my surprise, I see that others think the same.

Also, technically speaking, what I'm about to show you is my own local variant of abduction called graph-based abduction that comes from my 1995 Ph.D. thesis. For a more general treatment, that is more standard, see Bylander T., Allemang D., Tanner M.C., Josephson J.R. The computational complexity of. abduction, Artificial Intelligence Journal 49(1-3), pp. 25-60, 1991.)

Uncertainty and Topology

Republicans aren't pacifists by quakers are. Is Nixon (who was both a republican and a quaker) a pacifists?

This is a horrible problem. Observe that it can't be solved by sitting at the Nixon note and querying his immediate parents. You have to search into the network for contradictory conclusions. That is, it can't be solved by some fast local propagation algorithm.

If you can't gather more information, you have two options:

• Skeptical : since Nixon can neither be proved to be a pacifist nor the contrary, no conclusion is drawn. This is the approach of classical logic (one contradiction? throw out everything and run home crying).
• Credulous: since Nixon can be proved to be a pacifist in at least one case, he is believed to be a pacifist; however, since he can also be proved not be a pacifist, he is also believed not to be a pacifist. Note that option 2 means forking different worlds of beliefs then reasoning separately about each world. This can lead to an intractable explosion of beliefs if, as we explore quaker-ness and republican-ness we find that we must generate even more worlds of belief.

Alternatively, if we are allowed to probe the world for more information, we can:

• Identify the base sources of the contradictions
• Design the smallest number of probes that remove the most number of contradictions, thus reducing the number of worlds.

That is, unlike fuzzy logic (where everything is quickly inferred from hard-wired numbers set at design time), here we must extract and explore the topology of our doubts, then probe the key points.

Formally, this is abduction.

Abduction, induction, deduction

Welcome to abduction, the logic of "maybe". Abduction can be contrasted with induction and deduction as follows:

• If a -> b are a set of rules and a,b are antecedents and consequences then..
• DEDUCTION is matching the rules to the antecedents to find the consequences;

  rules + antecedents
  ==>
  consequences
  

• INDUCTION means taking lots of antecedents,consequences and learning the rules:

  <antecedent,consequence>
  <antecedent,consequence>
  <antecedent,consequence>
  <antecedent,consequence>
  ==>
  rules
  

• ABDUCTION means matching the rules to the consequence to find antecedents that could explain the consequence

  rules + consequences
  ==>
  antecedents 
  
  

  Note that abduction is not a certain inference since there may exist multiple rules that explain the consequence. For example:
  • rule1: If sprinkler then wet grass
  • rule2: If rain then wet grass
  • consequence: wet grass
  • Abduce: consequence = rain
    • Not a certain inference

In practice, all these methods run together:

(That's the official story. My own experience is that by the time you get an abductive device going, you have much of the machinery required for deduction and induction. But don't tell anyone,)

Formally

Formally, abduction looks like this:

1. Theory and assumptions => goal; i.e. do something
2. not(Theory and assumptions => error); i.e. don't do dumb things.

Without rule2, abduction becomes deduction:

• Athletes on steroids. Go! Run to conclusions

With rule2, abduction gets very slow:

• Replace you athletes with nervous accountants
• After shuffling forward a few yards they realize that they are in the wrong order (violating rule2).
• So the race stops while they sort out who should be first, second, third..
• Worse case,
  • They realize they can't all run this race together and the race must fork into worlds
  • Now several races are run and not everyone finishes the same race.

That is, when the accountants run the race, rules 1 & 2 have to be modified:

3. Theory' ⊆ Theory
4. goals' ⊆ goals
5. Theory' and assumptions => goal'
6. not(Theory' and assumptions => error)

Assumptions define worlds of belief.

• Internally consistent
• Maximal w.r.t. size
• No world contains another world

Assumptions come in two forms:

• Some assumptions are controversial (conflict with other assumptions) and so do not. Those that do not do not drive world generation.
• Some assumptions dependent on other assumptions and some do not. Those that don't are base.

Note that the least informative assumptions are the non-base, non-controversial assumption (the yawn set).

(BTW, is your head spinning yet? Don't you wish we were still doing fuzzy logic?)

Example

An example makes all this clear. Here's a theory:

In this example, our inputs are:

• foriegnSales=up
• domesticSales=down

Our goals are to explain the outputs:

• investorConfidence=up
• wages=down
• inflation=down

We have some background knowledge

• Variables X,Y,etc have the range {up,down}.
• X=up and X=down is an error
• X++Y is consistent with
  • X=up and Y=up
  • X=down and Y=down
• X-Y is consistent with
  • X=up and Y=down
  • X=down and Y=up

The above theory supports the following consistent chains of reasons that start at the inputs and end at the outputs:

1. foriegnSales=up, companyProfits=up, investorConfidence=up
2. domesticSales=down , inflation=down,
3. domesticSales=down, companyProfits=down, wages=down
4. domesticSales=down, inflation=down, wages=down

In the above, companyProfits=up and companyProfits=down are controversial assumptions. They are also base since they depend on no upstream controversial assumptions.

We say that one world of belief is defined by each maximal consistent subsets of the base controversial assumptions. By collecting together chains of reasons consistent with each such subset, we find two worlds:

• Worlds1= paths {a,b,d}
• World2= paths {b,c,d}

So our example leads us to two possibilities:

Applications of Abduction

Each world is internally consistent (by definition) so predictions can be made without checking for inconsistencies. So, ignoring the world generation cost (which can be scary), the subsequent prediction cost is very cheap.

Note the connection of abduction to deduction and induction.

• In this framework, deduction is just running prediction from the inputs.
• As to induction, of it turns out that (say) world1 generates the best predictions then we can induce that the companyProfits to wages link is ignorable.

When multiple worlds can be generated and a best operator selects the preferred world: i.e.

• Equations 3,4,5,6 generate world(s)
• Believed = (best(words) ⊆ worlds)
• Hint: to find the worlds. seek maximal w.r.t. size consistent subsets of the base controversial assumptions. As described above, one world exists for each such subset.

Different applications for abduction arise from different best operators: For example, classification is just a special case of prediction where some subset of the goals have special labels (the classes).

Another special case of prediction is validation where we score a theory by the maximum of the number of goals found in any world. This is particularly useful for assessing theories that may contain contradictions (e.g. early life cycle requirements).

Yet another special case of prediction is planning. Here, we have knowledge of how much it costs to use part of the theory and planning-as-abduction tries to to maximize coverage of the goals while minimizing the traversal cost to get to those goals. Note that, the directed graph in the generated worlds can be interpreted as an order of operations.

Monitoring can now be built as a a post-processor to planning. Once all the worlds are generated, we cache them (? to disk). As new information arrives, any world that contradicts that new data is deleted. The remaining worlds contain the remaining space of possibilities.

Minimal fault diagnosis means favoring worlds that explain most diseases (goals) with the fewest inputs; i.e.

• maximize world ∩ goals and
• minimize world ∩ In

Probing is a special kind of diagnostic activity that seeks the fewest tests that rule out the most possibilities. In this framework, we would eschew probes to non-controversial assumptions and favor probes to the remaining base assumptions.

The list goes on. Explanation means favoring worlds containing ideas that the user has seen before. This implies maintaining a persistent user profile storing everything the user has seen prior to this session with the system.

Tutoring is a combination of explanation and planning. If the best worlds we generate via explanation are somehow sub-optimum (measured via some domain-specific criteria) we use the planner to plot a path from the explainable worlds to the better worlds. This path can be interpreted as a lesson plan.

The list goes on. But you get the idea. We started with uncertainty and got to everything else. Managing uncertainty is a core process in many tasks. Abduction as a unifying principle for implementing uncertain reasoning. One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them

Well, we all know what comes next...

Abduction: Complexity and solutions

Abduction belongs to a class of problems called NP-hard. That is, there no known fast and complete algorithm for the general abductive problem. And we say that after decades of trying to find one.

So if everything is abduction then everything is hard. Hmmm... sounds about right.

But I gave up on abduction when all my abductive inference engines ran into computational walls. The following runtimes come from validation-as-abduction using an interpreted language on a 1993 computer. But the general shape of this graph has been seen in other abductive inference engines.

But I'm starting to think I should come back to abduction. Here's one experiment with an ISSAMP-style world generation method for validation-as-abduction. Repeatedly, this abductive inference engine built one consistent world, making random choices as it went. The algorithm terminated when new goals stopped appearing in the generated worlds. This algorithm ran in polynomial time (as opposed to the complete validation-as-abduction method shown on the left.

It is hardly surprising that an incomplete random search runs faster than a complete one. But the real significant finding was that in the region where both algorithms terminated, the random search found 98\% of the goals found by the complete search.

Why? Well, that's another story for another time but if you are interested, then read this (which is an ok paper) or this (which is a really nice paper).

Fuzzy Logic or Abduction or ... ?

By now you probably have a pretty strong view on the relative merits of fuzzy logic or abduction (implementation complexity, generality, etc). So what are you going to use in your commercial AI work?

Well, that depends. If you are just playing games then what-the-hell, use fuzzy logic.

And if you are trying to diagnose potentially life threatening diseases using the least cost and fewest number of invasive procedures, you might consider the complexity of abduction well worth the implementation effort.

But you're engineers- you decide.

There is a sad truth to the world today. I am part of a dying breed of people known as "shell users." We are an old-fashioned bunch, preferring the warm glow of a green screen full of text over the cold blockiness of a graphical interface. We use ssh, scp, and even occasionally ftp. Back in the days before high-speed connections ("broadband"), we would dial up during off-hours to avoid being slammed with huge phone bills. The whole "Microsoft Windows" fad will fade away sooner or later, but in the interim, our kind is facing extinction.

Because there are fewer and fewer of us, I must help keep our lineage alive. I am looking for someone to help me do this. I need a woman (obviously) who is willing to raise a child with me in the method of Unix. Our child will be introduced to computers at a young age, and will be setting emacs mode before any other child can even read. I earn a sufficient income to support a family in modest comfort. Other than the fact our child will be bright, text-based and sarcastic, we will otherwise be a normal family. We will even go to Disney World and see Mickey Mouse.

So, if you are a woman between the ages of 23 and 43 who is ready to raise a child in the way of the shell, let me know so we can begin the process. (If you are ready to raise more than one child, even better.)

PS - yes, this is for real. Given the right person, I would obviously propose before we ... call fork().

PPS - I only set emacs mode for my ksh session. I only edit files using vi. Just wanted to clear that up. And I'm looking to raise the child(ren) as a dedicated couple, so if you aren't interested in being married, you may wish to select() a different posting.

N.B. - on the issue of relocation. I live in a place where my income/expense ratio is proper (i.e., greater than 2:1). I'm willing to live anywhere in the world where this remains true. I've been to much of the country as well as foreign nations. There are no limits to where I will live *so long as the job market for unix admins is robust enough to be sustainable.* And yes, I am interested in a strictly monogamous situation. I've been known to actually turn down offers of "two chicks at the same time."

Location: Typical Rich Town, CT
it's NOT ok to contact this poster with services or other commercial interests
Original URL: http://www.craigslist.org/about/best/nyc/485967082.html

• My search lecture.
• My cognitive science lecture

• Norvig, section 6.4 and the associated LISP file.
• Re-read my search lecture.
• Read my cognitive science lecture

• Define them. Where possible, your definition should include terms like combiner, ranker, cost function, h(x).
• Characterize their maximum memory and run time in terms of a search tree's branching factor "b" and search tree depth "d".
• Comment on whether or not the algorithm s guaranteed to find an optimal solution.
• Comment on under what conditions the the algorithm will not return an acceptable solution.

1. Functional programming and sorting
   1. Read http://www.n-a-n-o.com/lisp/cmucl-tutorials/LISP-tutorial-21.html. Write an anonymous lambda function that returns t if the car one list is numerically less than the car of another.
   2. Write an example of using the above to sort a list ((10 . a ) (5 . b ) (20 . c)) Do not use the :key argument.
   3. Read http://www.delorie.com/gnu/docs/emacs/cl_50.html. Using string-lessp and :key, write the "words-sort" function needed for the following function. (defun sort-words-demo () (words-sort '(i have gone to seek a great perhaps)))
2. Search control
   • Write an anonymous lambda function that returns true if some argument x equals the value 12.
   • Write a successors function for a binary tree that returns a list containing "twice the passed argument" and "twice the argument plus one"
   • Write a successor function of a finite tree that calls the above successor function and prunes any successors greater than some value n.
3. Search
   • Give an example of an ordered search problem.
   • Give an example of an unordered search problem.
   • Consider the task of leaving the class and arriving at downtown Morgantown. How can this task be characterized in terms of [N,A,S,G], g(x), h(x), d and b.
   • Consider this generic search function:

     (defun tree-search (states goal-p  successors combiner)
     	 (labels ((next  ()       (funcall successors (first states)))
     	          (more-states () (funcall combiner   (next) (rest states))
     	    (cond ((null states) nil)                              ; failure. boo!
     	          ((funcall goal-p (first states)) (first states)) ; success!
     			  (t  (tree-search                                 ; more to do
     			       (more-states) goal-p successors combiner))))
     

   • Starting a number "1", give an example of depth first search using "tree-search". Hints: 1) you may use the functions described in the above questions. 2) In DFS, new states are "combiner"-ed to the end of the current states./
   • Starting a number "1", give an example of beam first search using "tree-search". Hints: 1) beam search is a breadth first search that sorts the list of states according to some predicate. 2) In BFS, new states are "combiner"-ed to the beginning of the current state.

For example, here's a file misc/search1-exe.lisp that builds a stand-alone executable for the NOVA system.

(load "make.lisp")
(load "apps/search1.lisp")

(defun search1-and-quit ()
  (search1)
  (quit))

(save-lisp-and-die "tmp/search1" 
		   :toplevel 'search1-and-quit
		   :executable t )

Note that:

• This file loads a bunch of files
• Defines a top-level program that does the work, then (quit)s LISP
• Calls save-lisp-and-die

If this is loaded into LISP, then the system is made and saved to disk. Then...

cd tmp
./search1 --noinform

That's the good news. The bad news is that the executable contains all of LISP. The example above generated a 24MB file from less than 2000 lines of LISP. Oh well.

1. Write a function to exponentiate , or raise a number to an integer power.
   For example: (power 3 2)= 3*3 = 9
   Do it three ways (and, for a hint, see here)
   1. Do it using a looping construct (no recursion).
   2. Do it using a recursive call to the same top-level function
   3. Do it using a helper function defined inside the top-level function.
   
   
2. Write a function that counts the number of times an expression occurs anywhere within another expression. Example:
   (count-anywhere 'a '(a ((a) b) a)) ==> 3
   Hint: your function should recurse on all parts of the list.
    
   
3. Consider the following function:
   1. what do apply, append, mapcar do?

      (defun mappend (fn list)
        (apply #'append (mapcar fn list)))
      

   2. What is the output of this code?

      (defun numbers-and-negations (input)
          (mappend #'number-and-negation input))
      
      (defun number-and-negation (x)
        "If x is a number, return a list of x and -x."
          (if (numberp x)
      	     (list x (- x))
              nil))
      

   
   
4. Write grammars recording the steps required to achieve some goal:
   1. For getting a university degree e.g.

      (defparameter *education*
      		'((graduate -> preschool high-school undergrad)
      		  (high-school -> grade-school high-years)
      		  (high-years -> hiyear1 hiyear2 hiyear3 hiyear4)
      ...)
      

   2. Your grammar should support stochastic plan generation. Does it? Why?
   3. Repeat the above for the task of assembling a car.
   4. Augment the grammar with some benefit score in the head and some cost score in the tail (so when a goal is achieved, we add that to a "hooray!" score while adding the cost of the tail to some "boo!" score)

Globals are bad; side-effects from one function can ruin another.

With LISP's local-global trick you can have it both ways. A global is copied to a local temporary that can be referenced by called functions called from some master function. BUT, and here's the the trick, all changes made by this sub-functions just go away when they terminate.

Here's how it works. First, define global parameter:

(defparameter *x* 1)

Now, define a main function that calls some worker function.

(defun main()
  (format t "before ~a~%" *x*)
  (worker)
  (format t "after ~a~%" *x*)
)

The worker changes the scope of the global using the "&optional" command, then calls some underlings to get the job done.

(defun worker (&optional (*x* *x*))
  (underling)
)

(defun underling ()
  (format t "during1 ~a~%" *x*)
  (dotimes (i 3)
    (incf *x* i)
    (format t "during2 ~a~%" *x*)))

Now, when the worker is call, all the changes made by the underlings disappear when the work is done. Observe in the following how the underling makes many changes to "*x*" which are gone when the worker terminates:

CL-USER> (main)
before 1
during1 1
during2 1
during2 2
during2 4
after 1

(defun sum (&rest nums)
  (let ((sum 0))
    (dolist (one nums sum)
      (incf sum one))))  

E.g.

(SUM 1 1 1 1 2 2 4 100) => 112

And, if you want the mean value, divide the sum by the number of items in the list:

(defun mean (&rest nums)
  (let ((sum 0)
        (n   0))
    (dolist (one nums (/ sum n))
      (incf n)
      (incf sum one))))

(MEAN 1 1 1 1 2 2 4 100) => 14

LISP functions can also return more than one value using the "values" keyword. Here, we compute mean and standard deviation of a set of numbers.

(defun mean-sd (&rest nums)
  (let ((sum 0)
        (n   0)
        (sumSq 0))
    (labels ((mean () (/ sum n))
             (sd   () (sqrt (/ (- sumSq(/ (* sum sum) n)) (- n 1) ))))
      (dolist (one nums)
         (incf n)
         (incf sum   one)
         (incf sumSq (* one one)))
      (values 
       (mean) 
       (sd)))))

(MEAN-sd 1 1 1 1 2 2 4 100) => 14 34.764515

We can use the same kind of function to return the median and the "spread" of a set of numbers. The median value is the point at which half the values lie below it:

• If a sorted list of numbers is of odd size, it is just the middle value.
• However of that list is of even size, then it is some number in between the middle two values.

This list also returns "spread", i.e. the difference between the 50% and 75% value. "Spread" (not the official technical name) is useful for measuring the expected deviation from the median.

(defun median (&rest nums) 
  "return 50% and (75-50)% values"
  (let* ((n1         (sort nums #'<))
         (l          (length n1))
         (mid        (floor (/ l 2)))
         (midval     (nth mid  n1))
         (75percent  (nth (floor (* l 0.75)) n1))
         (50percent  (if (oddp l) 
                         midval
                         (mean midval (nth (- mid 1) n1)))))    
    (values  
     50percent
     (- 75percent 
        50percent))))

(MEDIAN 1 1 1 1 2 2 4 100) => 3/2 5/2

(Oh, and in case there are there are typos in the following, the on-line code is here.)

(maker :files files2load :faslp boolean)

"Maker" is a lisp function that, optionally, pre-processes textual .lisp files into a binary fast load .fasl format.

#+SBCL (DECLAIM (SB-EXT:MUFFLE-CONDITIONS CL:STYLE-WARNING))

(defun maker ( &key files 
	       faslp   ; if nil,  just load, don't fasl
	       forcep  ; always force a re-compile?
	      )
  (labels ; some one-liners for compiling and loading files
      ((filename (x y)     (string-downcase (format nil "~a.~a"  x y)))
       (src      (f)       (filename f "lisp"))
       (bin      (f)       (filename f "fasl"))   
       (newerp   (f1 f2 )  (> (file-write-date f1)  
			      (file-write-date f2)))
       (compile? (src bin) (or forcep
			       (not (probe-file bin))
			       (newerp src bin)))
       (update   (f)       (if (compile? (src f) (bin f)) 
			     (compile-file (src f))))
       (cake     (f)       (update f) (load (bin f)))
       (loader   (f)       (format t ";;;; FILE: ~a~%" f) (load f))
       (make1    (f)       (if faslp 
			       (cake f) 
			       (loader (src f)))))

    (mapc #'make1 files)))

The slow way: "(maker :files files2load)"

In this first example, we turn off fasl pre-processing and load stuff the slow way:

(defun make-slow () 
  "list your files to load"
  (maker   :files '( 
		  macros
		  eg
		  lib
		  guess-db
		  config
		  guess
		  coc-lib
		  demos
		  )))

Faster: "(maker :faslp t :files files2load)"

In this example, we enable fasl pre-processing. Note that a new file is created in the current directory and, if the .lisp file ever has a new change date than the .lisp file, fasl pre-processing is repeated.

(defun make-fast () 
  "list your files to load"
  (maker  :faslp t 
          :files '( 
		  macros
		  eg
		  lib
		  guess-db
		  config
		  guess
		  coc-lib
		  demos
		  )))

And the winner is...

In the usual case, only a few source files are ever changed so fasl pre-processing is required for only a small part of the system.

In the worst case, all the files are loaded the slow way.

In the best case, everything has been fasl-ed so "compilation" becomes "just load the fasls".

The following times just compare the worst case with the best case:

(time (make-slow))

Evaluation took:
  0.975 seconds of real time
  0.912261 seconds of user run time
  0.050491 seconds of system run time
  [Run times include 0.103 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  44,846,872 bytes consed.
(MACROS EG LIB GUESS-DB CONFIG GUESS COC-LIB DEMOS)

(time (make-fast))

Evaluation took:
  0.175 seconds of real time
  0.164378 seconds of user run time
  0.005954 seconds of system run time
  0 calls to %EVAL
  0 page faults and
  9,153,928 bytes consed.
(MACROS EG LIB GUESS-DB CONFIG GUESS COC-LIB DEMOS)

Solution 1: recursion with funky initializations in variable list:

(defun n1   (&optional (x 1000)) 
  (if (< x 0) 
      0
      (+ x (n1 (- x 1))))) 

Solution 2: recursion but using helper function called by the main worker with defaults:

(defun n2 ()
  (labels 
      ((n0 (x)
	 (if (< x 0)
	     0
	     (+ x (n0 (- x 1))))))
    (n0 1000))) 

Solution 3: no recursion:

(defun n3 ()
  (do* ((x   1000 (1- x))
	(sum x    (+ sum x)))
       ((< x 0) sum))) 

Timings:

(defun ns ()
  (let ((r 100000)) 
      (print   t) (time (dotimes (i r) t)) 
      (print 'n1) (time (dotimes (i r) (n1))) 
      (print 'n2) (time (dotimes (i r) (n2))) 
      (print 'n3) (time (dotimes (i r) (n3)))))

Results:

CL-USER> (ns)

T 
Evaluation took:
  0.0 seconds of real time
  1.03e-4 seconds of user run time
  2.e-6 seconds of system run time

N1 
Evaluation took:
  3.167 seconds of real time
  3.154306 seconds of user run time
  0.002845 seconds of system run time

N2 
Evaluation took:
  2.818 seconds of real time
  2.812621 seconds of user run time
  0.001603 seconds of system run time

N3 
Evaluation took:
  0.705 seconds of real time
  0.703598 seconds of user run time
  5.08e-4 seconds of system run time

Conclusions:

Recursion increased runtimes by a factor of around 4.
• Keyword tricks added little to the runtime (2.818 secs to 3.167 secs)

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

• Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.

For example, say there is some code "(demo456)" that does "something". In SBCL, this is how we could learn where the time goes.

First, we need a list of functions to profile:

(defun profiles () 
  (sb-profile:profile
				?bag
				?dr
				?elt
				?em
				?num
				?one-a
				?one-b
				...
   ))

Hint: to get a list of all functions in the lisp code in a directory, run

grep defun *.lisp | gawk '{print $2}' 

Then add this code to your lisp interpreter:

(defun watch (code)
  (sb-profile:unprofile)
  (sb-profile:reset)
  (profiles)
  (eval code)
  (sb-profile:report)
  (sb-profile:unprofile)
)

Then, "watch" something:

(watch '(demo456))

This outputs something like this:

CL-USER> (watch '(demo456))
WARNING: ignoring undefined function @DR
  seconds  |   consed   |  calls  |  sec/call  |  name  
----------------------------------------------------------
     0.143 |  2,781,184 | 170,000 |   0.000001 | EM2EFFORT
     0.101 |  2,813,952 | 170,000 |   0.000001 | EM2CIN
     0.100 |  2,658,304 | 170,000 |   0.000001 | EM2DIN
     0.067 |  2,678,784 | 170,000 |  0.0000004 | EM2RIN
     0.065 |    413,696 |  50,000 |   0.000001 | SF2EFFORT
     0.033 |    348,160 |  50,000 |   0.000001 | SF2CIN
     0.027 |    172,032 |  30,000 |   0.000001 | DR2ROUT
     0.024 |    192,512 |  30,000 |   0.000001 | DR2COUT
     0.023 |    421,888 |  50,000 |  0.0000005 | SF2RIN
     0.021 |    401,408 |  50,000 |  0.0000004 | SF2DIN
     0.008 |    167,936 |  10,124 |   0.000001 | MY-RANDOM
     0.001 |          0 |      28 |   0.000033 | GETA
     0.001 |          0 |       5 |   0.000180 | ?SF
     0.000 |          0 |       1 |   0.000000 | POINT-TO-LINE
     0.000 |          0 |       1 |   0.000000 | LINE-Y
     0.000 |          0 |       1 |   0.000000 | INIT-DB
     0.000 |          0 |      27 |   0.000000 | GUESS
     0.000 |    172,032 |  30,000 |   0.000000 | DR2DOUT
     0.000 |          0 |       1 |   0.000000 | COCOMO-DEFAULTS
     0.000 |          0 |       1 |   0.000000 | ?ONE-B
     0.000 |          0 |       1 |   0.000000 | ?ONE-A
     0.000 |          0 |      17 |   0.000000 | ?EM
     0.000 |          0 |      25 |   0.000000 | ?ELT
     0.000 |          0 |       3 |   0.000000 | ?DR
     0.000 |          0 |      25 |   0.000000 | ?BAG
----------------------------------------------------------
     0.613 | 13,221,888 | 980,260 |            | Total

estimated total profiling overhead: 4.69 seconds
overhead estimation parameters:
  1.8e-8s/call, 4.784e-6s total profiling, 2.264e-6s internal profiling

These functions were not called:
 ?NUM ?QUANTITY AS-LIST COC-LIB1 DEMO DEMO-GUESS DEMO-GUESS1 DEMO123 DEMOF
 EG EG0 EGS GUESS-DEMO-ALL GUESS0A GUESS0B GUESS0C GUESS0D GUESS0E GUESS0F
 GUESS0G HINGED-LINE HINGED-LINE-COQUALMO MAKE MAKER MY-COMMAND-LINE
 MY-GETENV PIVOTED-LINE SYM-PRIM ZAP ZAPS
NIL
CL-USER> 

Looking at the above, if we can speed up "em2effort", "em2cin" and "em2din" then we'd halve the runtime.

But what about the related task of profiling all your code? The code http://unbox.org/wisp/var/timm/08/ai/src/profile.lisp illustrates one method.

*lisp-funs*

That code contains a list of all symbols in a standard release of Common LISP and SBCL:

(defparameter *lisp-funs* '(
			    *
			    *
			    **
			    ***
			    +
			    +
			    ++
			    +++
			    -
			    -
			    /
			    /
			    //
			    ///
			    1+
			    1-
			    <
			    <=
			    =
			    >
			    >=
			    abort
			    abs
			    acons
			    acos
                 
                etc
))

(my-funs)

(defun my-funs ()
  (let ((out '()))
    (do-symbols  (s)
      (if (and (fboundp s)
	       (find-symbol  (format nil "~a" s) *package*)
	       (not (member s *lisp-funs*)))
	  (push s out)))
    out))

(watch code)

With "my-funs", we can write a "watch" macro that wraps the SBCL profiling calls:

(defmacro watch (code)
  `(progn
    (sb-profile:unprofile)
    (sb-profile:reset)
    (sb-profile:profile ,@(my-funs))
    (eval ,code)
    (sb-profile:report)
    (sb-profile:unprofile)
    t)
)

Example: (watch (main))

With all the above, then we can profile all the functions called from some high-level "(main)" function, as follows:

(watch (main))

The result is a standard SBCL profiler output. Note that, in the following, the "!" function takes 0.447/0.707 (i.e. over half) the run time. So if we are going to optimize anything, optimize "!".

CL-USER> (watch (main))
  seconds  |   consed   |   calls   |  sec/call  |  name  
------------------------------------------------------------
     0.447 |          0 |   990,001 |  0.0000005 | !
     0.105 |  6,819,840 |   170,000 |   0.000001 | EM2EFFORT
     0.073 |  6,795,264 |   170,000 |  0.0000004 | EM2RIN
     0.027 |  6,778,880 |   170,000 |  0.0000002 | EM2CIN
     0.020 |  1,585,152 |    50,000 |  0.0000004 | SF2CIN
     0.016 |  1,630,208 |    50,000 |  0.0000003 | SF2DIN
     0.012 |  6,742,016 |   170,000 |  0.0000001 | EM2DIN
     0.006 |    946,176 |    30,000 |  0.0000002 | DR2ROUT
     0.001 |          0 |        14 |   0.000067 | MAKE-R15
     0.001 |      8,192 |         1 |   0.000539 | COCOMO-DEFAULTS
     0.000 |          0 |         5 |   0.000000 | MAKE-SFS
     0.000 |          0 |         1 |   0.000000 | LINE-Y
     0.000 |          0 |        27 |   0.000000 | ?
     0.000 |          0 |         1 |   0.000000 | INIT-DB
     0.000 |          0 |         5 |   0.000000 | MAKE-R16
     0.000 |          0 |         7 |   0.000000 | MAKE-RIN+
     0.000 |  1,695,744 |    50,000 |   0.000000 | SF2EFFORT
     0.000 |          0 |         1 |   0.000000 | MAKE-R26
     0.000 |          0 |         9 |   0.000000 | MAKE-EM-
     0.000 |          0 |         6 |   0.000000 | MAKE-DIN+
     0.000 |          0 |         1 |   0.000000 | ?ONE-B
     0.000 |          0 |         1 |   0.000000 | MAKE-ONE-A
     0.000 |          0 |        27 |   0.000000 | GUESS
     0.000 |          0 |        25 |   0.000000 | ?ELT
     0.000 |          0 |         5 |   0.000000 | MAKE-DSF
     0.000 |    974,848 |    30,000 |   0.000000 | DR2DOUT
     0.000 |          0 |        34 |   0.000000 | MAKE-EM
     0.000 |          0 |        25 |   0.000000 | ?BAG
     0.000 |          0 |         6 |   0.000000 | MAKE-DR
     0.000 |          0 |        10 |   0.000000 | MAKE-RIN-
     0.000 |          0 |         5 |   0.000000 | MAKE-RSF
     0.000 |          0 |         3 |   0.000000 | ?DR
     0.000 |          0 |         1 |   0.000000 | POINT-TO-LINE
     0.000 |          0 |         3 |   0.000000 | MAKE-RDR
     0.000 |          0 |         1 |   0.000000 | DEMO456
     0.000 |          0 |         1 |   0.000000 | MAKE-LINE
     0.000 |          0 |         3 |   0.000000 | MAKE-R25
     0.000 |          0 |         3 |   0.000000 | MAKE-DDR
     0.000 |          0 |         5 |   0.000000 | MAKE-CSF
     0.000 |          0 |        10 |   0.000000 | MAKE-SF
     0.000 |          0 |         6 |   0.000000 | MAKE-CIN+
     0.000 |          0 |        11 |   0.000000 | MAKE-CIN-
     0.000 |          0 |        28 |   0.000000 | GETA
     0.000 |  1,482,752 |    50,000 |   0.000000 | SF2RIN
     0.000 |          0 |         5 |   0.000000 | ?SF
     0.000 |      8,192 |        17 |   0.000000 | ?EM
     0.000 |          0 |         8 |   0.000000 | MAKE-EM+
     0.000 |          0 |         2 |   0.000000 | MAKE-NUM
     0.000 |          0 |         1 |   0.000000 | ?ONE-A
     0.000 |    958,464 |    30,000 |   0.000000 | DR2COUT
     0.000 |          0 |         3 |   0.000000 | MAKE-CODR
     0.000 |          0 |         1 |   0.000000 | MAKE-ONE-B
     0.000 | 24,076,288 |         1 |   0.000000 | DEMO456A
     0.000 |          0 |        25 |   0.000000 | COCO
     0.000 |          0 |         2 |   0.000000 | MAKE-R36
     0.000 |          0 |        11 |   0.000000 | MAKE-DIN-
     0.000 |          0 |         1 |   0.000000 | MAKE-DB
     0.000 |    155,648 |    10,124 |   0.000000 | MY-RANDOM
------------------------------------------------------------
     0.707 | 60,657,664 | 1,970,493 |            | Total

• Cost benefits of recursion/iteration.
• How to profile some of your code to find hotspots.
• How to profile all of your code.