Alloy constraint specification - logic

I wrote the following code block in Alloy:
one h: Human | h in s.start => {
s'.currentCall = h.from
}
I want to pick one 'human' from a set of humans (s.start) and set a variable (s'.currentCall) equal to h.from.
However I think this code is saying: There is only one human in s.start, where
s'.currentCall = h.from
is true.
Is my assumption correct? And how should I fix this?

You are absolutely correct, the meaning of the one quantifier is that there is exactly one element in the given domain (set) such that the quantifier body holds true.
Regarding your original goal of picking one element from a set and setting its field value to something: that sounds like an imperative update, and you can't really do that directly in Alloy; Alloy is fully declarative, so you can only assert logical statements about the sets and relations for a bounded universe of discourse.
If you just change one to some and also change the implication to conjunction, and then run the analysis (a simple run command to find a valid instance), the Alloy Analyzer will find a model in which the value s'.currentCall is equal to h.from for some (arbitrary) h from s.start:
pred p[s, s': S] {
some h: s.start | s'.currentCall = h.from
}
run p
I hope this is what you want to achieve.

Related

Verifying transformed string was actually changed (according to mapping table)

I have a mapping table, M:
And using this, I've performed a find & replace on string S which gives me the transformed string S':
S: {"z" "y" "g" "k"} -> S':{"z" "y" "h" "k"}
Now I wish to verify if my mapping transformation was actually applied to S'. The psudo-code I came up for doing so is as follows:
I. Call function searchCol(x, “h”); // returns true if “h” can be found in column x in M.
II. If searchCol(x, “h”); returns true {
// assume mapping transformation was not applied to S'
// S'' after transforming S': {“z”, “y”, “i”, “j”}
}
III.If searchCol(x, “h”); returns false {
// assume mapping transformation was already applied to S'
// do nothing
}
IV. // log and continue …
However, as you can see, for the case above the algorithm doesn't work. Does anyone know a better way of going about this?
Cheers for your help.
Note: As my codebase is in Java, if you do provide any code examples, I'd prefer it if you posted them in the same language :)
Can you instead keep track of transformations? There are some cases where it's impossible to determine if a transformation took place, imagine this mapping table:
x -> y
y -> x
Now given the String yxyxyxyx, was it already transformed? And how many times?
But even if your mapping table is free of circles, the only thing you can say is:
If the string contains a char that is on the left side and not on the right side,
then it was not yet transformed.
But if the above condition is not fulfilled, then you can not be sure of anything.

Description Logics and Ontologies: How to denote role domain-restrictions to blank nodes

Request for assistance denoting a domain-restriction to a blank node.
Figure 1: Modelling a many-to-many relationship with a blank node.
Business Rule: An Enrolment maps one Student to one Section, once.
My attempt:
∃hasStudent.⊤ ≡ ∃hasSection.⊤ ≡ ∃grade_code.⊤
i.e. "the set of individuals that have some value for the role 'hasStudent' is the same set of individuals that have some value for the role 'hasSection' ...e.t.c."
I assume equivalence here instead of inclusion since the inclusions would be in both directions.
Restricting further:
∃hasStudent.⊤ ≡ ∃hasSection.⊤ ≡ ∃grade_code.⊤ ≡ =1hasStudent.⊤ ≡ =1hasSection.⊤ ≡ =1grade_code.⊤
i.e. "the set of individuals that have values for the roles 'hasStudent', 'hasSection' and 'grade_code', have one and only one value for them."
Assistance or comments on correctly denoting the domain-restrictions of the object properties in figure 1 would be appreciated.
Thanks!!
OWL's Open World assumption is going to prevent you from finding "the set of individuals that have values for the roles 'hasStudent', 'hasSection' and 'grade_code', have one and only one value for them."
However, using SPARQL, you could create an ASK query that does just what you are asking for:
ASK {
SELECT (count(?student) AS ?stcount) (count(?section) AS ?secount) (count(?course) AS ?ccount)
WHERE {
?indiv :hasStudent ?student .
?indiv :hasSection ?section .
?indiv :grade_course ?course .
} GROUP BY ?student ?section ?course
HAVING (stcount = 1 && ?secount = 1 && ?ccount = 1)
}
A bit akward syntactically, since the aggregates need to be computed by a SELECT statement. The ASK will return true if the 'constraints' (see the HAVING clause) are all true and false otherwise.
For future reference the SHACL (RDF Shapes Constraint Language) work at W3C is intended to shore up these kinds of constraint violation problems that are not possible to answer with OWL.
If I understand your intent correctly, you want these restrictions to apply to any use of these properties rather than only for a specific class.
Under this assumption, you can achieve this by declaring the properties functional and setting their domain to C. In Functional syntax:
Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
Ontology(
Declaration(Class(<urn:test:C>))
Declaration(ObjectProperty(<urn:test:hasSection>))
Declaration(ObjectProperty(<urn:test:hasStudent>))
Declaration(DataProperty(<urn:test:grade_code>))
FunctionalObjectProperty(<urn:test:hasSection>)
ObjectPropertyDomain(<urn:test:hasSection> <urn:test:C>)
FunctionalObjectProperty(<urn:test:hasStudent>)
ObjectPropertyDomain(<urn:test:hasStudent> <urn:test:C>)
FunctionalDataProperty(<urn:test:grade_code>)
DataPropertyDomain(<urn:test:grade_code> <urn:test:C>)
SubClassOf(<urn:test:C> ObjectIntersectionOf(ObjectSomeValuesFrom(<urn:test:hasSection> owl:Thing) ObjectSomeValuesFrom(<urn:test:hasStudent> owl:Thing) DataSomeValuesFrom(<urn:test:grade_code> rdfs:Literal)))
)

How does "Assignment Branch Condition size for index is too high" work?

Rubocop is always report the error:
app/controllers/account_controller.rb:5:3: C: Assignment Branch Condition size for index is too high. [30.95/24]
if params[:role]
#users = #search.result.where(:role => params[:role])
elsif params[:q] && params[:q][:s].include?('count')
#users = #search.result.order(params[:q][:s])
else
#users = #search.result
end
How to fix it? Anyone has good idea?
The ABC size [1][2] is
computed by counting the number of assignments, branches and conditions for a section of code. The counting rules in the original C++ Report article were specifically for the C, C++ and Java languages.
The previous links details what counts for A, B, and C. ABC size is a scalar magnitude, reminiscent of a triangulated relationship:
|ABC| = sqrt((A*A)+(B*B)+(C*C))
Actually, a quick google on the error shows that the first indexed page is the Rubocop docs for the method that renders that message.
Your repo or analysis tool will define a threshold amount when the warning is triggered.
Calculating, if you like self-inflicting....
Your code calcs as
(1+1+1)^2 +
(1+1+1+1+1+1+1+1+1+1+1+1+1)^2 +
(1+1+1+1)^2
=> 194
That's a 'blind' calculation with values I've made up (1s). However, you can see that the error states numbers that probably now make sense as your ABC and the threshold:
[30.95/24]
So cop threshold is 24 and your ABC size is 30.95. This tells us that the rubocop engine assign different numbers for A, B, and C. As well, different kinds or Assignments (or B or C) could have different values, too. E.G. a 'normal' assignment x = y is perhaps scored lower than a chained assignment x = y = z = r.
tl;dr answer
At this point, you probably have a fairly clear idea of how to reduce your ABC size. If not:
a simple way it to take the conditional used for your elsif and place it in a helper method.
since you are assigning an # variable, and largely calling from one as well, your code uses no encapsulation of memory. Thus, you can move both if and elsif block actions into each their own load_search_users_by_role and load_search_users_by_order methods.

Is there an efficient algorithm to find which composition of boolean functions will match the output of a given boolean function?

Suppose I have the following boolean functions.
def Bottom():
return False
def implies(var1, var2):
if var1 == True and var2 == False: return False
return True
def land(var1, var2):
return var1 == True and var2 == True.
Is there an efficient algorithm which will take these three functions as input, and determine which (possibly multiple-application) functional composition of the first two functions will match the output of the third function for every Boolean (T,F) input to the third function?
I am using Python to write my example in, but I am not restricting solutions to Python or any programming language for that matter.
In fact I am not actually looking for code, but more of a description of an algorithm or an explanation for why one does not exist.
As a side note, my motivation for trying to discover this algorithm is because I was asked to show Functional Completeness of a particular set of logical connectives, and we do this by showing that one logical connective can be emulated by a certain set of others.
For logic, we have to use a little bit of guess and check, but I could not figure out a way to capture that in a program without a linear search over a large space of possibilities.
If you're only looking at boolean functions of two arguments, a simple brute-force technique will work. It could be extended to ternary logic, or ternary functions, or even both, but it is exponential so you can't push it too far. Here's the boolean version; I hope it's obvious how to extend it.
1) A binary boolean function is a relation {False, True} X {False, True} -> {False, True}. There are exactly 16 of these. Note that these include various functions which are independent of one or even both of the inputs. So let's make the set 𝓕 consisting exactly of these 16 functions, and now note that every boolean function has a corresponding higher-order function 𝓕 X 𝓕 -> 𝓕.
2) Now, start with the boolean functions Take first and Take second, and construct a closure using the HOFs corresponding to the "given functions". If the target function is in the closure, then it's achievable from some combination of the given functions. More generally, if every element in 𝓕 is in the closure, then the given function(s) are universal.
So, let's apply this to your example. I'm going to write elements of 𝓕 as a four-tuple corresponding to the inputs (F,F) (F,T) (T,F) (T,T) in that order, and I'm going to write the HOFs in bold. So Bottom is FFFF and Implies is TTFT. Bottom(a, b) is FFFF for any (a,b).
Take first is FFTT and Take second is FTFT, so that's our starting set. We can use Bottom to add FFFF, but obviously no further applications of Bottom are going to add anything.
So now we have nine possible pairs of functions we can apply to Implies. Here we go:
Implies(FFTT, FFTT) == TTTT (new)
Implies(FFTT, FTFT) == TTFT (new)
Implies(FFTT, FFFF) == TTFF (new)
Implies(FTFT, FFTT) == TFTT (new)
Implies(FTFT, FTFT) == TTTT
Implies(FTFT, FFFF) == TFTF (new)
Implies(FFFF, FFTT) == TTTT
Implies(FFFF, FTFT) == TTTT
Implies(FFFF, FFFF) == TTTT
Now we're up to eight of the sixteen functions, and we have a bunch more pairs to check. Since this is actually a complete set, it will get tedious, so I'll leave the next step to the reader (or perhaps their computer program).

OR between two function call

What is the meaning of a || between two function call
like
{
//some code
return Find(n.left,req)||Find(n.right,req);
}
http://www.careercup.com/question?id=7560692
can some one help me to understand . Many thanks in advance.
It means that it returns true if one of the two functions is true (or both of them).
Depends on the programming language, the method calls Find(n.left,req) -> if it's true - returns true. if it's false, it calls Find(n.right,req) and returns its Boolean value.
In Java (and C and C#) || means "lazy or". The single stroke | also means "or", but operates slightly differently.
To calculate a||b, the computer calculates the truth value (true or false) of a, and if a is true it returns the value true without bothering to calculate b, hence the word "lazy". Only if a is false, will it checks b to see if it is true (and so if a or b is true).
To calculate a|b, the computer works out the value of a and b first, then "ors" the answers together.
The "lazy or" || is more efficient, because it sometimes does not need to calculate b at all. The only reason you might want to use a|b is if b is actually a function (method) call, and because of some side-effect of the method you want to be sure it executes exactly once. I personally consider this poor programming technique, and on the very few occasions that I want b to always be explicitly calculated I do this explicitly and then use a lazy or.
Eg consider a function or method foo() which returns a boolean. Instead of
boolean x = a|foo(something);
I would write
boolean c=foo(something);
boolean x = a||c;
Which explicitly calls foo() exactly once, so you know what is going on.
Much better programming practice, IMHO. Indeed the best practice would be to eliminate the side effect in foo() entirely, but sometimes that's hard to do.
If you are using lazy or || think about the order you evaluate it in. If a is easy to calculate and usually true, a||b will be more efficient than b||a, as most of the time a simple calculation for a is all that is needed. Conversely if b is usually false and is difficult to calculate, b||a will not be much more efficient than a|b. If one of a or b is a constant and the other a method call, you should have the constant as the first term a||foo() rather than foo()||a as a method call will always be slower than using a simple local variable.
Hope this helps.
Peter Webb
return Find(n.left,req)||Find(n.right,req);
means execute first find {Find(n.left,req)} and return true if it returns true or
execute second find return the value true if it return true, otherwise false.

Resources