CODEWITHSUNDEEP
alloy
JOR
JOR

Reputation: 11

Alloy integer comparison semantics using "Forbid Overflow: Yes"

I have the following Alloy module and run command:

sig A { x : set A }
run {all a: A| #a.x<3 and #a.x>1} for exactly 2 A, 2 int

With "Forbid Overflow: No" the Alloy Analyzer 4.2 (Build date: 2012-09-25) does not find an instance. I believe the reason is that due to the overflow of the constant 3 the run predicate reads {all a: A| #a.x<-1 and #a.x>1}.

With "Forbid Overflow: Yes" the Alloy Analyzer finds an instance. 

---INSTANCE---
integers={-2, -1, 0, 1}
univ={-1, -2, 0, 1, A$0, A$1}
Int={-1, -2, 0, 1}
seq/Int={0}
String={}
none={}
this/A={A$0, A$1}
this/A<:x={A$0->A$0, A$0->A$1, A$1->A$0, A$1->A$1}

The Alloy Evaluator tells me that the predicate {all a: A| #a.x<3 and #a.x>1} used in the run command evaluates to false.

Could somebody please explain this behavior? Is there a difference in the sematics of integer comparisons in the Evaluator and the Analyzer?

Edit: I noticed that the behavior is different in the latest experimental version: Alloy 4.2_2014-03-07. It does not find an instance. This behavior is as expected.

Upvotes: 1

Views: 385

Answers (1)

Aleksandar Milicevic
Aleksandar Milicevic

Reputation: 3857

You already provided all the right answers in your question, so I can only quickly reiterate them

  • the expected behavior (no instance) is the "correct" behavior for that model;
  • version 4.2 has some known bugs regarding handling overflows, so that's the reason it finds an instance (those should be fixed in the latest version, hence correct behavior for this model);
  • under the "wraparound" semantics of integers (overflow detection turned off), there is still no instance, exactly for the reason you described (-3 being treated as -1);
  • the evaluator still has some issues (even in the latest version), so sometimes it will just use the wraparound semantics.

Upvotes: 2

Related Questions