-
Notifications
You must be signed in to change notification settings - Fork 66
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
Equations command modification #427
Equations command modification #427
Conversation
This reverts commit f0eabb9.
this looks good to me! |
Thank you very much @0art0! |
Thanks. I seem to be getting a strange build error in one of the generated files:
I can't immediately think of a reason why the changes introduced in my code would be causing this, but I'll continue to track down the issue. |
Ok @0art0. I will take a look at it later. Can you please resolve the merge conflicts? |
…into equations-command-modification
@pitmonticone Thank you so much. I've merged conflicts on both PRs. |
@0art0 : Is this PR ready for reviewing? I believe there is another PR that is dependent on this one as well. |
Yes, it's ready for reviewing. Thank you for helping out with fixing the build issues. The PR that depends on this one is #429. |
awaiting-review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the theorems converting between |
About the blueprint: Seems sensible. I'll change this PR to a draft, once the blueprint is ready we can get this merged. |
The action didn't timeout, but it still took 53 minutes to run the project. Is this expected? I'm inclined to merge both PRs (#427 and #429) because they look fine to me (even if the branch of #429 seem to have been created from the branch of #427 which isn't considered best practice), but I may be missing something. See discussion here https://leanprover.zulipchat.com/#narrow/stream/458659-Equational/topic/Do.20we.20need.20to.20build.20EquationalSearch.20files.3F/near/475682423 |
Let's wait for the blueprint to be updated |
I've added a section to the blueprint. |
Great, the cache mechanism worked properly and now it took just a few minutes. |
Thanks again @0art0! |
Exports the equations defined in `Equations.lean` and `AllEquations.lean` to a JSON file `data/magma_equations.json`. Depends on PR #427. --------- Co-authored-by: Pietro Monticone <38562595+pitmonticone@users.noreply.github.com>
The blueprint looks good to me too! (I presume @teorth would have written down the proof as 'trivial', but I think this level of detail doesn't hurt either) |
-- define law over `Fin n` | ||
elabCommand (← `(command| abbrev%$tk $finLawIdent : Law.MagmaLaw (Fin $freeMagmaSize) := $tl)) | ||
-- compatibility between the `finLaw` and the original equation | ||
let modelsIffLemma : Ident := mkIdent (.mkSimple s!"models_iff_{is.size}") | ||
elabCommand (← `(command| abbrev%$tk $finThmName : ∀ (G : Type _) [$inst : Magma G], G ⊧ $finLawIdent ↔ $eqIdent G := $modelsIffLemma $finLawIdent)) | ||
-- define the actual law over `Nat` | ||
elabCommand (← `(command| abbrev%$tk $lawIdent : Law.NatMagmaLaw := $tl)) | ||
-- compatibility between the law and the original equation | ||
elabCommand (← `(command| abbrev%$tk $thmName : ∀ (G : Type _) [$inst : Magma G], G ⊧ $lawIdent ↔ $eqIdent G := | ||
fun G _ ↦ Iff.trans (Law.satisfies_fin_satisfies_nat G $finLawIdent).symm ($finThmName G))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be better to do this in a more low-level way, rather than re-elaborating the law repeatedly. A hybrid approach would be to elaborate the law once and use Expr.toSyntax
to repeat it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion. The law happens to be elaborated slightly differently in the two situations -- in one case, the leaves are coerced to Fin n
, while in the second case, they are left as natural numbers, so storing the rest of elaboration as an expression may not directly work. (It's possible that I may be misunderstanding the comment.)
This PR modifies the
equation
command to automatically generate the corresponding law with variables overFin n
(in addition to the law with variables overNat
that is already being generated).This is used to show that the automatically generated laws are equivalent to the original equation in terms of satisfiability.
Additionally, this PR introduces an environment extension to store all the equational laws, which can be used to export laws as described in #142.
This PR also modifies a result transporting laws from
Fin n
toNat
to omit then != 0
hypothesis.