Properties over partly specified inductive families (HoTT)
$begingroup$
At the moment I'm about to get my head around homotopy type theory as a new perspective into mathematics. Insofar, I'm trying to mess around with it, prove some simple things and see where it gets; but I'm stuck, again.
The questions
My problem can be boiled down to a simple example. Consider a relatively simple inductive type family
$$mathsf{T} : mathbf{2}to mathbf{2}to mathcal{U}$$
defined by two constructors
- $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$
- $A_2 : Pi_{b : mathbf{2}} mathsf{T}(1_{mathbf{2}},b)$
where I'm using the notation from the HoTT Book, i.e. $mathbf{2}$ is a boolean, $mathcal{U}$ is some universe, etc.
Now,
- is there a function $f : Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b)to b = 0_{mathbf{2}}$?
- How is it defined?
- How is this definition justified (e.g. how would it be defined using the induction principle of $mathsf{T}$, or such)?
Ideas
From a meta perspective, one might argue: any term $t$ with type $mathsf{T}(0_{mathbf{2}},b)$ must be $A_1$, i.e. $t equiv A_1$. But then, $b equiv 0_{mathbf{2}}$, since $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$.
So, how defining this more formally. My first thought was, use induction over $mathsf{T}$ (resp. pattern matching), but this won't work, since its not defined for every $t : mathsf{T}$. Clearly
$$f(b, A_1) :equiv textsf{refl}_{0_{mathbf{2}}}$$
But what about $f(b, A_2)$?
Is there a way to use this idea within the theory?
Disclaimer
While this question might have an answer and explanation in a broader context then homotopy type theory, in the end I probably need some answer especially in HoTT, mainly because I'm not fluent in (intensional) type theory nor do I have sufficient skill to translate general ideas around pattern matching, type theory, etc. into HoTT (yet). But I'm thankful for any advice/hint. : )
type-theory homotopy-type-theory
$endgroup$
add a comment |
$begingroup$
At the moment I'm about to get my head around homotopy type theory as a new perspective into mathematics. Insofar, I'm trying to mess around with it, prove some simple things and see where it gets; but I'm stuck, again.
The questions
My problem can be boiled down to a simple example. Consider a relatively simple inductive type family
$$mathsf{T} : mathbf{2}to mathbf{2}to mathcal{U}$$
defined by two constructors
- $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$
- $A_2 : Pi_{b : mathbf{2}} mathsf{T}(1_{mathbf{2}},b)$
where I'm using the notation from the HoTT Book, i.e. $mathbf{2}$ is a boolean, $mathcal{U}$ is some universe, etc.
Now,
- is there a function $f : Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b)to b = 0_{mathbf{2}}$?
- How is it defined?
- How is this definition justified (e.g. how would it be defined using the induction principle of $mathsf{T}$, or such)?
Ideas
From a meta perspective, one might argue: any term $t$ with type $mathsf{T}(0_{mathbf{2}},b)$ must be $A_1$, i.e. $t equiv A_1$. But then, $b equiv 0_{mathbf{2}}$, since $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$.
So, how defining this more formally. My first thought was, use induction over $mathsf{T}$ (resp. pattern matching), but this won't work, since its not defined for every $t : mathsf{T}$. Clearly
$$f(b, A_1) :equiv textsf{refl}_{0_{mathbf{2}}}$$
But what about $f(b, A_2)$?
Is there a way to use this idea within the theory?
Disclaimer
While this question might have an answer and explanation in a broader context then homotopy type theory, in the end I probably need some answer especially in HoTT, mainly because I'm not fluent in (intensional) type theory nor do I have sufficient skill to translate general ideas around pattern matching, type theory, etc. into HoTT (yet). But I'm thankful for any advice/hint. : )
type-theory homotopy-type-theory
$endgroup$
$begingroup$
yes! A typo. Thanks. : ). Edited.
$endgroup$
– aphorisme
Dec 13 '18 at 18:22
add a comment |
$begingroup$
At the moment I'm about to get my head around homotopy type theory as a new perspective into mathematics. Insofar, I'm trying to mess around with it, prove some simple things and see where it gets; but I'm stuck, again.
The questions
My problem can be boiled down to a simple example. Consider a relatively simple inductive type family
$$mathsf{T} : mathbf{2}to mathbf{2}to mathcal{U}$$
defined by two constructors
- $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$
- $A_2 : Pi_{b : mathbf{2}} mathsf{T}(1_{mathbf{2}},b)$
where I'm using the notation from the HoTT Book, i.e. $mathbf{2}$ is a boolean, $mathcal{U}$ is some universe, etc.
Now,
- is there a function $f : Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b)to b = 0_{mathbf{2}}$?
- How is it defined?
- How is this definition justified (e.g. how would it be defined using the induction principle of $mathsf{T}$, or such)?
Ideas
From a meta perspective, one might argue: any term $t$ with type $mathsf{T}(0_{mathbf{2}},b)$ must be $A_1$, i.e. $t equiv A_1$. But then, $b equiv 0_{mathbf{2}}$, since $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$.
So, how defining this more formally. My first thought was, use induction over $mathsf{T}$ (resp. pattern matching), but this won't work, since its not defined for every $t : mathsf{T}$. Clearly
$$f(b, A_1) :equiv textsf{refl}_{0_{mathbf{2}}}$$
But what about $f(b, A_2)$?
Is there a way to use this idea within the theory?
Disclaimer
While this question might have an answer and explanation in a broader context then homotopy type theory, in the end I probably need some answer especially in HoTT, mainly because I'm not fluent in (intensional) type theory nor do I have sufficient skill to translate general ideas around pattern matching, type theory, etc. into HoTT (yet). But I'm thankful for any advice/hint. : )
type-theory homotopy-type-theory
$endgroup$
At the moment I'm about to get my head around homotopy type theory as a new perspective into mathematics. Insofar, I'm trying to mess around with it, prove some simple things and see where it gets; but I'm stuck, again.
The questions
My problem can be boiled down to a simple example. Consider a relatively simple inductive type family
$$mathsf{T} : mathbf{2}to mathbf{2}to mathcal{U}$$
defined by two constructors
- $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$
- $A_2 : Pi_{b : mathbf{2}} mathsf{T}(1_{mathbf{2}},b)$
where I'm using the notation from the HoTT Book, i.e. $mathbf{2}$ is a boolean, $mathcal{U}$ is some universe, etc.
Now,
- is there a function $f : Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b)to b = 0_{mathbf{2}}$?
- How is it defined?
- How is this definition justified (e.g. how would it be defined using the induction principle of $mathsf{T}$, or such)?
Ideas
From a meta perspective, one might argue: any term $t$ with type $mathsf{T}(0_{mathbf{2}},b)$ must be $A_1$, i.e. $t equiv A_1$. But then, $b equiv 0_{mathbf{2}}$, since $A_1 : mathsf{T}(0_{mathbf{2}},0_{mathbf{2}})$.
So, how defining this more formally. My first thought was, use induction over $mathsf{T}$ (resp. pattern matching), but this won't work, since its not defined for every $t : mathsf{T}$. Clearly
$$f(b, A_1) :equiv textsf{refl}_{0_{mathbf{2}}}$$
But what about $f(b, A_2)$?
Is there a way to use this idea within the theory?
Disclaimer
While this question might have an answer and explanation in a broader context then homotopy type theory, in the end I probably need some answer especially in HoTT, mainly because I'm not fluent in (intensional) type theory nor do I have sufficient skill to translate general ideas around pattern matching, type theory, etc. into HoTT (yet). But I'm thankful for any advice/hint. : )
type-theory homotopy-type-theory
type-theory homotopy-type-theory
edited Dec 13 '18 at 18:23
aphorisme
asked Dec 13 '18 at 14:30
aphorismeaphorisme
57128
57128
$begingroup$
yes! A typo. Thanks. : ). Edited.
$endgroup$
– aphorisme
Dec 13 '18 at 18:22
add a comment |
$begingroup$
yes! A typo. Thanks. : ). Edited.
$endgroup$
– aphorisme
Dec 13 '18 at 18:22
$begingroup$
yes! A typo. Thanks. : ). Edited.
$endgroup$
– aphorisme
Dec 13 '18 at 18:22
$begingroup$
yes! A typo. Thanks. : ). Edited.
$endgroup$
– aphorisme
Dec 13 '18 at 18:22
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
This seemingly simple question is actually fairly deep, and leads quite directly to the "encode-decode method" used in HoTT to give synthetic proofs of classical theorems of algebraic topology. The key is to generalize the type of $f$. As you note, "$f(b,A_2)$" doesn't even make sense because $A_2$ doesn't have the correct type to be the second argument of $f$; but we need something analogous to "$f(b,A_2)$" in order to define $f$ by induction on $mathsf{T}$.
Thus, instead of $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$, we will define $g:Pi_{a:mathbf{2}} Pi_{b:mathbf{2}} mathsf{T}(a,b) to P(a,b)$, where $P:mathbf{2}to mathbf{2}to mathcal{U}$ is some type family such that $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$. Since the type of $g$ is more general, we will be able to use the induction principle for it; then we can define $f(b,t) = g(0_{mathbf{2}},b,t)$.
How do we obtain $P$? By a recursion principle. In this case, that means case analysis on the first argument $a:mathbf{2}$ of $P$. Our desired equality $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$ is the first case, and since we don't care about the other case we take it to be trivial to inhabit:
$$begin{align*}
P(0_{mathbf{2}},b) &:equiv (b=0_{mathbf{2}})\
P(1_{mathbf{2}},b) &:equiv mathbf{1}
end{align*}$$
Now we can define $g$ by the induction principle of $mathsf{T}$, with two cases corresponding to the two constructors of $mathsf{T}$:
$$begin{align*}
g(0_{mathbf{2}},0_{mathbf{2}},A_1) &:equiv mathsf{refl}_{0_{mathbf{2}}}\
g(1_{mathbf{2}},b,A_2) &:equiv star
end{align*}$$
Note that $g(a,b,t) : P(a,b)$ in both cases. Now, as noted above, we can define your $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$ by $f(b,t) = g(0_{mathbf{2}},b,t)$.
This sort of trick, of defining a desired function by generalizing the domain and finding the codomain as a particular value of a recursively defined type family, is a fundamental way of characterizing inductively defined type families over inductive types, including particularly the identity type (in which case in HoTT it often goes by the name of the "encode-decode method"). It's introduced in sections 2.12 and 2.13 of the HoTT book for characterizing the identity types of coproducts and the natural numbers (in fact you need it even to prove that $0_{mathbf{2}}neq 1_{mathbf{2}}$!), and then again in chapters 6 and 8 to study higher inductive types and compute homotopy groups of spheres.
$endgroup$
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
add a comment |
$begingroup$
Strictly speaking, the encode-decode method is not necessary here, and I don't think you'd avoid induction on $mathsf{T}$ by doing it. So I'll suggest that you define a function of type $Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$ directly by induction.
When you're defining functions out of inductively defined types or type families, like you do here, you can do that by defining the value at each of the constructors. This process is called pattern-matching.
In your example, we want to define a term of type $f:Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$. You do that by defining
$f(0,A_1) : 0=0$
There are no other constructors of $mathsf{T}$ that produce a term of a type of the form $mathsf{T}(0,b)$, so the definition of $f$ is complete after specifying that $f(0,A_1)$ is $mathsf{refl}$.
$endgroup$
1
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
1
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "69"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmath.stackexchange.com%2fquestions%2f3038068%2fproperties-over-partly-specified-inductive-families-hott%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
This seemingly simple question is actually fairly deep, and leads quite directly to the "encode-decode method" used in HoTT to give synthetic proofs of classical theorems of algebraic topology. The key is to generalize the type of $f$. As you note, "$f(b,A_2)$" doesn't even make sense because $A_2$ doesn't have the correct type to be the second argument of $f$; but we need something analogous to "$f(b,A_2)$" in order to define $f$ by induction on $mathsf{T}$.
Thus, instead of $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$, we will define $g:Pi_{a:mathbf{2}} Pi_{b:mathbf{2}} mathsf{T}(a,b) to P(a,b)$, where $P:mathbf{2}to mathbf{2}to mathcal{U}$ is some type family such that $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$. Since the type of $g$ is more general, we will be able to use the induction principle for it; then we can define $f(b,t) = g(0_{mathbf{2}},b,t)$.
How do we obtain $P$? By a recursion principle. In this case, that means case analysis on the first argument $a:mathbf{2}$ of $P$. Our desired equality $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$ is the first case, and since we don't care about the other case we take it to be trivial to inhabit:
$$begin{align*}
P(0_{mathbf{2}},b) &:equiv (b=0_{mathbf{2}})\
P(1_{mathbf{2}},b) &:equiv mathbf{1}
end{align*}$$
Now we can define $g$ by the induction principle of $mathsf{T}$, with two cases corresponding to the two constructors of $mathsf{T}$:
$$begin{align*}
g(0_{mathbf{2}},0_{mathbf{2}},A_1) &:equiv mathsf{refl}_{0_{mathbf{2}}}\
g(1_{mathbf{2}},b,A_2) &:equiv star
end{align*}$$
Note that $g(a,b,t) : P(a,b)$ in both cases. Now, as noted above, we can define your $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$ by $f(b,t) = g(0_{mathbf{2}},b,t)$.
This sort of trick, of defining a desired function by generalizing the domain and finding the codomain as a particular value of a recursively defined type family, is a fundamental way of characterizing inductively defined type families over inductive types, including particularly the identity type (in which case in HoTT it often goes by the name of the "encode-decode method"). It's introduced in sections 2.12 and 2.13 of the HoTT book for characterizing the identity types of coproducts and the natural numbers (in fact you need it even to prove that $0_{mathbf{2}}neq 1_{mathbf{2}}$!), and then again in chapters 6 and 8 to study higher inductive types and compute homotopy groups of spheres.
$endgroup$
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
add a comment |
$begingroup$
This seemingly simple question is actually fairly deep, and leads quite directly to the "encode-decode method" used in HoTT to give synthetic proofs of classical theorems of algebraic topology. The key is to generalize the type of $f$. As you note, "$f(b,A_2)$" doesn't even make sense because $A_2$ doesn't have the correct type to be the second argument of $f$; but we need something analogous to "$f(b,A_2)$" in order to define $f$ by induction on $mathsf{T}$.
Thus, instead of $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$, we will define $g:Pi_{a:mathbf{2}} Pi_{b:mathbf{2}} mathsf{T}(a,b) to P(a,b)$, where $P:mathbf{2}to mathbf{2}to mathcal{U}$ is some type family such that $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$. Since the type of $g$ is more general, we will be able to use the induction principle for it; then we can define $f(b,t) = g(0_{mathbf{2}},b,t)$.
How do we obtain $P$? By a recursion principle. In this case, that means case analysis on the first argument $a:mathbf{2}$ of $P$. Our desired equality $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$ is the first case, and since we don't care about the other case we take it to be trivial to inhabit:
$$begin{align*}
P(0_{mathbf{2}},b) &:equiv (b=0_{mathbf{2}})\
P(1_{mathbf{2}},b) &:equiv mathbf{1}
end{align*}$$
Now we can define $g$ by the induction principle of $mathsf{T}$, with two cases corresponding to the two constructors of $mathsf{T}$:
$$begin{align*}
g(0_{mathbf{2}},0_{mathbf{2}},A_1) &:equiv mathsf{refl}_{0_{mathbf{2}}}\
g(1_{mathbf{2}},b,A_2) &:equiv star
end{align*}$$
Note that $g(a,b,t) : P(a,b)$ in both cases. Now, as noted above, we can define your $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$ by $f(b,t) = g(0_{mathbf{2}},b,t)$.
This sort of trick, of defining a desired function by generalizing the domain and finding the codomain as a particular value of a recursively defined type family, is a fundamental way of characterizing inductively defined type families over inductive types, including particularly the identity type (in which case in HoTT it often goes by the name of the "encode-decode method"). It's introduced in sections 2.12 and 2.13 of the HoTT book for characterizing the identity types of coproducts and the natural numbers (in fact you need it even to prove that $0_{mathbf{2}}neq 1_{mathbf{2}}$!), and then again in chapters 6 and 8 to study higher inductive types and compute homotopy groups of spheres.
$endgroup$
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
add a comment |
$begingroup$
This seemingly simple question is actually fairly deep, and leads quite directly to the "encode-decode method" used in HoTT to give synthetic proofs of classical theorems of algebraic topology. The key is to generalize the type of $f$. As you note, "$f(b,A_2)$" doesn't even make sense because $A_2$ doesn't have the correct type to be the second argument of $f$; but we need something analogous to "$f(b,A_2)$" in order to define $f$ by induction on $mathsf{T}$.
Thus, instead of $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$, we will define $g:Pi_{a:mathbf{2}} Pi_{b:mathbf{2}} mathsf{T}(a,b) to P(a,b)$, where $P:mathbf{2}to mathbf{2}to mathcal{U}$ is some type family such that $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$. Since the type of $g$ is more general, we will be able to use the induction principle for it; then we can define $f(b,t) = g(0_{mathbf{2}},b,t)$.
How do we obtain $P$? By a recursion principle. In this case, that means case analysis on the first argument $a:mathbf{2}$ of $P$. Our desired equality $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$ is the first case, and since we don't care about the other case we take it to be trivial to inhabit:
$$begin{align*}
P(0_{mathbf{2}},b) &:equiv (b=0_{mathbf{2}})\
P(1_{mathbf{2}},b) &:equiv mathbf{1}
end{align*}$$
Now we can define $g$ by the induction principle of $mathsf{T}$, with two cases corresponding to the two constructors of $mathsf{T}$:
$$begin{align*}
g(0_{mathbf{2}},0_{mathbf{2}},A_1) &:equiv mathsf{refl}_{0_{mathbf{2}}}\
g(1_{mathbf{2}},b,A_2) &:equiv star
end{align*}$$
Note that $g(a,b,t) : P(a,b)$ in both cases. Now, as noted above, we can define your $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$ by $f(b,t) = g(0_{mathbf{2}},b,t)$.
This sort of trick, of defining a desired function by generalizing the domain and finding the codomain as a particular value of a recursively defined type family, is a fundamental way of characterizing inductively defined type families over inductive types, including particularly the identity type (in which case in HoTT it often goes by the name of the "encode-decode method"). It's introduced in sections 2.12 and 2.13 of the HoTT book for characterizing the identity types of coproducts and the natural numbers (in fact you need it even to prove that $0_{mathbf{2}}neq 1_{mathbf{2}}$!), and then again in chapters 6 and 8 to study higher inductive types and compute homotopy groups of spheres.
$endgroup$
This seemingly simple question is actually fairly deep, and leads quite directly to the "encode-decode method" used in HoTT to give synthetic proofs of classical theorems of algebraic topology. The key is to generalize the type of $f$. As you note, "$f(b,A_2)$" doesn't even make sense because $A_2$ doesn't have the correct type to be the second argument of $f$; but we need something analogous to "$f(b,A_2)$" in order to define $f$ by induction on $mathsf{T}$.
Thus, instead of $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$, we will define $g:Pi_{a:mathbf{2}} Pi_{b:mathbf{2}} mathsf{T}(a,b) to P(a,b)$, where $P:mathbf{2}to mathbf{2}to mathcal{U}$ is some type family such that $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$. Since the type of $g$ is more general, we will be able to use the induction principle for it; then we can define $f(b,t) = g(0_{mathbf{2}},b,t)$.
How do we obtain $P$? By a recursion principle. In this case, that means case analysis on the first argument $a:mathbf{2}$ of $P$. Our desired equality $P(0_{mathbf{2}},b) equiv (b=0_{mathbf{2}})$ is the first case, and since we don't care about the other case we take it to be trivial to inhabit:
$$begin{align*}
P(0_{mathbf{2}},b) &:equiv (b=0_{mathbf{2}})\
P(1_{mathbf{2}},b) &:equiv mathbf{1}
end{align*}$$
Now we can define $g$ by the induction principle of $mathsf{T}$, with two cases corresponding to the two constructors of $mathsf{T}$:
$$begin{align*}
g(0_{mathbf{2}},0_{mathbf{2}},A_1) &:equiv mathsf{refl}_{0_{mathbf{2}}}\
g(1_{mathbf{2}},b,A_2) &:equiv star
end{align*}$$
Note that $g(a,b,t) : P(a,b)$ in both cases. Now, as noted above, we can define your $f:Pi_{b:mathbf{2}} mathsf{T}(0_{mathbf{2}},b) to (b=0_{mathbf{2}})$ by $f(b,t) = g(0_{mathbf{2}},b,t)$.
This sort of trick, of defining a desired function by generalizing the domain and finding the codomain as a particular value of a recursively defined type family, is a fundamental way of characterizing inductively defined type families over inductive types, including particularly the identity type (in which case in HoTT it often goes by the name of the "encode-decode method"). It's introduced in sections 2.12 and 2.13 of the HoTT book for characterizing the identity types of coproducts and the natural numbers (in fact you need it even to prove that $0_{mathbf{2}}neq 1_{mathbf{2}}$!), and then again in chapters 6 and 8 to study higher inductive types and compute homotopy groups of spheres.
answered Dec 13 '18 at 19:01
Mike ShulmanMike Shulman
2,405720
2,405720
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
add a comment |
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
$begingroup$
Thank you very much! Your answer not only solved my issue but shed more light onto HoTT for me. I've read through the encode-decode method but I wasn't getting the motivation this clear -- it is good to see another example where it arises. I remember proving 0 != 1 using the coding of 2 and my problem here looked similar, but it seemed to be on a different level, inr != inl vs something deducted from limitations on type families. Ah, this helped. Kind of familiar in the context of induction to take a step back first and then prove...
$endgroup$
– aphorisme
Dec 13 '18 at 20:12
add a comment |
$begingroup$
Strictly speaking, the encode-decode method is not necessary here, and I don't think you'd avoid induction on $mathsf{T}$ by doing it. So I'll suggest that you define a function of type $Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$ directly by induction.
When you're defining functions out of inductively defined types or type families, like you do here, you can do that by defining the value at each of the constructors. This process is called pattern-matching.
In your example, we want to define a term of type $f:Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$. You do that by defining
$f(0,A_1) : 0=0$
There are no other constructors of $mathsf{T}$ that produce a term of a type of the form $mathsf{T}(0,b)$, so the definition of $f$ is complete after specifying that $f(0,A_1)$ is $mathsf{refl}$.
$endgroup$
1
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
1
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
|
show 1 more comment
$begingroup$
Strictly speaking, the encode-decode method is not necessary here, and I don't think you'd avoid induction on $mathsf{T}$ by doing it. So I'll suggest that you define a function of type $Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$ directly by induction.
When you're defining functions out of inductively defined types or type families, like you do here, you can do that by defining the value at each of the constructors. This process is called pattern-matching.
In your example, we want to define a term of type $f:Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$. You do that by defining
$f(0,A_1) : 0=0$
There are no other constructors of $mathsf{T}$ that produce a term of a type of the form $mathsf{T}(0,b)$, so the definition of $f$ is complete after specifying that $f(0,A_1)$ is $mathsf{refl}$.
$endgroup$
1
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
1
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
|
show 1 more comment
$begingroup$
Strictly speaking, the encode-decode method is not necessary here, and I don't think you'd avoid induction on $mathsf{T}$ by doing it. So I'll suggest that you define a function of type $Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$ directly by induction.
When you're defining functions out of inductively defined types or type families, like you do here, you can do that by defining the value at each of the constructors. This process is called pattern-matching.
In your example, we want to define a term of type $f:Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$. You do that by defining
$f(0,A_1) : 0=0$
There are no other constructors of $mathsf{T}$ that produce a term of a type of the form $mathsf{T}(0,b)$, so the definition of $f$ is complete after specifying that $f(0,A_1)$ is $mathsf{refl}$.
$endgroup$
Strictly speaking, the encode-decode method is not necessary here, and I don't think you'd avoid induction on $mathsf{T}$ by doing it. So I'll suggest that you define a function of type $Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$ directly by induction.
When you're defining functions out of inductively defined types or type families, like you do here, you can do that by defining the value at each of the constructors. This process is called pattern-matching.
In your example, we want to define a term of type $f:Pi_{(b:mathbf{2})}mathsf{T}(0,b)to (0=b)$. You do that by defining
$f(0,A_1) : 0=0$
There are no other constructors of $mathsf{T}$ that produce a term of a type of the form $mathsf{T}(0,b)$, so the definition of $f$ is complete after specifying that $f(0,A_1)$ is $mathsf{refl}$.
answered Dec 13 '18 at 20:08
EgbertEgbert
2,715921
2,715921
1
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
1
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
|
show 1 more comment
1
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
1
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
1
1
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
Haven't seen this answer until now. I actually have this solution in my notes, but it somehow doesn't click with me. I've accepted that with an introduced type (family) there is pattern matching/induction. But the type T(0,b) is not introduced, the family T is. Does it make sense to say "induction over T(0,b) for every b?" I'm quite picky here, I know, but it's just because it's so fundamental. It's always this question in my head: Is this already safe territory or am I assuming to much? Am I leaving the theory here? Especially with newly introduced types. What is allowed?
$endgroup$
– aphorisme
Dec 13 '18 at 20:58
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
I understand, it feels weird. To get a feel for what is allowed I'd suggest to try this with a proof assistant. In Agda the above argument is perfectly valid, I just checked it. One way to look at this, is maybe to note that when you specify T, you already use pattern-matching in the first argument of T. Simultaneously you give an inductive definition for T(0) and for T(1) in order to specify T. The family T(0) has only one constructor, so when you want to use induction on T(0) you use just that one constructor.
$endgroup$
– Egbert
Dec 13 '18 at 21:25
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
$begingroup$
Here's the answer to your question formalized in Agda, if you're interested: github.com/EgbertRijke/HoTT-Intro/blob/…
$endgroup$
– Egbert
Dec 13 '18 at 21:30
1
1
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Agda indeed allows that, but Book HoTT does not, and neither does Coq. In order to justify Agda's pattern-matching in terms of Book HoTT, you have to essentially do the encode-decode-type argument. For this reason I think Agda is a bit misleading for a beginner; it silently does all sorts of magic that actually has to be justified.
$endgroup$
– Mike Shulman
Dec 13 '18 at 22:24
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
$begingroup$
Hmm... I think you're right about this, Mike. Good point.
$endgroup$
– Egbert
Dec 13 '18 at 23:42
|
show 1 more comment
Thanks for contributing an answer to Mathematics Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmath.stackexchange.com%2fquestions%2f3038068%2fproperties-over-partly-specified-inductive-families-hott%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
yes! A typo. Thanks. : ). Edited.
$endgroup$
– aphorisme
Dec 13 '18 at 18:22