-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add minimizer functionality #156
base: main
Are you sure you want to change the base?
Conversation
@digama0 would you like to review this? |
That's really great. This finally made me install the Rust toolchain and try metamath-knife :-) I tried it on the recent large 3cubeslem3l theorem, minimization succeeded in 557899ms, which is fairly good for a theorem of that size. I don't know Rust so can't really comment on the code, but let me still make several remarks, maybe you'll find them useful. Compressed proof Minimize_with This has two advantages, first you can implement the As another example, suppose steps 10, 20, 30 all reference step 5 but Optimizations I'm a bit rusty on the metamath-exe internals, but if I recall correctly the biggest burden besides looping through all theorems and all steps, was computing the compressed proof to actually check if it got smaller. I can't quite understand if you're doing the same in your algo, but often you can avoid computing the compressed proof over and over again if, for example, you're able to remove some theorem from the theorem list, or if the referenced theorems list doesn't change but some steps were removed. Deep minimization One can precompute "allowed steps" for each step beforehand, and use those as potential hypotheses when trying to match a theorem to a step. Updating this structure shouldn't be too hard, but I guess that's a feature for minimizers of the future :-) |
Thank you @savask for your encouraging and detailed feedback!
I believe metamath_knife uses the same knapsack algorithm as metamath-exe. The algorithm first counts how many references there are to a proof step, pulls all the hypotheses first, but then the knapsack might reorder, as it will use labels sorted by length.
Yes you're right! I'll try swapping the order of the loops.
I'm actually not recomputing the compressed proof in the current algo. I find alternatives, and only estimate they could lead to a shorter proof... this is very random right now! Actually recomputing the compressed proof and actually comparing proof lengths is going to be my next step. I checked a few proofs and from what I saw there were very few alternative proofs to check (a handful per proof, if any), so my guess was that the performance impact would be minimal.
When attempting to minimize a step, I currently consider all steps previously proved, in the current proof order. |
Right, but there seems to be some difference still. Here's the proof of Proof
And now after applying Proof
You can see that the label ordering is different ( On the larger theorem |
Adds a minimal functioning minimizer, which:
To-do list:
Usage:
-M
command line switch.