mathlib icon indicating copy to clipboard operation
mathlib copied to clipboard

refactor(tactic/wlog): simplify and speed up `wlog`

Open jcommelin opened this issue 3 years ago • 25 comments

Benefits:

  • The tactic is faster
  • The tactic is easier to port to Lean 4

Downside:

  • The tactic doesn't do any heavy-lifting for the user

Zulip thread: https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/wlog/near/296996966


Open in Gitpod

jcommelin avatar Sep 13 '22 09:09 jcommelin

i'd be a lot more confortable if it could run some basic things, maybe some sort of push_neg (with a wlog! switch if you're worried about performance). or at least have dot notation for stuff like le_of_not_le

ericrbg avatar Sep 13 '22 15:09 ericrbg

I would prefer to leave those improvements to the Lean 4 version.

jcommelin avatar Sep 14 '22 10:09 jcommelin

I didn't look through the implementation yet, but I love the semantics! Finally a wlog that I understand and that works like a w.l.o.g. on paper!

What is the reason for a separate doneif though? Is there an advantage over wlog ..., swap, or even just reordering the proof? I also find it a bit confusing that wlog and doneif revert different assumptions by default.

gebner avatar Sep 14 '22 13:09 gebner

@gebner Providing doneif is just a little bonus for the user. Just like you have suffices and have.

I agree that it might make sense to have both of them have the same "reverting" behaviour. I'll fix that now.

jcommelin avatar Sep 15 '22 07:09 jcommelin

I'm also in the camp that doneif is superfluous here, for a relatively infrequently used tactic. Too many variants makes it harder for newbies. I'm guessing the total number of swaps this will require in the future history of mathlib may still add up to fewer bytes than the boilerplate to introduce doneif separately from wlog!

But it's obviously not critical either way.

kim-em avatar Sep 20 '22 06:09 kim-em

The current build failure suggests that wlog is broken. But I have no idea how to debug what's wrong.

jcommelin avatar Sep 20 '22 15:09 jcommelin

The problem seems to be with wlog ... generalizing generating a buggy proof. But I don't see what's wrong when I stare at the code.

jcommelin avatar Sep 21 '22 05:09 jcommelin

I just observed wlog generating a buggy proof that the kernel rejects: it's the proof of pow_eq_one_of_norm_eq_one here. This is with the wlog currently in mathlib, so this bug may be already present and unrelated to changes made in this PR. The error message says

type mismatch at application
...
term
  habne
has type
  a < b
but is expected to have type
  b < a

alreadydone avatar Oct 04 '22 06:10 alreadydone

Beware that the last commit would conflict with #16804 where I used a trick to replace the buggy wlog. (I suspect the trick is pretty widely applicable and actually may provide one way of implementing wlog, but I'm not sure if it's good practice.)

alreadydone avatar Oct 06 '22 02:10 alreadydone

I'm able to minimize the example above:

import tactic.wlog
example (a b : ℕ) (hn : a < b ∨ b < a) : 0 = 0 :=
by { wlog : b < a := hn using [a b], refl }

shows "goals accomplished" but produces the error

type mismatch at application
  (λ (a b : ℕ) (hn : b < a), eq.refl 0) a b hn
term
  hn
has type
  a < b
but is expected to have type
  b < a

Maybe this is intended to fail because b < a isn't the first in the disjunction; if you replace it with wlog : a < b ... then it works (and [a b] vs. [b a] doesn't matter). However it's really confusing that it shows "goals accomplished". Not sure if this remains relevant after simplification made in this PR.

alreadydone avatar Oct 06 '22 07:10 alreadydone

I don't think I can meaningfully push this PR further. I don't know how to debug the mysterious behaviour. So I'm tagging this please-adopt (cc @semorrison).

@urkud Thanks for pushing some fixes.

jcommelin avatar Oct 06 '22 19:10 jcommelin

@jcommelin Do you have concrete examples for the mysterious behavior? You said something about generalize on zulip. Everything seems to build here though.

gebner avatar Oct 06 '22 23:10 gebner

I'm perfectly happy if we merge as is and deal with any mysterious fallout later. :-)

kim-em avatar Oct 07 '22 01:10 kim-em

Here's an example that works around a problem: https://github.com/leanprover-community/mathlib/pull/16495/commits/39df28619ded2767bcc8c60c9e87a793b2739c80 If you revert those two lines, you can see how generalizing is misbehaving.

But I agree with Scott. We can probably just merge this. The port of wlog to Lean 4 might have the bug disappear altogether because of hygiene and whatnot.

jcommelin avatar Oct 07 '22 05:10 jcommelin

bors merge

kim-em avatar Oct 08 '22 05:10 kim-em

Build failed (retrying...):

bors[bot] avatar Oct 08 '22 09:10 bors[bot]

bors r- Can you merge master and fix the build? bors d+

sgouezel avatar Oct 08 '22 10:10 sgouezel

:v: jcommelin can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

bors[bot] avatar Oct 08 '22 10:10 bors[bot]

Canceled.

bors[bot] avatar Oct 08 '22 10:10 bors[bot]

I will not be able to do this before Tuesday. If someone else wants to do it before then, please go ahead!

jcommelin avatar Oct 08 '22 11:10 jcommelin

bors merge

urkud avatar Oct 11 '22 15:10 urkud

This PR was included in a batch that was canceled, it will be automatically retried

bors[bot] avatar Oct 11 '22 16:10 bors[bot]

Build failed (retrying...):

bors[bot] avatar Oct 11 '22 18:10 bors[bot]

One more use of wlog was merged in the meantime :(

bors failure

bors r-

alreadydone avatar Oct 11 '22 19:10 alreadydone

Canceled.

bors[bot] avatar Oct 11 '22 19:10 bors[bot]

bors r+

jcommelin avatar Feb 03 '23 13:02 jcommelin

Pull request successfully merged into master.

Build succeeded:

bors[bot] avatar Feb 03 '23 16:02 bors[bot]