my code is this:
but when I execute this.it show me only one house and one mohre.
what should I do???
abstract one sig board{}
sig mohre {live:one state }
sig house extends board{ver:one Int,hor:one Int,mo: mohre }
enum state{alive,dead}
run{#house>10 and #mohre>8}
Your run does not specify a scope. The default scope is 3 atoms of each sig and 16 integers ([-8..7]).
The US of cardinality 10 is therefore out if scope. Basically those models are in lala land. If you lower the cardinality or increase the scope things should work.
run{#house>10 and #mohre>8} for 12 but 5 int
This command allows 12 atoms of all types and has 32 integers. Weirdly, the integers are specified by their bit width and 5 bits gives you 32 values.
Additionally, you put a constraint on the abstract sig one board. Remove the one since that prevents a solution with more than one house.
Related
When the ordering module is called with a set then all these functions are suddenly available on the set: first, last, next, prev, etc.
first returns the first atom.
last returns the last atom.
first.next returns the second atom.
But wait!
A set is, by definition, unordered. So how can you order a set?
Consider this set of colors:
abstract sig Color {}
one sig red extends Color {}
one sig yellow extends Color {}
one sig green extends Color {}
What does it mean to order that set of colors? Suppose we call the ordering module:
open util/ordering[Color]
What does first return? What does last return? What does first.next return?
Let’s have Alloy generate some instances:
run {}
Here are a few of the instances that are generated:
Instance #1
first returns: yellow
last returns: green
first.next returns: red
Instance #2
first returns: yellow
last returns: red
first.next returns: green
Instance #3
first returns: green
last returns: yellow
first.next returns: red
Notice that the ordering is different with each instance.
Now, let’s order a plain signature:
open util/ordering[Time]
sig Time {}
run {}
Only one instance is generated:
Instance #1
first returns: Time0
last returns: Time2
first.next returns: Time1
No more instances!
Lessons Learned
For a set created by enumerating its atoms, the ordering module orders the set in any way.
For a set created by a signature, the ordering module orders the set this way: Blah0, Blah1, Blah2, …, where “Blah” is the signature name.
I think the real lesson, however, is that the functions provided in the ordering module (first, last, next, etc.) make it appear that the set is ordered. But that is an illusion, it is just a view placed on top of the set. The set, in fact, has no ordering.
Do I have a correct understanding? Anything you would add to this?
The reason behind this difference holds in 2 words: Symmetry breaking.
In short, Alloy wants to avoid returning isomorphic instances (instances which are the same up to label renaming).
Think of it that way:
When you analyze a model consisting solely of the signature one Time{} the analyzer will return a single instance composed of atom Time$0. Labeling this atom Time$1, Time$2 or CoolAtom won't change the fact that the instance is composed of a single atom of type Time.
When analyzing the model declaring Color as being either red, yellow or green, the analyzer will return 3 instances, each consisting of a different color.
Why you ask? That's because those atoms are semantically different in the sense that they do not have the same type.
Note that in no ways you have created a set enumerating its atoms. You have defined the set of colors as being composed of several sets (red, green, yellow) which all happen to have an arity of one.
Your final understanding however is correct in the sense that using ordering doesn't alter the essence of the signature it is used on (defining a set of atoms), but rather provides functions used to define an ordering on elements typed by the said signature.
When you invoke the ordering module on some set S, you are simply adding an ordering to every instance, as if you explicitly included a homogeneous relation on the set S. As Loic notes, the key reason this is better than doing it explicitly is that you get symmetry breaking for free so better performance (and more convenient atom numbering). And of course, you don't need to axiomatize the ordering yourself.
I am a beginner in Alloy (The Modelling Language made by MIT). I am trying to model the leasing of a 2 bedroom apartment in Alloy. I am trying to add a fact such that the number of people in each leased apartment is not more than 4. However the instance generated on running, still shows only one 2 bedroom leased apartment having 10 occupants. What am I doing wrong? Also if possible could someone point to some good resources on learning Alloy apart from the tutorial on the MIT website? Thanks.
abstract sig apartment {}
sig twoLeased extends apartment {
occupants: some People
} { #occupants < 5 }
sig twoUnleased extends apartment {
}
sig People {}
run {} for 3 but 4 twoLeased, 10 People
By default the bit width used to represent integers is 4 so your instance contains integers ranging from -8 to 7. In an instance where the number of occupant is 10, an integer overflow thus occur (as 10>8), #occupants returning a negative number it is thus inferior to 5 hence satisfying your invariant.
To fix this issue, you can either forbid integer overflow in the Alloy Analyzer settings or increase the bit width used to represent integers (e.g. run {} for 6 Int).
Page 137 of the book Software Abstractions has these remarkable statements:
Integers are actually not very useful. If you think you need them,
think again; there is often a more abstract description that matches
the properties better. Just because integers appear in the problem
domain does not mean that they should be modeled as such. To figure
out whether integers are necessary, ask yourself what properties are
actually relied upon. For example, a communication protocol that
numbers its messages may rely only on the numbers being distinct; or
it may rely on them increasing; or perhaps even being totally ordered.
In none of these cases should integers be used.
Wow!
This is important. I want to deeply understand this.
To help me understand, I created two versions of the communication protocol.
The first version uses the Int datatype:
sig Message {
number: Int
}
The second version does not:
sig Message {
number: Number
}
sig Number {}
Is the second version more abstract? How is it more abstract? Is it more abstract because Number is not tied to a datatype? The first version is less abstract because it specifies a datatype (Int)?
Are datatypes the enemy of abstraction?
No, the second is no better. Suppose your messages aren't totally ordered, but are just partially ordered. Then the point is that rather than assigning an index to each message, you'd do better to make explicit the partial ordering on messages:
sig Message {follows: set Message, ...}
The following model is ok, Alloy finds instances.
abstract sig A{}
sig B extends A{}
sig C extends A{}
run {} for 1 but exactly 1 B, exactly 1 C
That makes me understand that the scope is not limited by the top-level signature A, but by its extensions, B and C.
However, I have a large model (no sense posting it here) that can only be satisfied with the scope of 14. With a scope of 13 the analyzer finds no instances.
When I analyze the instance found, using the evaluator to request 'univ', I get a solution that has about 5 atoms of each signature. Only the top-level abstract signatures have 14 atoms.
Am I missing something about scope? Does it affect something else besides the signatures (such as predicates)? Does it behave differently than what I assumed with the toy example?
Why won't my model simulate with a scope of 5?
edit:
here is my model if anyone is interested in taking a look. It is the result of model transformation, that's why legibility is an issue http://pastebin.com/17Z00wV4
edit2:
the predicate below works. If I run the predicate for 5 but don't specify the other ranges explicitly, it doesn't find instances.
run story3 for 5 but exactly 4 World, exactly 4 kPerson,
exactly 0 kSoftwareTool, exactly 1 kSourceCode,
exactly 1 kDocument, exactly 1 kDiagram, exactly 3 kChange,
exactly 1 kProject, exactly 2 coBranch, exactly 1 coRepository,
exactly 3 modeConfiguration, exactly 2 modeAtomicVersion,
exactly 2 relatorChangeRequest, exactly 0 relatorVerification,
exactly 1 relatorCheckIn, exactly 1 relatorCheckOut,
exactly 2 relatorConfigurationSelection,
exactly 1 relatorModification,
exactly 0 relatorRequestEvaluation, exactly 2 relatorMarkup
this one does not (it's the same predicate, but without the "exactly" keywords
run story3 for 5 but exactly 4 World, 4 kPerson, 1 kSourceCode,
1 kDocument, 1 kDiagram, 3 kChange, 1 kProject, 2 coBranch,
1 coRepository, 3 modeConfiguration, 2 modeAtomicVersion,
2 relatorChangeRequest, 1 relatorCheckIn, 1 relatorCheckOut,
2 relatorConfigurationSelection, 1 relatorModification,
2 relatorMarkup
I was told Alloy would find any possible instances within the defined scope so
run story3 for 5
should work too!
If each of the signature extending another one have a well defined scope, (it is the case for the small exemple you gave, then the the analyzer is "smart enough" to understand that the scope of the top level signature is at least equal to the some of the scopes of the signatures partitionning it.
In the case now you do not give any scopes to specific signatures, I assume that the analyzer won't be able to process the scope of the top signature as detailed bellow, the top level signature hence will have as scope the global one you gave.
Consider the following Alloy model:
open util/ordering[C]
abstract sig A {}
sig B extends A {}
sig C extends A {}
pred show {}
run show for 7
I understand why, when I run show for 7, all the instances of this model have 7 atoms of signature C. (Well, that's not quite true. I understand that the ordered signature will always have as many atoms as the scope allows, because util/ordering tells me so. But that's not quite the same as why.)
But why do no instances of this model have any atoms of signature B? Is this a side-effect of the special handling performed for util/ordering? (Intended? Unintended?) Is util/ordering intended to be applied only to top-level signatures?
Or is there something else going on that I am missing?
In the model from this this is abstracted, I'd really like to have a name like A for the union of B and C, and I'd really like C to be ordered, and I'd really like B to be unordered and non-empty. At the moment, I seem to able to achieve any two of those goals; is there a way to manage all three at the same time?
[Addendum: I notice that specifying run show for 3 but 3 B, 3 C does achieve my three goals. By contrast, run show for 2 but 3 B produces no instances at all. Perhaps I need to understand the semantics of scope specifications better.]
Short answer: the phenomena reported result from the rules for default and implicit scopes; those rules are discussed in section B.7.6 of the Language Reference.
Longer answer:
The eventual suspicion that I should look at the semantics of scope specifications more closely proved to be warranted. In the example shown here, the rules work out exactly as documented:
For run show for 7, signature A has a default scope of 7; so do B and C. The use of the util/ordering module forces the number of C atoms to 7; that also exhausts the quota for signature A, which leaves signature B with an implicit scope of 0.
For run show for 2 but 3 B, signature A has a default scope of 2, and B has an explicit scope of 3. This leaves signature C with an implicit signature of 2 minus 3, or negative 1. That appears to count as an inconsistency; scope bounds are expected to be natural numbers.
For run show for 2 but 3 B, 3 C, signature A gets an implicit bound of 6 (the sum of its subsignatures' bounds).
As a way of gaining a better understanding of the scope rules, it proved useful to this user to execute all of the following commands:
run show for 3
run show for 3 but 2 C
run show for 3 but 2 B
run show for 3 but 2 B, 2 C
run show for 3 but 2 A
run show for 3 but 2 A, 2 C
run show for 3 but 2 A, 2 B
run show for 3 but 2 A, 2 B, 2 C
I'll leave this question in place for other answers and in the hope that it may help some other users.
I understand that the ordered signature will always have as many atoms as the scope allows, because util/ordering tells me so. But that's not quite the same as why.
The reason is that when forcing an ordered sig to contain as many atoms as the scope allows it is possible for the translator to generate an efficient symmetry breaking predicate, which, in most examples with ordered sigs, results in much better solving time. So it is simply a trade-off, and the design decision was to enforce this extra constraint in order to gain performance.