What are a couple possible instances in the world we had from last time?
Let's call this instance 1:
Atom_1 (Sorawee)
Atom_2
Atom_3 (Katya)
partnerof(Sorawee, Katya)
The submitted relation exists, but is empty, and the partnerof
relation has one entry. Does it satisfy our specification?
It doesn't! Because of our constraints, we need to have
partnerof(Katya, Sorawee) and submitted(Sorawee).
Let's add a couple things:
partnerof(Katya, Sorawee)
submitted(Sorawee)
But now we also have things that can go into the left-hand
side of ∀ x, y . submitted(x), partnerof(x, y) => submitted(y).
Because we have submitted(Sorawee) and partnerof(Sorawee, Katya), we need submitted(Katya)
This is starting to look more like Alloy than the things we've
done with boolean variables. We don't just have literals, and
we have to think about plugging things into predicates.
Now, we can start to answer the question from last time. How would you prove (maybe using something like resolution)
whether or not partnerof(Katya, Sorawee) is necessary?
We can assume not partnerof(Katya, Sorawee) (and add it to
our knowledge bank), and try to find a contradiction
between our constraints.
∀ x, y . partnerof(x, y) => partnerof(y, x) looks promising,
but we need something to put into it. How about partnerof(Sorawee, Katya)?
Let's combine them with resolution!
∀ x, y . partnerof(x, y) => partnerof(y, x)
{ x -> Sorawee, y -> Katya }
partnerof(Sorawee, Katya)
{ } // Nothing to substitute since only constants are used
--------------------------------------------
partnerof(Katya, Sorawee)
partnerof(Katya, Sorawee)
not partnerof(Katya, Sorawee)
--------------------------------------------
<contradiction>
Is it necessary that submitted(Katya)?
∀ x, y . submitted(x), partnerof(x, y) => submitted(y)
{ x -> Sorawee }
submitted(Sorawee)
------------------------------------------------------
∀ y . partnerof(Sorawee, y) => submitted(y)
∀ y . partnerof(Sorawee, y) => submitted(y)
{ y -> Katya }
partnerof(Sorawee, Katya)
------------------------------------------------------
submitted(Katya)
not submitted(Katya)
submitted(Katya)
------------------------------------------------------
<contradiction>
This is the essence of resolution in first-order logic. It's
exactly the same rule as what we saw with propositional logic,
but with some extra substitutions.
I'm glossing over a few things here. First-order logic can have
functions, which makes unification (figuring out what to substitute) more complicated. It also has a notion of equality,
which means that you have to bake what equality is into your
proof process.
Now that we can do this, there are a few ways we can solve these
kinds of problems. We can use a SAT solver and search for a counterexample, or we can find a proof with resolution. There are some subtleties in terms of relative power and strengths.
Some of you have started looking at final project ideas,
and running into higher-order quantification issues becomes
pretty common.
We're going to look at the 4-color theorem
The spec has basically the same undirected graph that we've
seen before, plus a color function that we're trying to find.
What will happen when we run this? Is it any higher-order quantification or a particular kind?
In this case, we're actually fine since Alloy skolemizes
the outer some colorFunc quantification (in the lecture code).
What if we want an instance with no valid coloring?
Negating our someValidColoring predicate turns the
some into an all, so now we have universal higher-order
quantification that can't be skolemized. Alloy is sad.
One option is to use some small exact bound and manually
rewrite your predicate to not use higher-order quantification.
Instead, you get a bunch of tedious first-order quantifications
(and it takes a while to run). If you have to deal with
something like sets of size 2 (pairs), that can be broken
down pretty easily and runs fairly quickly.
There's also an experimental version of Alloy
called Alloy* that does a really interesting iterative
refinement process to let you use higher-order quantification
in Alloy. Tim can point you to it if it becomes an issue.