Re: [isabelle] rule is sometimes very slow

On Tue, 2 Dec 2014, Lars Noschinski wrote:

theory Scratch imports Main

abbreviation funswapid :: "'a ⇒ 'a ⇒ 'a ⇒ 'a" (infix "⇌⇩F" 90) where
 "x ⇌⇩F y ≡ Fun.swap x y id"

notepad begin
 fix uv uw vu vw wu wv f GM HM m n a
 assume "(vw ⇌⇩F vu ∘ f HM ^^ Suc m ∘ (uw ⇌⇩F uv ∘ vw ⇌⇩F vu)) a = (f
GM ^^ Suc n) a"
 then have "∃m. (vw ⇌⇩F vu ∘ f HM ^^ Suc m ∘ (uw ⇌⇩F uv ∘ vw ⇌⇩F vu)) a
= (f GM ^^ Suc n) a"
   by (rule exI)

The proof step "rule exI" takes several seconds to complete on my
machine (in Isabelle 2014). Similar proofs, like

  by (rule_tac exI)
  by -  (rule exI)
  by - (erule exI)
  by metis
  by blast

are instantaneous, as expected. I looked a bit into the implementation
of rule and it seems that most time is spend
in evaluating the result of

  Drule.multi_resolves facts @{thms exI}

Drule.multi_resolves is not relevant here, it is merely a wrapper for Thm.biresolution, i.e. the main rule composition principle of Isabelle/Pure.

The key difference of the structured form

  then have "∃m. P m" by (rule exI)

compared to the other ones above is the order of higher-order unification attempts. The 'then' means that some fact is unified with the premise of exI, which is the worst-case situation ?P ?x and thus can go amiss.

Only in the second stage, the closed conclusion ∃. P m contributes more specific unification constraints.

This problem has been there in Isar proofs since 1998/1999, and until today I don't know a better way. The HO-unification code of Isabelle is ultimately a mystery to me.


          1,070,319 people so far

This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.