Skip to content

Patmat: efficient reasoning about mutual exclusion#4431

Merged
adriaanm merged 1 commit intoscala:2.11.xfrom
adriaanm:rebase-4379
Apr 13, 2015
Merged

Patmat: efficient reasoning about mutual exclusion#4431
adriaanm merged 1 commit intoscala:2.11.xfrom
adriaanm:rebase-4379

Conversation

@adriaanm
Copy link
Contributor

@adriaanm adriaanm commented Apr 6, 2015

[Rebase of #4379]

Faster analysis of wide (but relatively flat) class hierarchies
by using a more efficient encoding of mutual exclusion.

Faster analysis of wide (but relatively flat) class hierarchies
by using a more efficient encoding of mutual exclusion.

The old CNF encoding for mutually exclusive symbols of a domain
added a quadratic number of clauses to the formula to satisfy.

E.g. if a domain has the symbols `a`, `b` and `c` then
the clauses
```
!a \/ !b  /\
!a \/ !c  /\
!b \/ !c
```
were added.

The first line prevents that `a` and `b` are both true at the same time, etc.

There's a simple, more efficient encoding that can be used instead: consider a
comparator circuit in hardware, that checks that out of `n` signals, at most 1
is true. Such a circuit can be built in the form of a sequential counter and
thus requires only 3n-4 additional clauses [1]. A comprehensible comparison of
different encodings can be found in [2].

[1]: http://www.carstensinz.de/papers/CP-2005.pdf
[2]: http://www.wv.inf.tu-dresden.de/Publications/2013/report-13-04.pdf
@scala-jenkins scala-jenkins added this to the 2.11.7 milestone Apr 6, 2015
@gbasler
Copy link
Contributor

gbasler commented Apr 7, 2015

/rebuild

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Doesn't going to flatMap change the semantics of the isDefined/nonEmpty check below?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the outcome is the same if you have List(None, ...) or just List(...) after the switch to flatMap.
However, for the other case you could before have a List(Some(Nil)), which will just reduce to Nil using flatMap.
You could enter the true branch below but the final outcome should be the same, shouldn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, thanks for explaining.

@adriaanm
Copy link
Contributor Author

adriaanm commented Apr 7, 2015

I'm sorry it took so long to digest this. In addition to my comments above, I think it could help my understanding to see how the change can be broken down into:

  • a commit that introduces the comparator circuit encoding of mutual exclusion
  • a commit that reworks the grouping logic of classes.

Can they be understood in isolation?

@gbasler
Copy link
Contributor

gbasler commented Apr 12, 2015

The grouping is a prerequisite to be able to use the mutual exclusion logic. The approach that I have taken should be conservative though: a quadratic number of implications is still generated but if the algorithm manages to isolate the groups, these implications are removed and replaced with the mutual exclusion logic.

@adriaanm
Copy link
Contributor Author

LGTM

adriaanm added a commit that referenced this pull request Apr 13, 2015
Patmat: efficient reasoning about mutual exclusion
@adriaanm adriaanm merged commit 8623c2b into scala:2.11.x Apr 13, 2015
@adriaanm
Copy link
Contributor Author

Hey, @gbasler, it looks like this caused a regression in unreachability checking: https://issues.scala-lang.org/browse/SI-9369

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants