Skip to content

Sort out FOOL paramodulation and Cases[Simp]#861

Open
mezpusz wants to merge 8 commits into
masterfrom
sort-out-foolp-cases
Open

Sort out FOOL paramodulation and Cases[Simp]#861
mezpusz wants to merge 8 commits into
masterfrom
sort-out-foolp-cases

Conversation

@mezpusz

@mezpusz mezpusz commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

There is an axiomatization and multiple inferences for handling Booleans, and they are kind of a mess. The goal of the present PR is uniformize the inferences, so that we can decide later which ones are still useful. My suggestion would be to eventually remove FOOLParamodulation, but we can also probably very easily implement it in Cases (basically taking the first result instead of all). In particular, the following changes are included:

  1. FOOL paramodulation was fixed for polymorphism, and now handles the higher-order case.
  2. Cases[Simp] handles now the first-order case too and the two inferences were merged as much as possible.
  3. Cases also inferred a lot of confluent but unnecessary intermediate clauses, this was ruled out.
  4. All inferences and the exhaustiveness axiom are turned on properly when needed. This had an unforseeable side effect, namely that with the exhaustiveness axiom we had hasBoolVar()==true in the Property object, which in turn toggles some additional inferences like primitive instantiation. Due to this, now with the missing (but unnecessary axiom) we seemingly lose some problems when Cases is turned on.

Detailed comparisons with master are to follow.

Cases FOL:
Discount master 10254 (0) vs branch 10260 (6)
Otter master 10354 (0) vs branch 10361 (7)

Cases HOL Discount:
master unsat: 2235 (13) sat: 1 (0) cputime: 8817.91 s instructions: 44196749 Mi memory: 118099.22 MB
branch unsat: 2231 (9) sat: 14 (13) cputime: 8820.62 s instructions: 43948531 Mi memory: 118149.41 MB

Cases HOL Otter:
master unsat: 2202 (20) sat: 1 (0) cputime: 9240.33 s instructions: 44841767 Mi memory: 141257.77 MB
branch unsat: 2200 (18) sat: 14 (13) cputime: 9239.07 s instructions: 44603251 Mi memory: 143950.84 MB

FOOLP HOL Discount:
master unsat: 2200 (37) sat: 14 (0) cputime: 8513.03 s instructions: 42983868 Mi memory: 118078.84 MB
branch unsat: 2183 (20) sat: 14 (0) cputime: 8735.23 s instructions: 43785102 Mi memory: 118122.17 MB

FOOLP HOL Otter:
master unsat: 2163 (28) sat: 14 (0) cputime: 8878.40 s instructions: 43640601 Mi memory: 144348.84 MB
branch unsat: 2151 (16) sat: 14 (0) cputime: 9175.95 s instructions: 44560333 Mi memory: 143307.99 MB

Comment thread Shell/Options.cpp
"Sets between three ways of dealing with the FOOL exhaustiveness axiom X0 = $true | X0 = $false:\n"
"(1) axiom: adds the axiom,\n"
"(2) generating: uses FOOL paramodulation as a generating inference rule,\n"
"(3) simplifying: a simplifying variant of the FOOL paramodulation inference rule.";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Would "off" be a reasonable value here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We are hiding all this behind the hasFOOL()==true condition, but of course, we could also consider disabling it completely. I honestly cannot tell which one makes more sense, what's you opinion?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That seems fine - what I was thinking about is the case where we do have FOOL, but we don't need to do any reasoning about terms being Boolean. This may not actually happen in practice, of course.

Comment thread Inferences/HOL/Cases.cpp
Comment thread Inferences/HOL/Cases.cpp
resLits->push( curr != lit
? curr
: EqHelper::replace(curr, t, troo));
resLits->push(EqHelper::replace(curr, TermList(t), replaceWithTroo ? troo : fols));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Would it be cleaner to pass the value of replaceWithTroo ? troo : fols directly to this function? Fairly minor though so nbd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants