Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix some minor Lean misformalisations #203

Merged
merged 11 commits into from
Aug 17, 2024

Conversation

ocfnash
Copy link
Contributor

@ocfnash ocfnash commented Aug 16, 2024

No description provided.

ocfnash added 10 commits August 16, 2024 11:36
There is one change which is required to fix the misformalisation:
 * Make sure `n / 2` use rational number division

There are two changes which are not required but are nice to have:
 * Use notation for `Nat.ceil`
 * Use `+ 1` instead of `- 1` to avoid natural number subtraction
The error in the original formalisation was that `P` was not
fully characterised (using an iff criterion).

In fact we provide a complete restatement since the original form was
unnecessarily complicated.
There were two errors in the original statement:
 * The set `Q` is not fully characterised (e.g., it could be empty)
 * The solution should intersect with the positive integers

A complete restatement seemed best.
The hypothesis `hasum` implies `False`. This issue could be fixed by
adding parentheses around the ` ∧ ` but I think a rewrite is better.
The limit should be a right-hand limit.

(In fact the singularity at `r = 0` is removable and we could also use
`𝓝[≠] 0` but this statement matches the question.)
The hypothesis `hM` implied `False` because it implied that every
function on [0, 1] had a maximum. We could fix this by specifying `M`
only for continuous functions and making no other changes but it is more
faithful to the question to restrict all functionals to C([0, 1], ℝ).
The hypotheses `hSABpart` and `hLS` jointly implied `False` for slightly
subtle reasons. To be precise, because `A ≠ B` is not demanded in
`hSABpart`, `Set.encard {AB | SABpart ∅ AB}.encard` is infinite and thus
cannot equal `LS ∅` since this is finite. We thus fix the statement by
adding `A ≠ B`.

We also include some stylistic changes, specifically:
 * We express the goal using `IsGreatest`
 * We rename `SABpart` to `IsLinearPartition` since this is the
   terminology of the question statement.
 * We drop some unnecessary type ascriptions.
The condition `hnmat` did not refer to `nmat` at all and so the
proposition `nmat` was free (and thus the statement could be disproved).
To fix this, `nmat` has been turned into a predicate which is
characterised by `hnmat`.

In addition some minor stylistic changes are made, notably the use of
`Pairwise`.
Copy link
Collaborator

@GeorgeTsoukalas GeorgeTsoukalas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for the PR! We really appreciate the contribution. Good catches with the subtle mistakes, we missed these in our verification. There also appeared to be some issues which probably arose from doing too many global syntactic edits at once. We did the most recent years first so hopefully there are less in the remaining problems. We also were not previously aware of IsGreatest and IsLeast, there are a fair amount of problems which still spell it out directly. We can get to those, but it might be several weeks as the semester is starting up soon so most of the team will be busy, and I'll be traveling shortly.

We'll also make some modifications in the corresponding Isabelle & Coq files to match any edits. Will leave this PR until we have made those changes. I also noted in putnam_2021_b2 that the held out solution is not mentioned in the theorem statement, but don't worry about this we can make this change on our end.

@ocfnash
Copy link
Contributor Author

ocfnash commented Aug 17, 2024

Thank you so much for the PR!

You're very welcome :)

We also were not previously aware of IsGreatest and IsLeast, there are a fair amount of problems which still spell it out directly. We can get to those, but it might be several weeks

Yes I was intending to highlight this. It's good to hear you might use these more widely, but there's no rush here. I think fixing misformalisations is much more urgent.

We'll also make some modifications in the corresponding Isabelle & Coq files to match any edits. Will leave this PR until we have made those changes.

Of course it's your project so you should certainly act as you see fit. However I'm not convinced that there is benefit to keeping a consistency of misformalisations across the three languages. This is just a batch of the first 10 problems I decided to fix and I should be able to fix many more. However if I have to wait for the Isabelle & Coq changes each time, I may not have further PRs.

@GeorgeTsoukalas
Copy link
Collaborator

However I'm not convinced that there is benefit to keeping a consistency of misformalisations across the three languages. This is just a batch of the first 10 problems I decided to fix and I should be able to fix many more. However if I have to wait for the Isabelle & Coq changes each time, I may not have further PRs.

Yeah, on second thought I agree with you. I'll merge and open an issue for the other languages. Let me know if you have any other suggestions!

@GeorgeTsoukalas GeorgeTsoukalas merged commit 991ae20 into trishullab:main Aug 17, 2024
1 check passed
@ocfnash ocfnash deleted the fix_misformalisations branch August 17, 2024 22:10
GeorgeTsoukalas added a commit that referenced this pull request Sep 21, 2024
Modify 73-78 Coq -> Mathcomp, Update Isabelle formalizations pursuant to #203, #206.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants