The Second Boom Begins | All History of AI

011965–1977 · The power of knowledge

The Power Is in the Knowledge

Does a clever computer need good ways of thinking, or a huge amount of knowledge?

In 1965, Edward Feigenbaum and his colleagues, who had moved to Stanford University, built the experience of chemists reading mass-spectrometry data into DENDRAL, a program that lists every possible molecular structure. They wrote it as rules, and the candidates were narrowed down. In an example from Nilsson (2010), 14,715,813 structures were cut to about 1,284,792 by the rules about the data, and to just one when another measurement was added.

The figure on the right lines up 6 parts of 3 kinds in 729 possible ways and narrows them by adding rules. The more knowledge is added, the more the number of things to check shrinks, by orders of magnitude.

In a 1970 paper the three authors wrote: In 1977, Feigenbaum called the work of moving experts' knowledge into computers knowledge engineering, and summed it up as .

N_left ≈ N × r₁ × r₂ × … × r_k

N: number of all candidates
r_i: fraction that remains after rule i (≈ is a rough guide when the rules do not affect each other)

What you think you knowThe popular story:A government white paper (2016) says (translated)
The original source says:the one that turned experts' experience into rules was DENDRAL (from 1965), which came first, and in the title of a 1993 paper a person involved calls DENDRAL . The answer changes depending on where you start counting expert systems.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_knowledge_prune.py

# u06 知識で候補を絞る：専門家の「決まり」を足すたびに、考える候補が減っていく
#
# どの出来事か：1965 年からの DENDRAL（記録 dendral_1965）と、1977 年のファイゲンバウムの論文
#   「知識の中に力がある」（記録 feigenbaum_knowledge_bottleneck_1977）。
#   DENDRAL は、化学式から考えられる分子構造を網羅し、化学者の経験的なルールで候補を絞り込んだ。
#   Nilsson（2010）の例では、14,715,813 通りの構造が、質量分析のデータで約 1,284,792 通りに、別の測定も加えると 1 通りに絞られた。
# 仕組み：分子の代わりに、A・B・C の 3 種類の部品を 8 個つなぐ「並べ方」を全通り生成する（3 の 8 乗＝6,561 通り）。
#   専門家のルール（このサイトが作った例）を 1 つずつ適用して、残る候補を数える。
#   力任せの探索よりも、候補を絞り込む知識のほうが、答えに早く近づけることが分かる。
# 試してみよう：
#   - RULES の順番を入れ替えると、途中の数はどう変わるか。最後の数は変わるか
#   - 部品の数 N を 10 にすると、全体の数と、残る数はどうなるか

import math
from itertools import product

N = 8
PARTS = "ABC"

# 専門家のルール（このサイトが作った例）。どれも「この形はありえない」という知識
RULES = [
    ("はじめは A", lambda s: s[0] == "A"),
    ("C と C はとなり合わない", lambda s: "CC" not in s),
    ("B はちょうど 2 個", lambda s: s.count("B") == 2),
    ("最後は C", lambda s: s[-1] == "C"),
    ("A の次に B は来ない", lambda s: "AB" not in s),
    ("C はちょうど 3 個", lambda s: s.count("C") == 3),
    ("3 番目と 6 番目は同じ", lambda s: s[2] == s[5]),
    ("B と B はとなり合わない", lambda s: "BB" not in s),
    ("2 番目は A", lambda s: s[1] == "A"),
]

cands = ["".join(p) for p in product(PARTS, repeat=N)]
print(f"部品 {N} 個の並べ方：全部で {len(cands):,} 通り")

def bar(n):
    """対数目盛のバー表示（# 6 個で 10 倍）"""
    return "#" * max(1, round(math.log10(max(n, 1)) * 6)) if n else ""

for name, ok in RULES:
    cands = [s for s in cands if ok(s)]
    print(f"  ＋ルール「{name}」→ 残り {len(cands):>5,} 通り  {bar(len(cands))}")

print("\n残った候補：", cands[:10], "…" if len(cands) > 10 else "")
print("\nDENDRAL の実際の数値（Nilsson 2010）：14,715,813 → 約 1,284,792 → 1")
print("ルール（知識）を加えるほど、調べる数が桁違いに減る。これが「知識の中に力がある」の意味の 1 つ")

021972–1978 · MYCIN

Confidence Factors for

How do you connect rules that contain a ?

From about 1972, Edward Shortliffe and his colleagues at Stanford University built MYCIN, a program that advises doctors on choosing drugs for bacterial infections. They wrote doctors' knowledge as rules of the form: if (the lab result is ...) then (the germ is probably ...). The rules numbered about 200 at first and about 500 by 1978.

Each rule carries a confidence factor (from −1 to +1) that says how sure it is. When a condition is uncertain, multiply the rule's confidence factor by how certain the condition is. In an example from the developers' book, a rule with confidence factor 0.7 whose condition is 0.6 certain gives 0.42. When other rules support the same conclusion, they are added together with the formula below.

In the figure on the right (a bicycle example, not a medical one), adding weak rules pushes the confidence toward 1, however weak they are. The book says it chose this way of adding by intuition, not by probability theory. A textbook cited by Nilsson (2010) says that as the rules grew in number, the confidence factors of other rules also had to be corrected.

combined confidence = x + y(1 − x)

x: confidence so far
y: confidence given by the new rule (the rule's confidence × how certain its condition is; with two or more conditions, the lowest certainty)

Number of rules used, and the combined confidence

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_expert_rules.py

# u06 エキスパートシステムの仕組み：「もし〜なら〜」のルールと確信度、「なぜ？」に答える
#
# どの出来事か：1972 年からの MYCIN（記録 mycin_1972）。医師の知識を「もし〜なら〜」のルールとして書き込み、
#   ルールごとに確からしさ（確信度）を設定し、なぜそう判断したかを説明できた。初めは約 200、1978 年に約 500 のルール。
# このサンプル：同じ仕組みで「自転車の調子が悪い理由」を診断する（医学の助言はしない）。
#   ゴール（原因の候補）から逆向きに、ルールを使って確かめていく（後ろ向き推論）。
# 試してみよう：
#   - FACTS の答えを変えると、結論と確信度がどう変わるか
#   - ルールにない症状（例：「ベルが鳴らない」）を入れると、何も判断できない → 知識を書き足す手間（知識獲得のボトルネック）

FACTS = {   # 利用者の回答（はい＝True、いいえ＝False）
    "こぐと音がする": True,
    "チェーンがさびている": True,
    "タイヤを押すとへこむ": False,
    "ブレーキをかけていないのに重い": True,
    "ベルが鳴らない": True,
}

RULES = [
    # (番号, 条件（すべて満たす場合）, 結論, ルールの確信度)
    ("R1", ["こぐと音がする", "チェーンがさびている"], "チェーンの油切れ", 0.8),
    ("R2", ["タイヤを押すとへこむ"], "空気が少ない", 0.9),
    ("R3", ["ブレーキをかけていないのに重い", "タイヤを押すとへこむ"], "空気が少ない", 0.6),
    ("R4", ["ブレーキをかけていないのに重い"], "ブレーキがこすれている", 0.5),
    ("R5", ["こぐと音がする"], "チェーンの油切れ", 0.3),
]
GOALS = ["チェーンの油切れ", "空気が少ない", "ブレーキがこすれている"]

def combine(a, b):
    """同じ結論を別のルールが支持したときの計算（MYCIN の確信度の合成。正の値同士）"""
    return a + b * (1 - a)

def prove(goal, depth=0):
    """ゴールの確信度を求め、どのルールを使ったかの説明も返す。"""
    cf, why = 0.0, []
    for no, conds, concl, strength in RULES:
        if concl != goal:
            continue
        cond_cfs = [1.0 if FACTS.get(c) else 0.0 for c in conds]
        if min(cond_cfs) > 0:
            this = strength * min(cond_cfs)
            cf = combine(cf, this)
            why.append(f"{no}：もし {'・'.join(conds)} なら {concl}（確信度 {strength}）")
    return cf, why

for g in GOALS:
    cf, why = prove(g)
    print(f"{g}：確信度 {cf:.2f}")
    for w in why:
        print(f"   なぜ？ → {w}")

unknown = [f for f, v in FACTS.items() if v and not any(f in conds for _, conds, _, _ in RULES)]
print("\nルールが 1 つもないため、何も判断できなかった回答：", unknown)
print(f"現在のルールの数：{len(RULES)}。MYCIN は 1978 年に約 500。ルールを書き足し、直し続けるのが大仕事だった")

031970s · Inference engines

Forward and Backward

When there are many rules, which rule does the machine use first?

A program that is given experts' knowledge as rules and produces answers along with the reasons is called an expert system. The part that chains the rules together to reach an answer is the inference engine. The book by the people who made MYCIN (1984) divided the ways of chaining into two. Forward (from the data) starts from the known facts and links the rules from the “if” to the “then”. Backward (from the goal) starts from the goal to be checked, traces back, and asks only for the facts that are missing. MYCIN mostly worked backward, and was also described as a program that gathers evidence.

Compare the two in the figure on the right (a bicycle example). Forward asks every question and then uses the rules, while backward asks only the questions related to the goal.

In MYCIN the collection of rules (the knowledge base) and the inference engine were separate, so an empty shell with the medical rules removed, EMYCIN (E is for empty), was built, and used for consultation systems such as tax planning.

Forward: facts → conclusion　　Backward: goal → question

Forward: go from the “if” (condition) to the “then” (conclusion)
Backward: trace back from the “then” to the “if”, and ask only about what is missing

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_forward_backward.py

# u06 前向き推論と後ろ向き推論：同じルールでも、適用する順番で「聞く質問の数」が変わる
#
# どの出来事か：MYCIN（記録 mycin_1972）。開発者たちの本（1984）は、分かっている事実からルールを左から右へ
#   つないでいくやり方を前向き（データから進む）、確かめたいゴールからルールを右から左へたどり、
#   足りない事実だけを聞くやり方を後ろ向き（ゴールから進む）と呼び、MYCIN は主に後ろ向きを使ったと書いている。
# このサンプル：医学ではなく「自転車の調子が悪い理由」の知識（このサイトが作ったルール）で比較する。
# 試してみよう：
#   - TRUTH（実際の状態）を変えて、それぞれ何問質問するかを比べる
#   - GOAL を「空気が少ない」に変える。後ろ向き推論は、どの質問を省略するか

TRUTH = {  # 使う人に聞けば分かる事実（実際の状態）
    "こぐと音がする": True,
    "チェーンがさびている": False,
    "雨の中に置いていた": True,
    "タイヤを押すとへこむ": False,
    "ブレーキをかけていないのに重い": True,
    "前に乗ったのは 1 か月以上前": True,
    "空気を入れたのは最近": False,
    "ブレーキのレバーが戻りにくい": False,
}

RULES = [  # (番号, もし（すべて満たせば）, なら)。「〜でない」は「not 〜」と書く
    ("R1", ["雨の中に置いていた"], "さびやすい所にあった"),
    ("R2", ["前に乗ったのは 1 か月以上前"], "しばらく乗っていない"),
    ("R3", ["こぐと音がする", "チェーンがさびている"], "チェーンの油切れ"),
    ("R4", ["こぐと音がする", "さびやすい所にあった"], "チェーンの油切れ"),
    ("R5", ["タイヤを押すとへこむ"], "空気が少ない"),
    ("R6", ["しばらく乗っていない", "ブレーキをかけていないのに重い", "not 空気を入れたのは最近"], "空気が少ない"),
    ("R7", ["ブレーキをかけていないのに重い", "ブレーキのレバーが戻りにくい"], "ブレーキがこすれている"),
]
GOAL = "チェーンの油切れ"

def forward():
    """前向き推論：まず事実をすべて確認し、使えるルールがなくなるまで適用を繰り返す"""
    known = dict(TRUTH)  # すべての質問を行う
    asked = len(TRUTH)
    changed = True
    while changed:
        changed = False
        for no, conds, concl in RULES:
            if concl not in known and all(known.get(c[4:]) is False if c.startswith("not ") else known.get(c) for c in conds):
                known[concl] = True
                changed = True
                print(f"   {no} を適用 → {concl}")
    return known.get(GOAL, False), asked

def backward(goal, known, asked, depth=0):
    """後ろ向き推論：ゴールを結論に持つルールを探し、その条件を新たなゴールとしてたどる。事実なら質問する"""
    if goal in known:
        return known[goal]
    concl_rules = [r for r in RULES if r[2] == goal]
    if not concl_rules:  # どのルールの結論でもない＝使う人に尋ねる事実
        known[goal] = TRUTH[goal]
        asked.append(goal)
        print("   " + "  " * depth + f"質問：{goal}？ → {'はい' if TRUTH[goal] else 'いいえ'}")
        return known[goal]
    for no, conds, _ in concl_rules:
        print("   " + "  " * depth + f"{no} を試す（{goal} を確かめるため）")
        ok = True
        for c in conds:
            neg = c.startswith("not ")
            v = backward(c[4:] if neg else c, known, asked, depth + 1)
            if v == neg:
                ok = False
                break
        if ok:
            known[goal] = True
            return True
    known[goal] = False
    return False

print("■ 前向き推論（データから）：")
ans, n = forward()
print(f"   答え：{GOAL} は {'あり' if ans else 'なし'}。聞いた質問 {n} 問\n")

print("■ 後ろ向き推論（ゴールから）：")
asked = []
ans = backward(GOAL, {}, asked)
print(f"   答え：{GOAL} は {'あり' if ans else 'なし'}。聞いた質問 {len(asked)} 問")
print("\n後ろ向き推論は、ゴールに関係のある質問しかしない。開発者たちが MYCIN を、証拠を集めるプログラムと呼んだ理由がここにある")

041970s · Explanation

A Machine You Can Ask “Why?”

How can people come to trust the answer a machine gives?

MYCIN's developers made explaining its reasons an important goal from the start. When MYCIN asked a question, the user could type WHY (why are you asking?). MYCIN then showed the higher goal it was checking and the rule that connects that goal to the question. Repeating WHY climbed higher still. Typing HOW (how did you find that out?) showed the rule it had used, or that the user had given that answer.

The figure on the right is a bicycle consultation. Answer the questions and press "Why?" a few times. In the figure, the chain of rules being checked appears.

In backward reasoning, every question comes up to check the condition of some rule. That is why the reason can be answered with a chain of rules.

Why? → higher goal + rule　How? → rule / answer

Goal: the conclusion being checked right now
Chain: the links of rules from the goal down to the question

Chapter 18 of the book has an example of a WHY and HOW exchange. It is a medical example, so the figure uses a bicycle instead.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_why_how.py

# u06 「なぜ？」と「どうやって？」に答える相談の機械
#
# どの出来事か：MYCIN（記録 mycin_1972）。開発者たちの本（1984）の第 18 章によると、MYCIN が質問している時、
#   使う人は WHY（なぜそれを聞くのか）と入力できた。MYCIN は、いま確かめようとしている上のゴールと、
#   そのゴールと質問をつなぐルールを示した。WHY を繰り返すと、さらに上のゴールへさかのぼった。
#   HOW（どうやってそれが分かったのか）と入力すると、使ったルールか、使う人自身が答えたことを示した。
# このサンプル：医学ではなく「自転車の調子が悪い理由」の小さな知識（このサイトが作ったルール）。
#   input() の代わりに、ANSWERS に答えを、COMMANDS に質問ごとに打つ言葉を書いておく。
# 試してみよう：
#   - COMMANDS に "なぜ" を 3 回並べると、どこまでさかのぼるか
#   - ANSWERS を変えると、どのルールが使われ、HOW の答えがどう変わるか

ANSWERS = {"こぐと音がする": True, "チェーンがさびている": False, "雨の中に置いていた": True}
COMMANDS = {"雨の中に置いていた": ["なぜ", "なぜ"]}  # この質問の時に打つ言葉
HOW_AT_END = ["チェーンの油切れ", "さびやすい所にあった", "こぐと音がする"]

RULES = [
    ("R3", ["こぐと音がする", "チェーンがさびている"], "チェーンの油切れ", 0.8),
    ("R4", ["こぐと音がする", "さびやすい所にあった"], "チェーンの油切れ", 0.6),
    ("R1", ["雨の中に置いていた"], "さびやすい所にあった", 0.7),
]

how = {}    # 分かったこと → どうやって分かったか
stack = []  # いま確かめているゴールと使っているルール（WHY のために記録）
known = {}  # 分かったこと → はい・いいえ

def ask(fact):
    print(f"質問：{fact}？")
    level = len(stack)  # WHY で、どこまでさかのぼったか
    for cmd in COMMANDS.get(fact, []):
        print(f"  ** {cmd}")
        if cmd == "なぜ":
            if level == 0:
                print("     （これが、いちばん上のゴールです）")
                continue
            level -= 1
            goal, (no, conds, concl, cf) = stack[level]
            print(f"     → {concl} を確かめるためです。{no}：もし {'・'.join(conds)} なら {concl}（確信度 {cf}）")
    ans = ANSWERS[fact]
    print(f"  答え：{'はい' if ans else 'いいえ'}")
    how[fact] = "あなたがそう答えた"
    return ans

def prove(goal):
    if goal in known:
        return known[goal]
    rules = [r for r in RULES if r[2] == goal]
    if not rules:
        known[goal] = ask(goal)
        return known[goal]
    for rule in rules:
        stack.append((goal, rule))
        ok = all(prove(c) for c in rule[1])  # all は、いいえが出たところで止まる
        stack.pop()
        if ok:
            how[goal] = f"{rule[0]} を使った（{'・'.join(rule[1])} がそろった）"
            known[goal] = True
            return True
    how[goal] = "使える決まりが無かった"
    known[goal] = False
    return False

result = prove("チェーンの油切れ")
print(f"\n結論：チェーンの油切れ は {'あり' if result else 'なし'}\n")
for f in HOW_AT_END:
    print(f"** どうやって「{f}」が分かった？ → {how.get(f, 'まだ分かっていない')}")

051974 · Frames

Knowledge as Templates of Situations

Why does hearing just “birthday party” make you think of cake and presents?

In June 1974, Marvin Minsky of MIT put forward, in his report , the idea that when people meet a new situation, they pull a structure called a frame out of memory and adjust its details to fit reality. A frame is , and it has empty slots. The slots are temporarily filled with the values that are usually true (default values). The report gave the example of going to a child's birthday party.

In the figure on the right, have it read the story one sentence at a time. The values that are written fill the slots, and for what is not written it assumes the default values, with a . If a value differs from the default, it turns purple.

Minsky noted that he wrote it , and in the last section he wrote: . He did not build a frame system himself; students built them a few years later (Nilsson 2010).

What you think you knowThe popular story:“Second-boom AI means writing lots of knowledge as ‘if ... then ...’ rules or logical formulas” is how it tends to be lumped together
The original source says:frames, one of the leading ideas of the same period, tried to represent knowledge as templates that hold expectations of how things usually are.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_frames.py

# u06 フレーム：よくある場面のひな型に、スロット（空き欄）と「とりあえずの値」を持たせる
#
# どの出来事か：1974 年 6 月のミンスキーの報告「知識を表すための枠組み」（記録 minsky_frames_1974）。
#   人は新しい場面に出会うと、記憶からフレームという枠組みを取り出し、細かいところを直して現実に合わせる、という考え方。
#   フレームにはスロット（空き欄）があり、そこには、ふつうはこうだというデフォルト（とりあえずの値）が入っている。
#   報告は、子どもの誕生会に行く場面を例に挙げている。
# このサンプル：誕生会のフレーム（スロットととりあえずの値は、このサイトが作った例）に、物語の文を 1 つずつ読ませる。
#   文に書かれた値でスロットを埋め、書かれていない所は、とりあえずの値で「たぶん〜」と考える。
#   とりあえずの値と違うことが書かれていたら「予想とちがう」と知らせる。
# 試してみよう：
#   - STORY に「ケーキはなかった」の文を足すと、どうなるか
#   - レストランのフレームを作って、同じ物語を読ませる（スロットがどれだけ埋まるか）

FRAME = {  # スロット（空き欄） → とりあえずの値
    "主役": "誕生日の子",
    "場所": "主役の家",
    "食べ物": "ケーキ",
    "プレゼント": "おもちゃ",
    "遊び": "ゲーム",
    "終わりに": "ろうそくを吹き消す",
}

STORY = [  # (文, スロット, 書かれた値)。文から値を取り出す処理は、ここでは人が書いておく
    ("今日はケンの 8 歳の誕生会だ。", "主役", "ケン"),
    ("みんなで公園に集まった。", "場所", "公園"),
    ("ぼくは本を包んで持っていった。", "プレゼント", "本"),
    ("おやつは大きなすいかだった。", "食べ物", "すいか"),
]

filled = {}
for sentence, slot, value in STORY:
    filled[slot] = value
    mark = "予想とちがう！" if value != FRAME[slot] and slot != "主役" else "埋まった　"
    print(f"{sentence:<16} → {slot}＝{value}　{mark}（とりあえずの値は {FRAME[slot]}）")

print("\n現在のフレーム：")
for slot, default in FRAME.items():
    if slot in filled:
        print(f"  {slot:<6}：{filled[slot]}（物語に書いてあった）")
    else:
        print(f"  {slot:<6}：たぶん {default}（書いていないので、とりあえずの値）")

print("\n書いていないことまで「たぶん」で埋められるのが、フレームの強み。")
print("そのかわり、とりあえずの値が現実と違うこともある（すいかの誕生会）。")

061979 · How MYCIN scored

Scoring with the Names Hidden

How can we fairly check whether a machine's answer is good?

In an evaluation in 1979, 10 prescriptions were collected for each of 10 meningitis patients: from MYCIN, from five Stanford infectious-disease faculty, from an infectious-disease fellow, from an internal-medicine resident, from a medical student, and the treatment actually given. Eight infectious-disease specialists from outside Stanford scored them one by one without being able to tell whose prescription it was (8 raters × 100 = 800 ratings).

65% of MYCIN's prescriptions were , against 42.5–62.5% (average 55.5%) for the five faculty. In the cases where most of the specialists accepted the prescription, MYCIN had 7 out of 10. In the figure on the right, switch the standard and reveal the names.

Even so, the book by its builders (1984) says . They had also wanted over 90% approval from most of the specialists before routine use.

What you think you knowThe popular story:“MYCIN was more accurate than specialists, but it was not used in hospitals because of legal and liability problems” is what people tend to say
The original source says:the reasons given in the builders' book are the cost and staffing of adding knowledge, the wish to move on to the next research, and above all, in their words, performance, for ordinary reasons. Most of these were problems of usability and effort.

071979–1982 · PROSPECTOR

Weighing the Odds with Multipliers

How can you estimate an ore deposit underground from clues on the surface?

SRI's PROSPECTOR was an AI that advised geologists searching for minerals, and an analysis of how well it performed was presented at the international conference in Tokyo in 1979. Its rules linked together into an inference network: a rock with crystal-shaped cavities is a sign of sulfides, and barite above sulfides may mean a massive sulfide deposit, and so on.

Unlike MYCIN's confidence factors, PROSPECTOR used probability and Bayes' rule. For each rule the expert gives two numbers: how many times the odds multiply when the condition is true (LS), and how many times when it is not (LN). In the figure on the right, pressing a clue sends the change through the network and the probability changes (the multipliers are numbers made up for this site).

In 1982, from map data for Mount Tolman (Washington State), it drew a map of how promising the area was for molybdenum deposits, on a scale from +5 to −5.

odds ← odds × LS (yes) or × LN (no)　　probability = odds ÷ (1 + odds)

odds: chance it happens ÷ chance it does not
LS, LN: two multipliers decided by the expert

What you think you knowThe popular story:“PROSPECTOR found an ore deposit that humans had not found” is what people tend to say
The original source says:by the developers' account, it was at a place where a mining company had already found the deposit by drilling more than 200 holes, and it picked out and . And . This is confirmed only through the book of one of the developers.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_prospector_odds.py

# u06 PROSPECTOR の推論方法：「A は B を示す」ルールに、2 つの倍率をつけてオッズをかけ算する
#
# どの出来事か：SRI の PROSPECTOR（記録 prospector_mount_tolman_1982）。Nilsson（2010）によると、
#   ルールは「結晶の形の空洞がある岩は、硫化物がある印」（ルール 22）や、
#   「硫化物の上に重晶石があれば、塊状の硫化物の鉱床があるかもしれない」（ルール 3）のような形で、
#   ルール同士がつながった「推論の網」になっていた。地質の専門家はルールごとに 2 つの数値を与えた。
#   条件が正しい時にオッズが何倍に増えるか（ここでは LS）と、条件が誤りの時に何倍に減るか（ここでは LN）である。
#   それをベイズの規則で使い、結論の確率を計算した。
# このサンプル：同じ構造の小さなネットワーク（倍率と初期確率は、このサイトが作った数）。
#   手がかりの入力は はい（True）・いいえ（False）・分からない（None）。
#   ネットワーク途中の結論（硫化物がある）は確率で次へ渡す。その計算（はい と いいえ の間を直線で補間する）は、
#   このサンプルのやり方で、本物の PROSPECTOR の式そのものではない。
# 試してみよう：
#   - EVIDENCE の答えを変えて、鉱床の確率がどう動くかを見る
#   - LS を大きくすると、1 つの手がかりの影響がどれだけ変わるかを見る

PRIOR = {"硫化物がある": 0.10, "塊状の硫化物の鉱床": 0.01}

# (手がかり, 結論, LS＝正しい時の倍率, LN＝誤りの時の倍率)
RULES = [
    ("結晶の形の空洞がある岩", "硫化物がある", 20.0, 0.8),
    ("方鉛鉱が見つかった", "硫化物がある", 50.0, 0.9),
    ("硫化物がある", "塊状の硫化物の鉱床", 5.0, 0.2),
    ("重晶石が上にある", "塊状の硫化物の鉱床", 8.0, 0.6),
]

EVIDENCE = {"結晶の形の空洞がある岩": True, "方鉛鉱が見つかった": None, "重晶石が上にある": True}

def odds(p):
    return p / (1 - p)

def prob(o):
    return o / (1 + o)

def factor(pe, pe0, ph0, ls, ln):
    """手がかりの確率 pe から、結論のオッズを何倍にするかを計算する（はい＝LS、いいえ＝LN、初期値のまま＝1 倍）"""
    p_yes, p_no = prob(odds(ph0) * ls), prob(odds(ph0) * ln)
    if pe >= pe0:
        p = ph0 + (p_yes - ph0) * (pe - pe0) / (1 - pe0)
    else:
        p = p_no + (ph0 - p_no) * pe / pe0
    return odds(p) / odds(ph0)

def infer(node, depth=0):
    """結論の確率を、下の手がかりから順に計算する。手がかりの確率を返す"""
    pad = "  " * depth
    if node in EVIDENCE:
        v = EVIDENCE[node]
        return 0.5 if v is None else (1.0 if v else 0.0), 0.5
    o = odds(PRIOR[node])
    print(pad + f"{node}（初期確率 {PRIOR[node]:.3f}）")
    for ev, concl, ls, ln in RULES:
        if concl != node:
            continue
        pe, pe0 = infer(ev, depth + 1)
        f = factor(pe, pe0, PRIOR[node], ls, ln)
        o *= f
        print(pad + f"  ← {ev}（{pe:.2f}）：オッズ ×{f:.2f} → {prob(o):.3f}")
    return prob(o), PRIOR[node]

p, _ = infer("塊状の硫化物の鉱床")
print(f"\n塊状の硫化物の鉱床がある確率：{p:.3f}（初期確率は {PRIOR['塊状の硫化物の鉱床']}）")
print("手がかりはかけ算で効く。専門家が決めるのは、ルールごとの 2 つの倍率だけである")

081980 · R1 (XCON)

Noticing the Missing Parts

What kind of rules turn a computer order into an assembly diagram?

John McDermott of Carnegie Mellon University built R1 (called XCON inside the company), which decides the configuration of parts from orders for DEC's VAX computers. One machine normally has about 90 parts, and orders often left out parts that were needed. R1 noticed this, filled the gaps, and drew up the layout. From January 1980 it was used in everyday work at DEC's factory.

R1 looked at its working notes, found all the rules whose conditions fit, ran one of them, and repeated this. In the 1980 paper it had 772 rules. One order took 1,056 rule runs on average, and the computing time averaged 2.5 minutes. In the figure on the right (the parts and rules are an example made up for this site), press "Run once".

① Find every rule whose conditions are met → ② Pick one → ③ Run it and rewrite the notes → ①

Working notes: the current task (checking, placing, connecting) and the information known so far

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_configurator.py

# u06 注文書から、足りない部品を足して、箱に並べる：「条件がそろった決まりを 1 つ実行する」をくり返す
#
# どの出来事か：R1（社内名は XCON）。1980 年 1 月から DEC の工場で使われた（記録 xcon_r1_dec_1980）。
#   1980 年の論文によると、R1 は OPS4 という言語で書かれ、作業のメモ（working memory）を見て、
#   条件を満たすルールをすべて見つけ、そのうち 1 つを実行する処理を繰り返した（recognize-act cycle）。
#   注文には必要な部品の不足が多く、それに気づいて補うのが大きな仕事だった。1 台は通常約 90 の部品。
# このサンプル：本物の VAX の部品ではなく、このサイトが作った小さな部品表と 8 つのルール。
#   ルールは「いまの作業（文脈）」ごとに分かれている（R1 のルールも、文脈の条件から始まっていた）。
# 試してみよう：
#   - ORDER のディスクを 5 台にすると、制御装置はいくつ追加されるか
#   - ルール R2 を消すと（RULES から外すと）、どんな誤った組み立てになるか

ORDER = {"CPU": 1, "メモリ": 3, "ディスク": 3, "端末": 2}
SLOTS_PER_BOX = 4          # 1 つの箱に入る基板の数（このサイトが作った数）
DISKS_PER_CONTROLLER = 2   # 1 つの制御装置につなぐディスクの数（このサイトが作った数）

wm = {"文脈": "点検", "部品": dict(ORDER), "箱": [[]], "置いた": {k: 0 for k in ORDER}, "ケーブル": 0, "足した": []}
BOARDS = ["CPU", "メモリ", "制御装置", "端末の板"]  # 箱の中に差し込む部品

def add(part, why):
    wm["部品"][part] = wm["部品"].get(part, 0) + 1
    wm["置いた"].setdefault(part, 0)
    wm["足した"].append(part)
    return f"{part} を追加（{why}）"

def next_unplaced():
    for p in BOARDS:
        if wm["置いた"].get(p, 0) < wm["部品"].get(p, 0):
            return p
    return None

def place(p):
    box = wm["箱"][-1]
    box.append(p)
    wm["置いた"][p] += 1
    return f"{p} を 箱 {len(wm['箱'])} の {len(box)} 番に配置"

RULES = [  # (名前, 条件, 実行)
    ("R1 制御装置が足りない", lambda: wm["文脈"] == "点検" and wm["部品"].get("制御装置", 0) * DISKS_PER_CONTROLLER < wm["部品"]["ディスク"],
     lambda: add("制御装置", "ディスクに対して不足")),
    ("R2 端末の板が無い", lambda: wm["文脈"] == "点検" and wm["部品"].get("端末", 0) > 0 and wm["部品"].get("端末の板", 0) == 0,
     lambda: add("端末の板", "端末をつなぐため")),
    ("R3 点検おわり", lambda: wm["文脈"] == "点検",
     lambda: wm.update(文脈="置く") or "不足なし → 文脈を「置く」へ"),
    ("R4 箱がいっぱい", lambda: wm["文脈"] == "置く" and next_unplaced() and len(wm["箱"][-1]) >= SLOTS_PER_BOX,
     lambda: wm["箱"].append([]) or add("箱", "空きが無い")),
    ("R5 次の板を置く", lambda: wm["文脈"] == "置く" and next_unplaced(),
     lambda: place(next_unplaced())),
    ("R6 置きおわり", lambda: wm["文脈"] == "置く",
     lambda: wm.update(文脈="ケーブル") or "配置完了 → 文脈を「ケーブル」へ"),
    ("R7 ディスクにケーブル", lambda: wm["文脈"] == "ケーブル" and wm["ケーブル"] < wm["部品"]["ディスク"],
     lambda: wm.update(ケーブル=wm["ケーブル"] + 1) or add("ケーブル", "ディスク 1 台に 1 本")),
    ("R8 おわり", lambda: wm["文脈"] == "ケーブル",
     lambda: wm.update(文脈="おわり") or "組み立て図を出力"),
]

cycle = 0
while wm["文脈"] != "おわり" and cycle < 100:
    cycle += 1
    ready = [r for r in RULES if r[1]()]          # ① 条件を満たすルールをすべて探す
    name, _, act = ready[0]                       # ② 1 つ選ぶ（ここでは表の上にあるもの＝特別なルールを優先）
    print(f"{cycle:>2} [{len(ready)} 個そろった] {name}：{act()}")   # ③ 実行して、作業のメモを書き換える

print("\n組み立て図：")
for i, box in enumerate(wm["箱"], 1):
    print(f"  箱 {i}：" + " ｜ ".join(box))
print(f"注文に無かったが追加した部品：{', '.join(wm['足した'])}")

091981 · Japan

Translating by Example Sentences

Can we translate without writing out all the rules of grammar?

Makoto Nagao of Kyoto University wrote that earlier machine translation had a contradiction: of its translation ability. So he proposed a system that, like a person learning a foreign language, holds many pairs of example sentences in English and Japanese. It looks for the example sentence most similar to the sentence to be translated, and swaps in words to translate it. This idea was written in a manuscript for a NATO conference in October 1981. That conference was held the week after the international Fifth Generation conference in Tokyo (October 19–22).

In the manuscript's example, from the example sentence A man eats vegetables. (人は野菜をたべる。), He eats potatoes. is translated as (彼はじゃがいもをたべる。). That works because man and he, and vegetable and potato, are close in the thesaurus. Acid eats metal. is not close to this example, so a different example is needed (酸は金属を侵す。). Try it in the figure on the right.

The opening essay of a 2015 society journal says that from this (translated), research grew into translation that uses huge amounts of text data and statistics.

What you think you knowThe popular story:“Makoto Nagao's 1984 paper started machine translation from examples” is what people say
The original source says:the idea was already written in the October 1981 conference manuscript. It appeared in print in 1984.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_example_mt.py

# u06 例文をまねて訳す：最も似た例文を探し、単語を入れ替える（長尾真さんの 1981 年の着想）
#
# どの出来事か：長尾真さんの 1981 年 10 月の原稿（記録 nagao_analogy_translation_1981）。
#   英語と日本語の対訳例文を蓄えておき、訳したい文に最も似た例文を探す。
#   対応する単語を置き換えられるか（意味が近いか）をシソーラス（類語辞典）で確認し、
#   適切であれば、例文の訳語を置き換えて訳文を作る。
# このサンプル：例文と訳は、原稿の表にある例（A man eats vegetables. など）。
#   シソーラス（単語の分類）と類似度のスコアは、このサイトが作った小さな例。
# 試してみよう：
#   - EXAMPLES から「酸は金属を侵す」の組を消すと、Sulphuric acid eats iron. はどう訳されるか
#   - 自分で例文の組と、辞書の単語を追加してみる

EXAMPLES = [  # (主語, 動詞, 目的語) の英語と、その訳の (主語, 目的語, 動詞)
    (("man", "eats", "vegetables"), ("人", "野菜", "たべる")),
    (("acid", "eats", "metal"), ("酸", "金属", "侵す")),
]
# 類語の辞書：言葉 → (仲間の名前, 日本語)。仲間の木：生き物 > 人、物 > 食べ物・化学の物・金属
THESAURUS = {
    "man": ("人", "人"), "he": ("人", "彼"), "she": ("人", "彼女"), "president": ("人", "大統領"),
    "vegetables": ("食べ物", "野菜"), "potatoes": ("食べ物", "じゃがいも"), "bread": ("食べ物", "パン"),
    "acid": ("化学の物", "酸"), "sulphuric acid": ("化学の物", "硫酸"),
    "metal": ("金属", "金属"), "iron": ("金属", "鉄"), "copper": ("金属", "銅"),
}
PARENT = {"人": "生き物", "食べ物": "物", "化学の物": "物", "金属": "物"}

def close(a, b):
    """2つの単語の類似度：同じ単語 1.0、同じ仲間 0.8、同じ上位概念 0.3、その他 0"""
    if a == b:
        return 1.0
    ga, gb = THESAURUS[a][0], THESAURUS[b][0]
    if ga == gb:
        return 0.8
    return 0.3 if PARENT[ga] == PARENT[gb] else 0.0

def translate(subj, obj):
    best, best_s = None, -1
    for (es, ev, eo), jp in EXAMPLES:
        s = close(subj, es) * close(obj, eo)  # 両方とも置き換えられるときだけ、スコアが高くなる
        print(f"   例文「{es} {ev} {eo}」との近さ {s:.2f}")
        if s > best_s:
            best, best_s = ((es, ev, eo), jp), s
    if best_s < 0.5:
        return None
    (_, _, _), (js, jo, jv) = best
    return f"{THESAURUS[subj][1]}は{THESAURUS[obj][1]}を{jv}。"

for subj, obj in [("he", "potatoes"), ("sulphuric acid", "iron"), ("acid", "vegetables")]:
    print(f"訳したい文：{subj.capitalize()} eats {obj}.")
    out = translate(subj, obj)
    print(f"   → {out if out else '似た例文がないため、訳を出力しない'}\n")
print("eat の訳が「たべる」か「侵す」かは、文法規則ではなく、似た例文によって決まった")

101982–1986 · Japan

Which Boom Is This?

In 1980s Japan, what was the AI craze called at the time?

In the National Diet Library's full-text search, a magazine from October 1982 already has the sentence (translated). The same magazine the next month called the boom of about 20 years earlier (translated). In 1985, a book has (translated), the Diet has (translated) (meaning that now is the second boom), and a magazine feature is titled (translated), so the way of counting was all over the place.

The trigger also differed from writer to writer: the Fifth Generation project, MYCIN's success, Feigenbaum's knowledge engineering, and tools for building AI were all named. Even in the middle of the boom there were cool voices saying (translated).

In July 1986, more than 700 people gathered and the Japanese Society for Artificial Intelligence was founded. Its prospectus noted that the United States has had the AAAI since 1980, but (translated). In the figure on the right, look at the names one at a time.

111984 · Hopes and warnings

Two Rooms at the Same Conference

In the middle of the boom, did the people selling AI and the people researching it see the same future?

In August 1984, the American Association for Artificial Intelligence (AAAI) held its conference at the University of Texas at Austin. In the exhibition hall, the brochure for TIMM, an AI tool that builds in experts' knowledge, boasted and said that expert systems do not get sick, quit, or take early retirement. To a reporter, the voices of the sellers sometimes sounded like .

In a discussion at the same conference, “The Dark Ages of AI”, the chair John McDermott laid out a . Within about five years, America's Strategic Computing program fails, Japan's Fifth Generation gets stuck, new companies go bankrupt, funding dries up, and everyone changes the name of their research. He said some people call this . In the figure on the right, move through the years and see which item happened when.

What you think you knowThe popular story:“The 1984 discussion predicted the AI winter exactly (a warning that came true)” is what people tend to say
The original source says:the chair himself said . Much of the scenario did happen afterward, but not all at once five years later.

121983–1984 · Common sense

Amniotic Fluid in a Male Patient

Can a machine notice that something is “wrong” when no rule says so?

A footnote in the MYCIN book (1984) tells this story. John McCarthy entered amniotic fluid as the culture site (the source of the specimen) for a male patient, and MYCIN did not notice the mistake and accepted it. This was because the common sense that everyone knows, that men have no amniotic fluid, was written nowhere in the rules.

In his 1984 piece , McCarthy pointed out that MYCIN has no view of what happens after a treatment, and cannot even answer . Nilsson (2010) uses the word brittle for the weakness of such systems.

In the figure on the right (a bicycle consultation), choose an impossible answer. Adding common-sense rules lets the system notice, but as the kinds of answers grow, the number of pairs to check for compatibility increases sharply.

number of pairs to check = n(n − 1) / 2

n: number of kinds of answers (facts). With n＝100 there are 4,950 pairs, and with 1,000 there are 499,500

What you think you knowThe popular story:“There is a story that McCarthy teased MYCIN (a rumor)” is what has been passed down
The original source says:MYCIN's own developers give as the source in a footnote of their 1984 book. But this story does not appear in McCarthy's own 1984 piece.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_common_sense.py

# u06 常識の穴：ルールに書いていない「ありえない組み合わせ」を、システムはそのまま受け入れてしまう
#
# どの出来事か：MYCIN の本（1984）の注に書かれた話（記録 mycin_mccarthy_amniotic_1983）。ジョン・マッカーシーさんが
#   男性患者の検査材料を羊水と入力したところ、MYCIN は間違いに気づかず受け入れた。
#   マッカーシーさんは 1984 年の文章で、いくつかのエキスパートシステムには常識が必要だ、と書いた。
# このサンプル：医学ではなく自転車の相談（このサイトが作った知識）。ありえない答えを入力しても、ルールは動いてしまう。
#   「常識の決まり」（2 つの答えが両立するか）を足すと気づけるが、答えの種類 n が増えると、
#   確認する組み合わせの数は n（n − 1）／ 2 で増えていく。
# 試してみよう：
#   - COMMON_SENSE を空にすると、どうなるか
#   - n を 10・100・1000 にして、組み合わせの数を見る

FACTS = {"車輪の数": 3, "こぐと音がする": True, "チェーンの無い自転車": True, "空気を入れたのは今朝": True, "タイヤを押すとへこむ": True}

RULES = [
    (lambda f: f["こぐと音がする"], "チェーンの油切れ（確信度 0.3）"),
    (lambda f: f["タイヤを押すとへこむ"], "空気が少ない（確信度 0.9）"),
]

COMMON_SENSE = [  # 両立しない組み合わせ（このサイトが作った常識のルール）
    (lambda f: f["車輪の数"] != 2, "自転車の車輪は 2 つのはず（三輪車の相談ではない）"),
    (lambda f: f["チェーンの無い自転車"] and f["こぐと音がする"], "チェーンが無いのに、チェーンの油切れは考えられない"),
    (lambda f: f["空気を入れたのは今朝"] and f["タイヤを押すとへこむ"], "今朝入れたのにへこむなら、パンクを先に疑う"),
]

print("■ ルールだけ：")
for cond, concl in RULES:
    if cond(FACTS):
        print("   結論：", concl)

print("\n■ 常識のルールを足すと：")
for bad, why in COMMON_SENSE:
    if bad(FACTS):
        print("   おかしい！", why)

print("\n答えの種類 n と、両立するか確認する組み合わせの数 n(n-1)/2：")
for n in (5, 10, 100, 1000, 10000):
    print(f"   n = {n:>6,} → {n * (n - 1) // 2:>12,} 組")
print("常識は、書き出そうとすると膨大な数になる。この「もろさ」を、常識を大量に書き込んで乗り越えようとしたのが、1985 年の CYC プロジェクトだ。")

131985 · Prediction

Common Sense, One Encyclopedia's Worth

How many years would it take to write in all of common sense?

In 1985, Douglas Lenat and his colleagues at MCC in Austin, Texas announced the CYC project. It is an attempt to overcome the of expert systems and the difficulty of acquiring knowledge with a large body of common sense. Over the next 10 years they would write the knowledge of a one-volume encyclopedia (about 30,000 entries) and the common sense underneath it. About 400 entries would be written carefully by themselves, and the rest copied and corrected by many typists. The effort was . They also wrote that if they had not got there in about 10 years, they would drastically rethink the project.

In 2023, Lenat and Gary Marcus called CYC , and wrote that its knowledge base is made of tens of millions of hand-written assertions, built over 40 years and 2,000 person-years. Move through the years in the figure on the right.

But the 150 person-years were for the people typing in the encyclopedia, and the 2,000 person-years for the whole knowledge base, so the scope of the count is not the same. How much common sense is enough is unknown in 1985, and unknown today.

person-years = number of people × number of years　　2,000 person-years ÷ 40 years = 50 people on average

Person-year: the amount of work one person does in one year

141982–1987 · Japan

Translation Software and an “Illusion”

How far could machine translation by rules be used in the 1980s?

In fiscal 1982, the national machine translation project Mu (of the Science and Technology Agency) began. It aimed to show that abstracts of scientific and technical papers could be translated between Japanese and English. It was led by Makoto Nagao and others at Kyoto University, and continued until 1986. They built grammars and dictionaries for three stages: analyze the sentence, convert its structure into the form of the other language, and generate the sentence.

Companies also released translation software (Fujitsu's ATLAS in 1984, Hitachi's HICATS/JE from May 1986, and others). In September 1987 at the machine translation summit in Hakone, Nagao said that . To users' expectation that he answered , and said that companies' exaggerated advertising was one cause. Mazda used it to translate maintenance manuals. At first only 40% of the translations were , but after adjusting it with Fujitsu, the accuracy reached about 80%, it reported.

In the figure on the right, try adding a dictionary of technical terms. Sentences from the manual become translatable, but the translation of ordinary sentences does not change.

What you think you knowThe popular story:“Machine translation came to be used in real work much later (translation by deep learning in the 2010s)” is what people tend to think
The original source says:according to the record of the 1987 meeting, more than ten companies in Japan were selling translation software, and some companies, like Mazda, used it to translate manuals.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_transfer_mt.py

# u06 ルールに基づく翻訳機：解析 → 変換 → 生成の 3 段階と、専門用語の追加による精度の向上
#
# どの出来事か：国の機械翻訳プロジェクト Mu（1982〜1986 年、記録 mu_mt_project_1982）と、1980 年代の日本企業の翻訳ソフト
#   （記録 japan_commercial_mt_1984_1987）。Mu の 1985 年の論文では、解析・変換・生成の 3 段階の文法と辞書が示された。
#   1987 年の会議で、マツダは翻訳ソフトで自動車の整備マニュアルを翻訳し、初めは「よい、または直せる」訳が 40% だったが、
#   富士通と調整して約 80% の精度にしたと報告した。
# このサンプル：短い英文を日本語に翻訳する、このサイトが作った小さな翻訳機（本物の Mu や ATLAS ではない）。
#   ①解析：単語の品詞を辞書で引き、主語・動詞・目的語を見つける。
#   ②変換：英語の語順（主語・動詞・目的語）を日本語の語順（主語・目的語・動詞）へ並べ替える。
#   ③生成：助詞を補って文にする。辞書にない単語があると、訳を出さずに元の単語を残す。
# 試してみよう：
#   - ADD_DOMAIN を True にして、マニュアルの文の翻訳精度がどう変わるかを見る
#   - 日常の文（EVERYDAY）の精度は変わるか

ADD_DOMAIN = False

DICT = {  # 単語 → (品詞, 訳)。n＝名詞、v＝動詞
    "the": ("det", ""), "a": ("det", ""), "mechanic": ("n", "整備士"), "checks": ("v", "点検する"),
    "replace": ("v", "交換する"), "car": ("n", "車"), "engine": ("n", "エンジン"), "he": ("n", "彼"),
    "eats": ("v", "食べる"), "bread": ("n", "パン"), "reads": ("v", "読む"), "book": ("n", "本"),
}
DOMAIN = {  # 整備マニュアルの用語（専門用語の辞書）
    "technician": ("n", "整備士"), "tightens": ("v", "締める"), "tighten": ("v", "締める"), "bolt": ("n", "ボルト"),
    "drain": ("v", "抜く"), "oil": ("n", "オイル"), "inspect": ("v", "点検する"), "brake": ("n", "ブレーキ"),
    "pads": ("n", "パッド"), "coolant": ("n", "冷却水"),
}
MANUAL = ["the technician tightens the bolt", "drain the oil", "inspect the brake pads", "replace the coolant",
          "the mechanic checks the engine"]
EVERYDAY = ["he eats bread", "a child reads the book", "he reads a letter"]

def translate(sentence, dic):
    words = sentence.split()
    tags = [dic.get(w, ("?", w)) for w in words]                      # ① 解析：辞書を引く
    if any(t == "?" for t, _ in tags):
        return None, "辞書にない：" + ", ".join(w for w, (t, _) in zip(words, tags) if t == "?")
    nouns = [tr for t, tr in tags if t == "n"]
    verb = next((tr for t, tr in tags if t == "v"), None)
    vi = next(i for i, (t, _) in enumerate(tags) if t == "v")
    subj = next((tr for t, tr in tags[:vi] if t == "n"), None)          # 動詞より前の名詞＝主語
    obj = next((tr for t, tr in tags[vi + 1:] if t == "n"), None)       # 動詞より後の名詞＝目的語
    obj = "".join(tr for t, tr in tags[vi + 1:] if t == "n") or obj     # 名詞が 2 つ続く時は連結する
    out = (f"{subj}は" if subj else "") + (f"{obj}を" if obj else "") + verb   # ② 変換 ③ 生成
    return out + "。", ""

dic = dict(DICT, **(DOMAIN if ADD_DOMAIN else {}))
for name, test in (("整備マニュアルの文", MANUAL), ("日常の文", EVERYDAY)):
    ok = 0
    print(f"■ {name}（専門用語の辞書 {'あり' if ADD_DOMAIN else 'なし'}）")
    for s in test:
        out, why = translate(s, dic)
        ok += out is not None
        print(f"   {s:<32} → {out or '（訳せない）' + why}")
    print(f"   翻訳できた割合：{ok}/{len(test)}\n")
print("ルールに基づく翻訳機は、専門辞書とルールを追加するほど、その分野では精度が上がる。ただし分野外の文の精度は上がらない。")

151985 · Japan

A Robot That Accompanies Your Singing

If a person starts singing a little higher, how does the accompaniment keep up?

Several research labs at Waseda University began preparing in 1980, and from 1981 built WABOT-2, a robot that plays musical instruments. Rather than a robot that does everything, they narrowed the goal to (translated), which takes both dexterity and intelligence. It talks with people in Japanese, reads a commercially printed score with a camera in about 15 seconds, and plays an electronic organ with the fingers of both hands and both feet. It has 50 degrees of freedom in total, and used 53 small computers for motion control alone.

To follow a singer, it makes note data on the spot from the singing voice and compares it with the stored score to find the gap. When the gap went over a set value (the threshold), it transposed the piece to match the voice in the next performance. Pitch is written in base 12, where the upper digit shows the octave and the lower digit the semitone. The control that ties everything together was written as if-then rules. In the figure on the right, move the singer's gap.

number of semitones = 12 × log₂(frequency of the singing ÷ frequency of the note in the score)

log₂: the power to which 2 is raised to get that number
Frequency doubled: 1 octave (12 semitones)

What you think you knowThe popular story:“The one that played the electronic organ at the Tsukuba Expo was Waseda University's WABOT-2” is what people tend to say
The original source says:in the developers' papers of 1985 and 1987, the performer at the Japanese Government Pavilion theme hall of the Science Expo was WASUBOT, built by Sumitomo Electric Industries on the basis of WABOT-2.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_transpose.py

# u06 歌声に合わせて移調する：歌の高さのずれを半音単位で測り、伴奏を移調する
#
# どの出来事か：1985 年の演奏ロボット WABOT-2（記録 wabot2_wasubot_expo85_1985）。開発者らの 1985 年の論文によると、
#   歌声トラッキングの仕組みは、歌声からその場で音符コードを生成し、記憶させた楽譜と比較して演奏と歌声のずれを検出した。
#   ずれが一定のしきい値を超えると、次の演奏時に歌声に合わせて曲を移調した。
#   音の高さは 12 進数で表し、上の桁がオクターブ、下の桁が半音の違いを表した。
# このサンプル：同じ考え方で作った小さなモデル。歌声の周波数（Hz）は、このサイトが作った数（歌う人が 3 半音高く歌い出したと仮定）。
#   半音の数 ＝ 12 × log₂（歌の周波数 ÷ 楽譜の音の周波数）
# 試してみよう：
#   - SHIFT を -2 や 0.4 に変える（しきい値より小さいずれでは移調しない）
#   - THRESHOLD を変える

import math
import random

SCORE = [60, 60, 67, 67, 69, 69, 67, 65, 65, 64, 64, 62, 62, 60]  # 楽譜の音（番号 60 ＝ ド。1 つ上がると半音上）
SHIFT = 3.0       # 歌う人が楽譜より何半音高く歌うか（このサイトが作った数）
THRESHOLD = 0.5   # これより大きなずれで移調する（このサイトが作った数）
random.seed(6)

def hz(n):
    """音の番号 → 周波数（番号 69 ＝ 440 Hz のラ）"""
    return 440 * 2 ** ((n - 69) / 12)

def note_code(n):
    """論文と同じ考え方の 12 進法：上の桁＝オクターブ、下の桁＝半音（0〜11）"""
    o, s = divmod(round(n), 12)
    return f"{o}{'0123456789AB'[s]}"

sung = [hz(n + SHIFT) * (1 + random.gauss(0, 0.01)) for n in SCORE]   # 歌声（わずかに揺れる）
diffs = [12 * math.log2(f / hz(n)) for f, n in zip(sung, SCORE)]
print("楽譜 → 歌声（音符コード）  ずれ（半音）")
for n, f, d in zip(SCORE, sung, diffs):
    print(f"  {note_code(n)} → {note_code(69 + 12 * math.log2(f / 440))}   {d:+.2f}")

mean = sum(diffs) / len(diffs)
print(f"\nずれの平均：{mean:+.2f} 半音")
if abs(mean) > THRESHOLD:
    k = round(mean)
    print(f"しきい値 {THRESHOLD} を超えた → 伴奏を {k:+d} 半音移調する")
    print("移調した伴奏：", " ".join(note_code(n + k) for n in SCORE))
else:
    print("ずれが小さいので、そのまま演奏する")

161965 · Fuzzy sets

From How Many cm Is Someone “Tall”?

Where is the boundary of a “tall person”? How many cm?

In 1965, Lotfi Zadeh of the University of California, Berkeley, in his paper , described collections with no clear boundary, such as , by a number from 0 to 1 (the degree of membership) that says how much each element belongs. As an example of the , the paper gives values such as f(10) = 0.2 and f(100) = 0.95.

He also set rules for calculating. “Not A” is 1 − f, “A or B” is the larger, and “A and B” is the smaller. In the figure on the right, compare an ordinary set that jumps from 0 to 1 at 175 cm with a smooth fuzzy set. The paper also says that this is a completely different idea from statistics.

In 1980 he looked back and said that he had known from the start that the word fuzzy has a belittling ring.

Not A: 1 − f_A　A or B: max(f_A, f_B)　A and B: min(f_A, f_B)

f_A: degree of membership in set A (0–1)
max, min: the larger, the smaller

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_membership.py

# u06 ファジィ集合：「入る・入らない」ではなく、「どのくらい入るか」を 0〜1 の数で表す
#
# どの出来事か：1965 年のザデーの論文「ファジィ集合」（記録 zadeh_fuzzy_sets_1965）。
#   論文は、ものがどれくらいその集合に含まれるかを、0 から 1 の数値（所属度）で表した。
#   例として「1 よりずっと大きい実数」の集合を挙げ、f(0)=0、f(1)=0、f(5)=0.01、f(10)=0.2、f(100)=0.95、f(500)=1 とした。
#   また、「でない」は 1 − f、「または」は大きい方（Max）、「かつ」は小さい方（Min）と定めた。
# このサンプル：①論文の数値を、あいだを直線でつないで使う ②「背が高い」「重い」の度合い（このサイトが作った例）から、
#   かつ・または・でない を計算する。
# 試してみよう：
#   - tall() の 160・185 を変えて、「背が高い」の度合いの形を変える
#   - 通常の集合（175 cm 以上なら 1、それ以外は 0）と比べる

POINTS = [(0, 0), (1, 0), (5, 0.01), (10, 0.2), (100, 0.95), (500, 1)]  # 論文の例

def much_greater_than_1(x):
    for (x0, y0), (x1, y1) in zip(POINTS, POINTS[1:]):
        if x0 <= x <= x1:
            return y0 + (y1 - y0) * (x - x0) / (x1 - x0)
    return 1.0

def ramp(x, a, b):
    """a 以下で 0、b 以上で 1、その間を直線でつなぐ（このサイトが作った例）"""
    return 0.0 if x <= a else 1.0 if x >= b else (x - a) / (b - a)

def tall(cm):
    return ramp(cm, 160, 185)

def heavy(kg):
    return ramp(kg, 55, 85)

print("「1 よりずっと大きい数」の度合い（論文の数値を直線で補間）")
for x in (1, 5, 10, 50, 100, 300):
    print(f"  {x:>4} → {much_greater_than_1(x):.2f}")

print("\n背が高い（ファジィ）と通常の集合（175 cm 以上）")
for cm in (158, 168, 174, 176, 182, 190):
    print(f"  {cm} cm → ファジィ {tall(cm):.2f}   通常 {1 if cm >= 175 else 0}")

print("\nかつ・または・でない（身長 178 cm・体重 62 kg の人）")
t, h = tall(178), heavy(62)
print(f"  背が高い {t:.2f}、重い {h:.2f}")
print(f"  背が高い かつ 重い   ＝ min = {min(t, h):.2f}")
print(f"  背が高い または 重い ＝ max = {max(t, h):.2f}")
print(f"  背が高く ない        ＝ 1 − f = {1 - t:.2f}")

171987 · Japan

Stopping a Subway with Fuzzy Logic

How does a skilled driver stop exactly on the mark without jolting the train?

On July 15, 1987, the Sendai City subway opened. The automatic train operation device developed by Hitachi used (translated). According to the company's 1988 article, it combined three things: AI (knowledge engineering) rules written in (translated) (the if-then form); a simulation that stands in for the skill of an expert driver; and fuzzy theory, which expresses several criteria as satisfaction degrees from 0 to 1 and combines them. Ride comfort, stopping accuracy and energy saving improved, and the article calls it (translated) (the words of the company that built it).

The figure on the right is a simple example of the same way of thinking, not Sendai's actual device. Compare three methods by their stopping-position error and the change in braking (the jolt): using just one rule, mixing several rules, and predicting ahead and choosing the brake with the highest satisfaction.

satisfaction = min(satisfaction with the stopping position, satisfaction with ride comfort) → choose the brake with the highest value

Satisfaction with the stopping position: predicted ahead, 1 when the train stops close to the target
Satisfaction with ride comfort: 1 when the change in braking is small (the setting in this figure)

What you think you knowThe popular story:“Fuzzy is a buzzword for home appliances” is what people tend to think
The original source says:before appliances, it was used in the automatic operation of the Sendai City subway that opened in 1987.

Brake strength over time

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_fuzzy_brake.py

# u06 ファジィ制御で電車を止める：「近くて速ければ、強めにブレーキ」のあいまいなルール
#
# どの出来事か：1987 年 7 月 15 日、仙台市の地下鉄が開業。列車の自動運転に「予見ファジィ制御」を使った
#   （記録 sendai_subway_fuzzy_ato_1987）。上手な運転士の技を、「もし〜なら〜する」の形のルールで書いた。
#   ファジィ集合そのものは、1965 年のザデーの論文から始まった（記録 zadeh_fuzzy_sets_1965）。
# このサンプル：同じ考え方の小さなモデル（仙台の装置そのものではない）。ホームの停止位置の 200m 手前から
#   時速 60km で入ってくる電車を止める。ルールはどちらも同じ 3 つ（少し→弱く、中くらい→中くらい、たくさん→強く）。
#   ①通常のルール：最も当てはまる 1 つだけを使う　②ファジィ制御：あてはまり具合に応じて 3 つを混ぜて使う。
#   停止位置の誤差と、ブレーキの強さの変わり方（乗り心地）を比べる。
# 試してみよう：
#   - OUT（ルールごとのブレーキの強さ）を変えてみる
#   - DT（制御の間隔の秒数）を 1.0 にすると、止まり方はどう変わるか

DT = 0.5           # 0.5 秒ごとに計算して制御する
MAX_DECEL = 1.2    # 最大ブレーキで 1 秒に速さが何 m/s 落ちるか（仮の数）

def tri(x, a, b, c):
    """三角形の「あてはまり具合」（0〜1）。b でいちばん 1 に近い"""
    if x <= a or x >= c:
        return 0.0
    return (x - a) / (b - a) if x < b else (c - x) / (c - b)

def need_ratio(dist, speed):
    """停止位置でちょうど止まるのに必要な減速度が、最大ブレーキの何倍か（先を読む＝予見）"""
    return speed * speed / (2 * max(dist, 0.5)) / MAX_DECEL

def memberships(dist, speed):
    ratio = need_ratio(dist, speed)                   # 1 なら最大ブレーキが必要
    few = tri(ratio, -1.0, 0.0, 0.6)                  # 必要な減速度は「少し」
    mid = tri(ratio, 0.3, 0.7, 1.0)                   # 「中くらい」
    big = min(1.0, max(0.0, (ratio - 0.8) / 0.3))     # 「たくさん」
    return few, mid, big

OUT = (0.1, 0.6, 1.0)   # ルールごとのブレーキの強さ：少し → 弱く、中くらい → 中くらい、たくさん → 強く

def fuzzy_brake(dist, speed):
    """ファジィ制御：3 つのルールを、あてはまり具合で重みをつけて混ぜる"""
    m = memberships(dist, speed)
    w = sum(m)
    return sum(mi * o for mi, o in zip(m, OUT)) / w if w else 0.0

def crisp_brake(dist, speed):
    """通常のルール：同じ 3 つのルールのうち、いちばん当てはまる 1 つだけを使う（はい・いいえ）"""
    m = memberships(dist, speed)
    return OUT[m.index(max(m))]

def run(brake):
    pos, v, t, last = 0.0, 60 / 3.6, 0.0, 0.0
    jumps, biggest = 0.0, 0.0
    while v > 0 and t < 300:
        b = brake(200 - pos, v)
        jumps += abs(b - last)
        biggest = max(biggest, abs(b - last))
        last = b
        v = max(0.0, v - b * MAX_DECEL * DT)
        pos += v * DT
        t += DT
    return 200 - pos, jumps, biggest, t

for name, f in (("通常のルール（1 つだけ使う）", crisp_brake), ("ファジィ制御（混ぜて使う）", fuzzy_brake)):
    err, jumps, biggest, t = run(f)
    print(f"{name}：停止位置の誤差 {err:+.1f} m（＋は手前）、ブレーキの強さの変化の合計 {jumps:.1f}、1 回での最大変化 {biggest:.2f}、停止まで {t:.0f} 秒")
print("ブレーキの強さの変化が小さいほど、乗っている人はがくんと揺れない")

181980–1990 · Checking a prediction

The “Standard Tool” Became a Washer

Where did the forecast for fuzzy logic get its answer?

In September 1980, Zadeh wrote that fuzzy set theory was starting to be used everywhere from industrial process control to medical diagnosis, and was . He gave no deadline year.

Seven years later, in 1987, the Sendai City subway adopted it, and in 1989, 48 companies founded the Laboratory for International Fuzzy Engineering Research (LIFE). On February 1, 1990, Matsushita Electric released a washing machine, “Aisaigo Day Fuzzy”. From the time it takes for the cloudiness of the water to settle and the transmittance once it has settled, it decides the washing time with 6 rules, such as (translated). That year, the gold prize in the new-word category of the year's buzzword awards went to . In the figure on the right, change the amount and kind of dirt.

washing time = Σ(fit × time of the rule) ÷ Σ fit

Fit: min(degree of T, degree of V)
T: time until the cloudiness settles
V: transmittance once it has settled

Change of transmittance over time (the curves and rules are an example made up for this site)

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_fuzzy_washer.py

# u06 ファジィ洗濯機：水の濁り方から、洗い時間を 6 つの「もし〜なら〜」ルールで決める
#
# どの出来事か：1990 年 2 月 1 日に発売された松下電器の全自動洗濯機（記録 fuzzy_washer_ryukogo_1990 と、
#   ザデーの 1980 年の予測記録 zadeh_fuzzy_standard_tool_prediction_1980）。開発者の 1990 年の記事によると、
#   排水弁の近くで光を当て、洗濯水を通る光の強さ（透過度）を測定する。洗い始めると汚れが溶け出して透過度が下がり、
#   やがて落ち着く。落ち着くまでの時間 T（泥の汚れは早く、脂の汚れは遅い）と、落ち着いたときの透過度 V（汚れが多いほど低い）
#   から、6 つのルールのファジィ推論で洗い時間を決めた。ルールは「飽和時間が長く、かつ透過度が低ければ
#   洗濯時間をとても長くする」のような形式で、家庭で集めたデータと作る人のコツから作られた。
# このサンプル：同じ仕組みの簡易推論。6 つのルールの中身・形・時間（分）の数は、このサイトが作った例。
#   「かつ」は最小値（min）をとる。ルールごとの洗い時間を、あてはまり具合で重みをつけて平均する（後件部が数値の簡便法）。
# 試してみよう：
#   - T と V を変えて、洗い時間がなめらかに変化するか確認する
#   - ルールを 1 つ削除すると、どこで時間が急変するか確かめる

def ramp(x, a, b):
    return 0.0 if x <= a else 1.0 if x >= b else (x - a) / (b - a)

def t_short(t): return 1 - ramp(t, 60, 180)     # 落ち着くのが早い（秒）
def t_long(t): return ramp(t, 60, 180)          # 落ち着くのが遅い
def v_high(v): return ramp(v, 0.4, 0.8)         # 透過度が高い（きれい）
def v_mid(v): return 1 - abs(v - 0.55) / 0.25 if abs(v - 0.55) < 0.25 else 0.0
def v_low(v): return 1 - ramp(v, 0.3, 0.6)      # 透過度が低い（汚れが多い）

RULES = [  # (T の形, V の形, 洗い時間（分）)
    (t_short, v_high, 4), (t_short, v_mid, 7), (t_short, v_low, 10),
    (t_long, v_high, 6), (t_long, v_mid, 10), (t_long, v_low, 15),   # 飽和時間が長く、かつ透過度が低い → とても長く
]

def wash_time(T, V, show=False):
    w = [min(ft(T), fv(V)) for ft, fv, _ in RULES]
    if show:
        for (ft, fv, m), wi in zip(RULES, w):
            print(f"   もし T が{'短い' if ft is t_short else '長い'}、かつ V が{ {v_high: '高い', v_mid: '中くらい', v_low: '低い'}[fv]} なら {m:>2} 分 … あてはまり {wi:.2f}")
    return sum(wi * m for wi, (_, _, m) in zip(w, RULES)) / sum(w)

T, V = 150, 0.35   # 脂の汚れが多い場合（このサイトが作った数）
print(f"T = {T} 秒、V = {V}")
print(f"→ 洗い時間 {wash_time(T, V, show=True):.1f} 分\n")

print("T を変えたときの洗い時間（V = 0.5）")
for t in range(40, 221, 30):
    m = wash_time(t, 0.5)
    print(f"   T = {t:>3} 秒 → {m:4.1f} 分 " + "■" * round(m))

191980–1989 · Upkeep

The Rules Kept Growing

Once you build an AI with rules in it, are you done?

The rules of R1 (XCON) kept growing from 772 in June 1980. When DEC took over the upkeep there were about 1,000, around July 1982 about 2,000, and in 1984 2,500, and in 1989 the related systems together had 17,500. This was because each time DEC released a new product, the assembly work itself changed.

According to an article written by DEC people in 1984, continuing to add knowledge took about four people's work every year, and, as they said of upkeep, , and it needs specially trained people. In that same year, 1984, the brochure in the exhibition hall boasted that expert systems never quit or retire.

New rules need to be checked for contradiction with the rules that came before. In the figure on the right, press a dot to see the number of rules at that time and the number of pairs.

number of pairs = n(n − 1) / 2

n: number of rules. With 772 there are 297,606 pairs, and with 17,500 about 153 million pairs

What you think you knowThe popular story:“XCON was a great success that saved $40 million every year” is what people tend to say
The original source says:that figure is an estimate in a 1989 paper by a DEC person, , and this site has confirmed it only through Nilsson's citation. The 1984 article by DEC people gives no dollar amount, and describes the effort of upkeep.

201977– · Acquiring knowledge

Widening the Narrow Pipe

How do you move the knowledge in an expert's head into a computer?

In 1977, in the invited paper , Feigenbaum wrote that . A bottleneck is the narrowest passage, like the neck of a bottle. There was also a case where drawing out the knowledge took little effort: PUFF, a program for diagnosing lung tests, got 55 rules from under 50 hours of exchanges with experts, under 10 person-weeks of work.

The same paper introduced, as one way to widen the pipe, META-DENDRAL, a program that automatically finds rules from measurement data on molecules whose structures are known. The rules it found were said to be on a par with the experts' rules in quality. The figure on the right shows the simplest method: finding rules one at a time from examples that come with answers.

Rules written by people kept needing upkeep. The road of learning from data grows in Chapters 8 and 9.

What you think you knowThe popular story:“Second-boom AI could only have experts' knowledge written in by hand, and learning from data begins with the third boom” is how people tend to divide it
The original source says:the 1977 paper that wrote about the bottleneck itself introduced, as one answer to it, META-DENDRAL, which finds rules automatically from data.

This is the same mechanism as "Try it", written as Python code. Press ▶ Run and the result appears below. Change the numbers and run it again.

u06_rule_induction.py

# u06 データからルールを見つける：人から聞き出す代わりに、正解付きのデータから「もし〜なら〜」を作る
#
# どの出来事か：1977 年のファイゲンバウムの論文（記録 feigenbaum_knowledge_bottleneck_1977）。
#   論文は、専門分野の知識を手に入れることがボトルネック（いちばん狭い通り道）の問題だった、と書いた。
#   その答えの 1 つとして、構造の分かっている分子の測定データからルールを見つけるプログラム META-DENDRAL を紹介した。
# このサンプル：分子ではなく、自転車の相談の例（このサイトが作ったデータ）。正解（原因）の付いた事例から、
#   「多くの例をまちがいなく説明できる条件」を 1 つずつ選んでルールにし、説明できた例を除いて繰り返す
#   （例を順にカバーしていくやり方。META-DENDRAL の手順そのものではない）。
# 試してみよう：
#   - EXAMPLES の正解を 1 つ変えると、見つかるルールはどう変わるか
#   - 例を減らすと、ルールはどうなるか

EXAMPLES = [  # (こぐと音, さび, 雨ざらし, へこむ, 重い, 答え)
    (1, 1, 1, 0, 0, "油切れ"), (1, 0, 1, 0, 1, "油切れ"), (1, 1, 0, 0, 0, "油切れ"), (1, 0, 1, 0, 0, "油切れ"),
    (0, 0, 0, 1, 1, "空気"), (0, 0, 1, 1, 1, "空気"), (1, 0, 0, 1, 1, "空気"), (0, 1, 0, 1, 0, "空気"),
    (0, 0, 0, 0, 1, "ブレーキ"), (0, 1, 0, 0, 1, "ブレーキ"), (0, 0, 1, 0, 1, "ブレーキ"),
]
NAMES = ["こぐと音がする", "さびている", "雨ざらし", "タイヤがへこむ", "重い"]

def conds():
    """1 つか 2 つの「〜がある／無い」の組み合わせをすべて作る"""
    single = [((i, v),) for i in range(len(NAMES)) for v in (1, 0)]
    pairs = [(a[0], b[0]) for a in single for b in single if a[0][0] < b[0][0]]
    return single + pairs

def fits(ex, cond):
    return all(ex[i] == v for i, v in cond)

def say(cond):
    return " かつ ".join(NAMES[i] + ("" if v else " でない") for i, v in cond)

left = list(EXAMPLES)
while left:
    best = None
    for cond in conds():
        covered = [ex for ex in left if fits(ex, cond)]
        labels = {ex[-1] for ex in covered}
        # 説明できる例が多く、誤りがない（答えが 1 種類だけ）条件を選ぶ。同じなら短く、「ある」の多い条件を優先する
        score = (len(covered), -len(cond), sum(v for _, v in cond))
        if len(labels) == 1 and (best is None or score > best[2]):
            best = (cond, covered, score)
    if best is None:
        print("これ以上、誤りのないルールは作れない")
        break
    cond, covered, _ = best
    print(f"見つけたルール：もし {say(cond)} なら {covered[0][-1]}（{len(covered)} 個の例を説明）")
    left = [ex for ex in left if ex not in covered]

print(f"\n{len(EXAMPLES)} 個の例から、人に聞かずにルールを作った。ただし、例にないことは分からない")

The Power Is in the Knowledge

Confidence Factors for “Probably”

Forward and Backward

A Machine You Can Ask “Why?”

Knowledge as Templates of Situations

Scoring with the Names Hidden

Weighing the Odds with Multipliers

Noticing the Missing Parts

Translating by Example Sentences

Which Boom Is This?

Two Rooms at the Same Conference

Amniotic Fluid in a Male Patient

Common Sense, One Encyclopedia's Worth

Translation Software and an “Illusion”

A Robot That Accompanies Your Singing

From How Many cm Is Someone “Tall”?

Stopping a Subway with Fuzzy Logic

The “Standard Tool” Became a Washer

The Rules Kept Growing

Widening the Narrow Pipe

What This Chapter Still Doesn't Know

Confidence Factors for