เส้นทางการเหนี่ยวนำที่สร้างสรรค์?


17

ฉันกำลังอ่านหนังสือ HoTTและฉันมีช่วงเวลายากลำบากในการบอกทาง

เมื่อฉันดูประเภทในส่วน1.12.1 : ผมไม่มีปัญหาการทำความเข้าใจสิ่งที่หมายถึง (ผมเพิ่งได้เขียนประเภทจากหน่วยความจำเพื่อตรวจสอบว่า)

ind=A:C:x,y:A(x=Ay)U((x:AC(x,x,reflx))x,y:Ap:x=AyC(x,y,p)),

สิ่งที่ฉันมีปัญหาคือคำสั่งถัดไปมาก:
ความประทับใจครั้งแรกของฉันคือการแสดงออกครั้งสุดท้ายนี้ไม่ได้กำหนดฟังก์ชั่นผลลัพธ์ f : x , y : A p : x = A y C ( x , y , p ) ,

with the equalityind=A(C,c,x,x,reflx):≡c(x)
f:x,y:Ap:x=AyC(x,y,p),
แต่เพียงระบุคุณสมบัติของมัน

นั่นคือตรงกันข้ามกับตัวอย่างก่อนหน้าของหลักการการเหนี่ยวนำ , ind A + Bหรือind N - มีการกำหนดสมการสำหรับองค์ประกอบเหล่านั้น - ที่จริงเรารู้วิธีการสร้างฟังก์ชั่นที่เกิดขึ้นให้สถานที่ ซึ่งสอดคล้องกับ "ความสร้างสรรค์" ของทฤษฎีประเภทที่โฆษณาตลอดทั้งบทindA×BindA+BindN

กลับไปที่ฉันสงสัยเกี่ยวกับความจริงที่ว่า (ดูเหมือน) ไม่ได้กำหนดไว้ การระบุว่าองค์ประกอบfเพิ่งปรากฏขึ้นพร้อมกับส่วนที่เหลือของบท และแน่นอนส่วน1.12.1ดูเหมือนจะเน้นว่าการแสดงผลของฉันไม่ถูกต้องและในความเป็นจริงเราได้กำหนดไว้แล้วind=Af

... ฟังก์ชั่น F : Π x , y ที่: Π P : x = Y C ( x , Y , P ) ,กำหนดโดย เส้นทางการเหนี่ยวนำจาก: Π x : C ( x , x , refl x ) , ซึ่งยิ่งไปกว่านั้น พอใจf ( x , x , refl x )f:x,y:Ap:x=AyC(x,y,p),
c:x:AC(x,x,reflx)
...f(x,x,reflx):≡c(x)

นั่นทำให้ฉันสับสนอย่างที่สุด แต่ฉันรู้สึกว่าประเด็นนี้สำคัญมากสำหรับการพัฒนาเพิ่มเติมทั้งหมด ดังนั้นการอ่านสองตัวสำหรับฉันควรจะไปด้วยไหน? หรืออาจเป็นไปได้ว่าฉันไม่มีความละเอียดอ่อนที่สำคัญและคำตอบก็คือ "ไม่"? ind=A


อย่างไรก็ตามนี่ไม่ใช่คำถามเฉพาะของ HoTT แต่เป็นคำถามที่ขึ้นกับประเภททั่วไป
ดี้

คำตอบ:


12

It is an illusion that the computation rules "define" or "construct" the objects they speak about. You correctly observed that the equation for ind=A does not "define" it, but failed to observe that the same is true in other cases as well. Let us consider the induction principle for the unit type 1, which seems particularly obviously "determined". According to Section 1.5 of the HoTT book we have

ind1:C:1TypeC()x:1P(x)
with the equation
ind1(C,c,)=c.
Does this "define" or "construct" ind1 in the sense that it leaves no doubt as to what ind1 "does"? For instance, set C(x)=N and a=42, and consider what we could say about
ind1(C,42,e)
for a given expression e of type 1. Your first thought might be that we can reduce this to 42 because " is the only element of 1". But to be quite precise, the equation for ind1 is applicable only if we show e, which is impossible when e is a variable, for example. We can try to wiggle out of this and say that we are only interested in computation with closed terms, so e should be closed.

Is it not the case that every closed term e of type 1 is judgmentally equal to ? That depends on nasty details and complicated proofs of normalization, actually. In the case of HoTT the answer is "no" because e could contain instances of the Univalence Axiom, and it is not clear what do to about that (this is the open problem in HoTT).

We can circumvent the trouble with univalance by considering a version of type theory which does have good properties so that every closed term of type 1 is judgmentally equal to . In that case it is fair to say that we do know how to compute with ind1, but:

  1. The same will hold for the identity type, because every closed term of an identity type will be judgmentally equal to some refl(a), and so then the equation for ind=A will tell us how to compute.

  2. Just because we know how to compute with closed terms of a type, that does not mean we have actually defined anything because there is more to a type than its closed terms, as I tried to explain once.

For example, Martin-Löf type theory (without the identity types) can be interpreted domain-theoretically in such a way that 1 contains two elements and , where corresponds to and to non-termination. Alas, since there is no way to write down a non-terminating expression in type theory, cannot be named. Consequently, the equation for ind1 does not tell us how to compute on (the two obvious choices being "eagerly" and "lazily").

In software engineering terms, I would say we have a confusion between specification and implementation. The HoTT axioms for the identity types are a specification. The equation ind=C(C,c,x,x,refl(x))c(x) is not telling us how to compute with, or how to construct ind=C, but rather that however ind=C is "implemented", we require that it satisfy the equation. It is a separate question whether such ind=C can be obtained in a constructive fashion.

Lastly, I am a bit weary of how you use the word "constructive". It looks as if you think that "constructive" is the same as "defined". Under that interpretation the Halting oracle is constructive, because its behavior is defined by the requirement we impose on it (namely that it output 1 or 0 according to whether the given machine halts). It is prefectly possible to describe objects which only exist in a non-constructive setting. Conversely, it is perfectly possible to speak constructively about properties and other things that cannot actually be computed. Here is one: the relation HN×{0,1} defined by

H(n,d)(d=1n-th machine halts)(d=0n-th machine diverges)
is constructive, i.e., there is nothing wrong with this definition from a constructive point of view. It just so happens that constructively one cannot show that H is a total relation, and its characteristic map χH:N×{0,1}Prop does not factor through bool, so we cannot "compute" its values.

Addendum: The title of your question is "Is path induction constructive?" After having cleared up the difference between "constructive" and "defined", we can answer the question. Yes, path induction is known to be constructive in certain cases:

  1. If we restrict to type theory without Univalence so that we can show strong normalization, then path induction and everything else is constructive because there are algorithms that perform the normalization procedure.

  2. There are realizability models of type theory, which explain how every closed term in type theory corresponds to a Turing machine. However, these models satisfy Streicher's Axiom K, which rules out Univalence.

  3. There is a translation of type theory (again without Univalence) into constructive set theory CZF. Once again, this validates Streicher's axiom K.

  4. There is a groupoid model inside realizability models which allows us to interpret type theory without Streicher's K. This is preliminary work by Steve Awodey and myself.

We really need to sort out the constructive status of Univalence.


I believe this answer is now (partially) out of date
WorldSEnder

Indeed, in the mean time cubical type theory gave a postive answer: there is a constructive model of Univalent type theory.
Andrej Bauer

7

I'm no HoTT person, but I'll throw in my two-cents.

Suppose we are wanting to make a function

fA:x,y:Ap:x=AyC(x,y,p)
How would we do this? Well, suppose we're given any x,y:A and a proof of their equality p:x=Ay. Since I know nothing about the arbitrary type A, I know nothing about the `structure' of x,y. However, I know something about the specific equality type: it has a single constructor,
refla:a=Aa, for any a:A
Hence, prefla for some a:A, but this would force x=a=y. Hence, if we had an element of C(x,x,reflx) for any x:A; ie if we had a function
baseC:x:AC(x,x,reflx)
(for our specific C), then our function fA can be defined as follows:
fA(x,y,p):=baseC(x,x,p)
.

Getting rid of the subscripts leads to the general inductive definition.

Hope that helps!


PS. I'm no HoTT guy, so I'm assuming `Axiom K'. More precisely, I'm assuming that an element e of type E must be the result of repeated applications of constructor of E. As far as I know, HoTT, probably chapter 2 onwards, throws away this notion ... and that makes absolutely no sense to me.


1
Perhaps you can make some sense of it, or at least get worried about your current intuitions by checking out math.andrej.com/2013/08/28/the-elements-of-an-inductive-type where I try to explain why it is harmful to think that the closed terms of a type are all there is to a type.
Andrej Bauer

2
By the way, you need not asssume Axiom K. For your answer to make sense, you need to know that every closed term of an identity type normalizes to refl. This has nothing to do with Axiom K, as such a normalization property does not prove axiom K, nor does it follow from axiom K.
Andrej Bauer

3

I'm an amateur HoTT guy, so I'll try to complement Moses' already great answer. Let me take the type A×B as an example. The basic principle of constructive type theory, as outlined by Martin-Löf, is that *every element of A×B is described as being in the image of the constructor:

pair : ABA×B
This philosophy allows us to define elimination: to build a function f out of A×B, it suffices to describe its action on the image of pair.

But since pair is a constructor (and so is in particular injective), this means exactly that to build a function f:A×BC, it suffices to describe it's action on a pair of elements in A and B, so

f:ABC
is sufficient to describe such an f. In conclusion, there is a canonical way to define functions out of A×B, and this can be encapsulated in the type
(ABC)(A×BC)
but this is exactly the type of indA×B.

But this is only half of the story: what happens if this newly constructed f is applied to a given pair(a,b)? Well then f should agree with its defining function f, i.e.

f(pair(a,b)) := f a b
i.e.
indA×B f pair(a,b) := f a b
and this should hold definitionally (or computationally), which means the two should be completely interchangeable in all situations (which is much different from the = in HoTT).

So you see that the definition of an eliminator for inductive type with given constructors comes in 2 steps:

  1. an existence principle, which describes the type of ind.

  2. a coherence principle which defines the computational behavior of ind. In category theory, this would correspond to uniqueness of the eliminator in some sense.


Let me argue that this is the same for the =A type. We want to build, given x,y:A and p:x=y, an element of C (we're forgetting the dependencies for simplification). To do that, we need to assume that p was built using a constructor for the type x=y, which can only be refl(z) for some z. This means that to give a function

f:Πx,y:A,x=yC
it suffices to give a function
f:Πz:A,C
which is defined for refl(z) (again, forgetting the dependencies in C).

Now what does the coherence principle say? Well simply that if applied to a known constructor, f should behave like f, which means

f z z refl(z):=f z

But that's exactly what you have above! The same principle that gave us the existence and coherence for the eliminator of A×B gives us the existence and coherence for the eliminator of =A.

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.