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.
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 have some doubts about how correctly we can use {XOR} constraint in UML.
I understand how it works in two different ways. Which one is correct?
The xor constraint applies to the association. (either: an object of type A may be associated with 1 object of type C; or: an object of type A may be associated with zero or 1 object to type B; or: object A could be just by itself because we have [0..1] near B).
The xor constraint applies to the link (either: an object of type A must be associated with exactly one object of type C; or: an object of type A must be associated to exactly one object of type B).
After many years I have to fix this answer (though I got many upvotes for it).
The {XOR} means that class A must have either an association to B or to C but not to both or none. That means in one case you have A * - 0..1 B and in the other case it's A 0..1 - 1 C. Both are legal constructs per se. Only here it is that A will play two exclusive roles.
This is a purely academic construct, so what it means in practice is completely open. It would be more meaningful (and helpful) if such examples from tutorials/classes would have some real world connection.
Old (wrong) answer
This is simply wrong (or a puzzle). You need exactly one C to be associated with A. But then, due to the XOR you may not associate B. Which means: the B relation is always 0 and you could as well leave it away.
Maybe (!) someone has put the multiplicity on the wrong side. If you swap them, it would make sense. If you use real names rather than A, B, C you could guess from the context.
Option 2 requires a multiplicity of exactly one near B.
Option 1 is suitable in the following cases:
1 near A, 0..1 near B
0..1 near A, 0..1 near B
0..1 near A, 1 near B
xor is a Boolean operator that gives true as a result only if its two operands are one true and the other false.
The notation is used to specify that an instance of the base class must participate in exactly one of the associations grouped together by the {xor} constraint. Exactly one of the associations must always be active.
The util/ordering module contains a comment at the top of the file about the fact that the bound of the module parameter is constrained to have exactly the bound permitted by the scope for the said signature.
I have read a few times (here for instance) that it is an optimization that allows to generate a nice symmetry-breaking predicate, which I can grasp. (BTW, with respect to the said post, am I right to infer that the exactly keyword in the module parameter specification is here to enforce explictly this exact bound (while it was implicit in pre-4.x Alloy versions)?)
However, the comment also contains a part that does not seem to refer to optimization but really to an issue that has a semantic flavour:
* Technical comment:
* An important constraint: elem must contain all atoms permitted by the scope.
* This is to let the analyzer optimize the analysis by setting all fields of each
* instantiation of Ord to predefined values: e.g. by setting 'last' to the highest
* atom of elem and by setting 'next' to {<T0,T1>,<T1,T2>,...<Tn-1,Tn>}, where n is
* the scope of elem. Without this constraint, it might not be true that Ord.last is
* a subset of elem, and that the domain and range of Ord.next lie inside elem.
So, I do not understand this, in particular the last sentence about Ord.last and Ord.next... Suppose I model a totally-ordered signature S in the classical way (i.e. specifying a total, reflexive, antisymmetric, transitive relation in S -> S, all this being possible using plain first-order logic) and that I take care to specify an exact bound for S: will it be equivalent to stating open util/ordering[S] (ignoring efficiency and confusing atom-naming issues)?
Sorry for the slow response to this. This isn't very clear, is it? All it means is that because of the symmetry breaking, the values of last, prev and next are hardwired. If that were done, and independently elem were to be bound to a set that is smaller than the set of all possible atoms for elem, then you'd have strange violations of the declarations such as Ord.last not being in the set elem. So there's nothing to understand beyond: (1) that the exactly keyword forces elem to contain all the atoms in the given scope, and (2) the ordering relation is hardwired so that the atoms appear in the "natural" order.
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.
I'm having trouble using Haskell's type system elegantly. I'm sure my problem is a common one, but I don't know how to describe it except in terms specific to my program.
The concepts I'm trying to represent are:
datapoints, each of which takes one of several forms, e.g. (id, number of cases, number of controls), (id, number of cases, population)
sets of datapoints and aggregate information: (set of id's, total cases, total controls), with functions for adding / removing points (so for each variety of point, there's a corresponding variety of set)
I could have a class of point types and define each variety of point as its own type. Alternatively, I could have one point type and a different data constructor for each variety. Similarly for the sets of points.
I have at least one concern with each approach:
With type classes: Avoiding function name collision will be annoying. For example, both types of points could use a function to extract "number of cases", but the type class can't require this function because some other point type might not have cases.
Without type classes: I'd rather not export the data constructors from, say, the Point module (providing other, safer functions to create a new value). Without the data constructors, I won't be able to determine of which variety a given Point value is.
What design might help minimize these (and other) problems?
To expand a bit on sclv's answer, there is an extended family of closely-related concepts that amount to providing some means of deconstructing a value: Catamorphisms, which are generalized folds; Church-encoding, which represents data by its operations, and is often equivalent to partially applying a catamorphism to the value it deconstructs; CPS transforms, where a Church encoding resembles a reified pattern match that takes separate continuations for each case; representing data as a collection of operations that use it, usually known as object-oriented programming; and so on.
In your case, what you seem to want is an an abstract type, i.e. one that doesn't export its internal representation, but not a completely sealed one, i.e. that leaves the representation open to functions in the module that defines it. This is the same pattern followed by things like Data.Map.Map. You probably don't want to go the type class route, since it sounds like you need to work with a variety of data points, rather than on an arbitrary choice of a single type of data point.
Most likely, some combination of "smart constructors" to create values, and a variety of deconstruction functions (as described above) exported from the module is the best starting point. Going from there, I expect most of the remaining details should have an obvious approach to take next.
With the latter solution (no type classes), you can export a catamorphism on the type rather than the constructors..
data MyData = PointData Double Double | ControlData Double Double Double | SomeOtherData String Double
foldMyData pf cf sf d = case d of
(PointData x y) -> pf x y
(ControlData x y z) -> cf x y z
(SomeOtherData s x) -> sf s x
That way you have a way to pull your data apart into whatever you want (including just ignoring the values and passing functions that return what type of constructor you used) without providing a general way to construct your data.
I find the type-classes-based approach better as long as you are not going to mix different data points in a single data structure.
The name collision problem you mentioned can be solved by creating a separate type class for each distinct field, like this:
class WithCases p where
cases :: p -> NumberOfCases