I am sorry for the title, I tried hard to make it as understandable as possible but I know I failed.
Here is the simple model:
sig ETHBusStation {
next: set ETHBusStation
}
one sig Polyterrasse, HaldenRight, HaldenLeft, Hoengg extends ETHBusStation {}
sig ETHBus {
station: lone ETHBusStation
}
fact {
//no (Hoengg - HaldenRight)
all s: ETHBusStation | ETHBusStation in s.^next and some s.next
all b1, b2: ETHBus | b1.station != b2.station}
run {} for 2 but 1 ETHBusStation
when I run the analyzer it finds an instance with one of each Polyterrasse, HaldenRight, HaldenLeft, Hoengg
but since these are all disjoint subsets of ETHBusStation, how can this be with the but 1 parameter?
I am expecting it to have a single station that links to itself via next.
I am grateful for any hints and tips.
If we use in instead of extends it behaves as expected, but then they also don't have to be disjoint which makes sense.
I believe the scope declaration is being overridden by the one sig decl. If it didn't do this, the expected behavior would be to find no instances, since the sig decl claims that exactly four bus stations exist, and the scope says that there is at most one bus station.
Related
I have encountered the following issue in Alloy. Consider the toy code which tries to capture even labeled entities (V1 is for State and V2 is for ProductStateSet):
enum State {s1, s2, s3, s4, s5, s6}
enum DummySet {b,c}
let ProductStateSet = DummySet->State
pred evenV1 (state: State){
(state = s2) or (state=s4) or (state=s6)
}
pred evensetV1 (stateset: State) {
all state: stateset | evenV1[state]
}
assert a2V1 {
evensetV1[(s2 + s4)]
}
pred evenV2 (state: ProductStateSet){
(state = b->s2) or (state=b->s4) or (state=b->s6)
}
assert a1V2 {
evenV2[b->s2]
}
pred evensetV2 (stateset: ProductStateSet) {
all state: stateset | evenV2[state]
}
assert a2V2 {
evensetV2[ (b->s2) + (b->s4) ]
}
The assertion a2V1 is true, but a2V2 is false, when I would have expected them to be the same. Why is this so, and what is the proper way to use quantifiers when dealing with set products?
If I change "evenset" to have "some" rather than "all", no issues with evensetV1, but for evensetV2 I get:
pred evensetV2 (stateset: ProductStateSet) {
some state: stateset | evenV2[state]
}
assert a2V2 {
evensetV2[ (b->s2) + (b->s4) ]
}
Executing "Check a2V2"
Solver=sat4j Bitwidth=4 MaxSeq=4 SkolemDepth=1 Symmetry=20
Generating CNF...
.
Analysis cannot be performed since it requires higher-order
quantification that could not be skolemized.
Another question for this example regarding set comprehension: I can write an assertion like:
assert a3V1{
#{state: State | evenV1[state]} > 2
}
Is there a way to print out the set elements, that is, can I print out the below set?
{state: State | evenV1[state]}
Thanks!
Regarding your first question:
EDITED (first answer was wrong)
Running the assertion gives 2 counter examples.
One is expected, in the sense that none -> none is not considered in the evenV2 predicate. But the other (see below) doesn't make sense for me.
My only logical explanation is that the quantification variable "state" of evenSetV2 is badly interpreted when given in parameter of evenV2 even though it seems somehow farfetched ...
I think whenever possible, one should avoid quantification and prefer more straightforward set operations. Implementing the predicate and assertion as follows solves the problem (you don't even need to differentiate between the singleton and the set approach anymore):
pred evenV2 ( state: ProductStateSet){
DummySet.state in (s2+s4+s6)
}
assert a2V2 {
evenV2[ (b->s4)+ (b->s6)]
}
END EDIT
For the second question, the Alloy evaluator is your friend.
I cribbed from the hotel door lock example and came up with this MWE for vehicle doors.
enum LockState {Locked, Unlocked}
sig Door {
var state: LockState
}
sig Vehicle {
doors : disj set Door
}
//actions
pred unlock[d: Door]{
d.state' = Unlocked
}
pred lock[d: Door]{
d.state' = Locked
}
//traces
pred init{
all s: Door.state | s = Locked
}
pred trace{
init
always {
some d: Door |
unlock[d] or
lock[d]
}
}
//demonstrate
run {} for 4 but exactly 2 Vehicle, 4 Time
Which to my suprise allows the instance shown below, in which some doors are locked and some not. How do I establish the condition that all doors are locked at the earliest time?
Initial states are defined without any temporal keywords, as you did in init.
The problem is that you defined your trace as a predicate. If you define it as a fact it will always be applied. However, if you make it a predicate (my preference since it feels less global) you must include it from the run command. Pick one:
run trace for 4 but exactly 2 Vehicle, 4 Time
run { trace } for 4 but exactly 2 Vehicle, 4 Time
However, your model will then still not run well.
You provide an always but no goal. So after one state Alloy is happy. You should provide an eventually so Alloy will attempt to continue until it is satisfied.
You allow vehicles without doors, I would use some Door instead of set Door
Your init can be done cleaner like Door.state = Locked
In your trace, each step sets one Door. However, you're not specifying what the state of the other doors should be. If you do not specify a value for the next state, they can become anything. These should be explicitly set to have their old value.
So I came up with the following model:
enum LockState { Locked, Unlocked }
sig Door { var state: LockState }
sig Vehicle { doors : disj some Door }
pred Door.unlock { this.state' = Unlocked }
pred Door.lock { this.state' = Locked }
pred trace {
Door.state = Locked
always (
some d: Vehicle.doors {
(d.unlock or d.lock)
unchanged[state,d]
}
)
eventually Door.state = Unlocked
}
run trace for 4 but exactly 2 Vehicle
pred unchanged[ r : univ->univ, x : set univ ] {
(r - x->univ)' = (r - x->univ)
}
updated Added an unchanged predicate.
I have a model with this sig:
sig Thing {}
sig World {
quantities: Thing ->one Int,
}
I want to define a constraint on the quantities relationship such that the quantity of each Thing must be a positive int.
I am total beginner with Alloy (and I have no theory background to draw on, am just a Python programmer). I followed through the tutorial but I did not see a recipe for what I want to do.
I know how to:
fact {
all w: World | w.quantities <something>
}
...but I am not clear how to address members of the right-hand-side of the relationship when writing a fact.
I have defined it as a relationship (rather than having a quantity property on the Thing sig) because I understood from the tutorial that this was necessary in a dynamic model where I want to update the quantity of Things via predicates.
I tried defining a:
sig PositiveInt extends Int {}
...but this is not allowed.
updated
This kind of subtyping works (imho) best with set enumeration:
let PositiveInt = { i : Int | i > 0 }
sig Thing {}
sig World { quantities : Thing -> one PositiveInt }
┌──────────┬──────────┐
│this/World│quantities│
├──────────┼──────┬───┤
│World⁰ │Thing⁰│7 │
│ ├──────┼───┤
│ │Thing¹│6 │
│ ├──────┼───┤
│ │Thing²│4 │
└──────────┴──────┴───┘
I am having errors in Alloy (4.2) specifications of the following kind:
You must specify a scope for sig "this/Univ"
The issue is easy to reproduce with a toy example:
open util/ordering[State]
open util/integer
sig State { value : Int }
fact {
first.value = 0
all s:State, s': s.next | s'.value = plus[s.value, 1]
}
run { } for 5 State, 3 Int
All of the above is fine. Now, when I define State in an external file and import it with an open statement, I get the "Univ scope" error:
open util/ordering[State]
open util/integer
open State
fact {
first.value = 0
all s:State, s': s.next | s'.value = plus[s.value, 1]
}
run { } for 5 State, 3 Int
I tried several variations of the above without success.
Why does this happen and how can it be solved?
In my project, it would be useful for me to define the target sig of the ordering module in a different file.
Thanks,
Eduardo
This is an Alloy "design bug".
It was decided that a Univ signature would appear when no signatures are defined in the module in order to check some property over built-in relations (e.g., unit, iden, none).
You have many ways of going around this problem, here is a selection :
You can add ",0 Univ" at the end of your run command
You can add a signature in your Alloy module
You can specify a global scope of zero (run { } for 0 but 5 State, 3 Int )
See this question for additional informations
This is an example of Alloy that I found I want to make it with 3 predicates, 3 facts, 3 objects and 3 assertions, can someone please help me? I am very new in Alloy and need some immediate help.
abstract sig Color {}
one sig Red,Yellow,Green extends Color {}
sig Light {
color: Color
}
sig Junction {
lights : set Light
}
fun count[j:Junction, c:Color] : Int {
#{x:Light | x in j.lights and x.color=c}
}
// This is just for realism, make sure each light belongs to exactly one junction
fact {
Light = Junction.lights
no x,y:Junction | x!=y and some x.lights & y.lights
Light = Junction.lights
no y,x:Junction | y!=x and some y.lights & x.lights
}
pred mostly[j:Junction, c:Color] {
no cc:Color | cc!=c and count[j,cc]>=count[j,c]
}
run{
some j:Junction | mostly[j,Red]
} for 10 Light, 2 Junction, 10 int`
In Alloy, you can only provide a scope for the number of objects (atoms) of each sig in your model. Predicates, functions, and assertions you write explicitly in your model, they are not "expanded" by the Alloy Analyzer in any way, and they cannot be quantified over, so providing a separate scope for them would not make sense.