1

Sorry for the weird wording of the title, happy to work on it. This is a continuation of Why is the Axiom of Infinity necessary? but from the perspective of a complete novice to axiomatic set theory (that will probably use the wrong terminology).

I understand that in ZFC we can only have an infinite set because of the Axiom of Infinity. Without it I could define as many finite sets as I want, one bigger than the other, but not an infinite one. Still, my temptation is to say (as a thought experiment just to better understand the subject): can I just start in a more basic model without this axiom and define an infinite set using a formula similar to it? The answer I think is no, because an axiom is assumed to be true and anything you write after the axioms is a theorem you need to prove: you can't just create it out of nowhere. Is this the case?


Background: I'm an IT developer and I have a strong bias to look at everything as instructions. From that mindset I (erroneously) see the axioms as just another instruction or function call I can either invoke from the start in a prelude (for convenience) or something I can invoke later if needed. But I suspect that the same formula has deeply different implications when presented as an axiom or when part of a theorem trying to be proved. Specifically, the quantifier "$ \exists $": as an axiom this is a statement like "this is provided to you" but if I use it later would sound like "I think this set here exists provided that..".

lucas
  • 49

1 Answers1

2

Going off of the metaphor of everything as instructions, you can think of the axioms as library functions or built-in commands which you don't have to code yourself - you can just use them.

In this analogy, if an axiom (or any other statement) is a function, then the instructions implementing that function correspond to the proof of that statement. Axioms are statements we don't have to prove - they're functions we don't have to implement, because they're already present for us.

By contrast, the statement of the axiom of infinity, something like $$\exists X \left [\exists e (\forall z \, \neg (z \in e) \land e \in X) \land \forall y (y \in X \Rightarrow S(y) \in X)\right]$$ (as seen on Wikipedia), is not the implementation of the function: it's a comment that tells you the function signature and the way it's meant to be used. At the risk of pushing the metaphor too far, I'll interpret this axiom as saying:

  • The library provides an object called $X$ you may use;
  • It guarantees that the empty set (provided by another axiom library function) will always be an element of $X$;
  • It guarantees that whenever you have an element of $X$, applying the successor operation (which, by the way, is not a library function; we are told that we can implement $S(y)$ as $y \cup \{y\}$) will give us another element of $X$.

The library can just get away with putting all this in the documentation and we assume that it's true. On the other hand, if you're writing your own code that uses the library, and the library does not provide an object called $X$, you can't get away with saying X = new Set() and then writing down the properties you want $X$ to have in a comment. You have to actually write the code that constructs $X$ and makes sure that it satisfies the properties the comment describes.

(In other words, if you don't have the axiom, and you want to claim that the statement of the axiom is true, you have to prove it!)

Software libraries don't usually have the goal of providing the bare minimum you need, but axiomatic systems usually do. So, for example, the "software library of ZFC" might not just provide an emptySet object but also setWithOneElement and setWithTwoElements objects on the grounds that these are convenient to have. But, because we can implement these ourselves using the built-in commands (in other words, we can prove the existence of $1$-element and $2$-element sets in ZFC), there is no axiom for these. And the reason that there's an axiom of infinity is that it provides an object $X$ we cannot implement on our own using the other library functions.

Misha Lavrov
  • 159,700
  • Wow, you really went all the way, thanks. Leaning on that, my question, or rather my confusion, is based on the fact that I think (for the little I've seen so far) that the language used for the axioms and the theorems/proofs is the same: first-order logic. In your analogy you mention "comments"/"signature" identifying axioms and "implementation" identifying proofs: in IT these are clearly different; they are part of the same programming language but the syntax is markedly different. This might also be the case in FOL and I'm not realizing it yet. – lucas Apr 02 '24 at 16:56
  • Can you tell an axiom from a theorem by looking at the formula alone or is the fact that we give it the axiom status what makes it different (the status being: this already exists; you don't have to prove it)? – lucas Apr 02 '24 at 16:58
  • 1
    The statement of an axiom and the statement of a theorem cannot be distinguished. (Both library functions and functions you've implemented yourself have signatures that look the same.) So in some sense, you're right: it's the axiom status that makes it different. – Misha Lavrov Apr 02 '24 at 17:07
  • 2
    @lucas You might be interested in reading about the Curry-Howard correspondence which formalizes a bit more this metaphor for "axiom or proposition or theorem <-> function signature", "proof of proposition or theorem <-> function implementation". In fact, some proof assistants such as Coq, Agda, Lean (among others) use this extensively, and theoretically would allow you to write all proofs in a functional programming language. (And in reverse, the piece-by-piece proof building apparatus could also theoretically be used to construct a function body piece-by-piece, as in top-down programming.) – Daniel Schepler Apr 02 '24 at 17:08
  • 1
    I do want to mention that the syntax of theorem statements is different from the syntax of theorem proof in logic as well: in a proof, whether written in words or in some horrendous two-column fashion, you will have a sequence of statements with justifications for them. That statement+justification form is like a line of code saying "here is the operation we do, and here is the command (whether a library function or something implemented earlier) that we use". – Misha Lavrov Apr 02 '24 at 17:08