
Solving a puzzle using the Isabelle proof assistant - yomritoyj
https://gist.github.com/jmoy/59c0ef25196716f1a0f4fd0efae6e099
======
yomritoyj
A machine checked proof of the following: "In a finite group of people, some
of whom are friends with some of the others there must be at least two people
who have the same number of friends."

~~~
chongli
Wow, what a weird coincidence. I just did this proof in graph theory
yesterday!

Suppose, for a contradiction, that there are _n_ people, each with a different
number of friends. Since a person can't be friends with themselves, the
numbers of friends is as follows:

0, 1, ..., n - 1

Then, the person with n - 1 friends has a friendship with everyone else in the
group, including the person with 0 friends. But this is a contradiction! Thus
there must be at least two people with the same number of friends.

~~~
antpls
Is that the same proof than the ~120 lines of code of the link?

If yes, proof assistants have to be improved on conciseness, imho

~~~
jlouis
The difference is that in a proof assistant, you cannot gloss over a detail.
So many of the lines establishes well-known facts which a mathematician has
internalized in their brain.

You could store that in a library (and many proof assistants do!) but then the
proof would probably be harder to follow for a first time reader.

The end goal of proof assistance are simpler proofs. Telling the system system
something like: "Proof. search by pigeonhole. crush. Qed." and all the details
would be established by the assistant itself. This allows for concise proofs,
especially in software where many proofs amounts to the invocation of some
induction scheme and solving by rote substitution and rewriting.

~~~
antpls
> The difference is that in a proof assistant, you cannot gloss over a detail.
> So many of the lines establishes well-known facts which a mathematician has
> internalized in their brain.

Maybe an intermediate DSL that would allow some "fallacies" or shortcuts would
also render the proof more readable to more people. And the weakness in the
reasoning could be easily spotable by special keywords.

> You could store that in a library (and many proof assistants do!) but then
> the proof would probably be harder to follow for a first time reader.

I'm not sure I agree with that. There is a middle ground to find between
rewriting a sort function everytime it is needed, and encapsulating everything
in a main() function. Creating an API/DSL/Vocabulary is not easy, but def
required to attract more developers.

