I have extended the original pizza.owl and have now the following SWRL rule in my Protege (Rules editor: Windows/Views/Ontology views/Rules):
Pizza(?p),
hasIngredient(?p, ?ing1), hasIngredient(?p, ?ing2),
hasCountryOfOrigin(?ing1, ?c1), hasCountryOfOrigin(?ing2, ?c1),
differentFrom(?ing1, ?ing2) -> NationalPizza(?p)
The rule should assert NationalPizza for all pizza individuals where at least two ingredients (e.g. PizzaToppings) are from the same country (e.g. MeatTopping Lardon_Alsace and CreamTopping CrèmeFraîche_Normandie both have hasCountryOfOrigin equal to the individual France).
The reasoner (Pellet) finds nothing.
Can I use any swrlb function instead?
+++EDIT1+++
I have come up with the following solution:
Pizza(?p),
hasIngredient(?p, ?ing1), hasIngredient(?p, ?ing2),
hasCountryOfOrigin(?ing1, ?c1), hasCountryOfOrigin(?ing2, ?c1) -> NationalPizza(?p)
which gives correct result.
Alternatively, I also tried that way with OWL expressions:
Pizza(?p), (hasIngredient min 2 PizzaTopping)(?ing) -> NationalPizza(?p)
but then how do I incorporate the condition that country must be the same? Any ideas?
+++EDIT2+++
I made following changes to my SWRL rule (based on #AKSW comment) in the SWRLTab:
Pizza(?p) ^
hasIngredient(?p, ?i1) ^ hasIngredient(?p, ?i2) ^
hasName(?i1, ?ni1) ^ hasName(?i2, ?ni2) ^ swrlb:notEqual(?ni1, ?ni2) ^
hasCountryOfOrigin(?i1, ?c1) ^ hasCountryOfOrigin(?i2, ?c2) ^
hasName(?c1, ?nc1) ^ hasName(?c2, ?nc2) ^ swrlb:equal(?nc1, ?nc2)
-> NationalPizza(?p)
but the Pellet (incremental) reasoner does not assert the individual BlancheAuxLardonds_MaMère, which indeed has (at least) two different ingredients (Lardon_Alsace and Reblochon_LEcho-des-Alpages) from the same country (France).
+++EDIT3+++
I made following changes in the ontology (based on #AKSW comment):
<rdf:Description>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AllDifferent"/>
<owl:distinctMembers rdf:parseType="Collection">
<rdf:Description rdf:about="http://www.co-ode.org/ontologies/pizza#CrèmeFraîche_Normandie"/>
<rdf:Description rdf:about="http://www.co-ode.org/ontologies/pizza#Gorgonzola_Maribor"/>
<rdf:Description rdf:about="http://www.co-ode.org/ontologies/pizza#Lardon_Alsace"/>
<rdf:Description rdf:about="http://www.co-ode.org/ontologies/pizza#Mozzarella_Buffala"/>
<rdf:Description rdf:about="http://www.co-ode.org/ontologies/pizza#Reblochon_LEcho-des-Alpages"/>
</owl:distinctMembers>
</rdf:Description>
Any help on that?
My ontology is here.
Related
Design a Turing Machine to accept {1^n: n is prime number}.
I have this homework to make a recognizer Turing Machine that will be accepted if the occurrences of 1 are equal to any prime number. As of now, I still got no idea how to find the solution related to this prime number.
How should I go about this?
Because we're making a Turing machine and we haven't explicitly said we care about performance, odds are we just care about showing that TMs can solve this problem - so, any solution, no matter how dumb, should suffice. What is a correct, if needlessly tedious, way to show that a number in unary format (e.g., 1^p) is a prime number? One way is to check whether the number of p's is evenly divisible by any number between 2 and p - 1, inclusive. This is actually pretty easy to do for a Turing machine. Since the problem doesn't tell us not to, we can make it even simpler by using a multi-tape Turing machine for our construction.
Let the input be on tape #1 and use tape #2 to record the current thing we are trying to divide the input by. Before we begin, we can verify that our p is greater than 2, as follows:
see if the current tape square is 1, if so, move right, else halt-reject since 0 is not prime
see if the current tape square is 1, if so, move right, else, halt-reject since 1 is not prime
see if the current tape square is 1, if so, reset the tape head and continue on with our division process, knowing p > 2; else, halt-accept since 2 is prime.
If we're continuing at this point, that means we've verified we are looking at the unary encoding of a number greater than 2. We need to do this because 2 is the first number for which we need to check divisibility, and we don't want to say 2 is composite since 2 divides it. At this stage, we can write 11 (unary 2) on tape #2. If you like, you can do this as you are resetting the tape head as mentioned above. Otherwise, you can use some new states specifically for that part of the setup.
We are now looking at a TM configuration like this:
#1111111111111111111111#
^
#11#
^
We want to see if the number represented on the second tape evenly divides the number represented on the first tape. To do this, we can "cross out" numbers on the first tape repeatedly, in groups the size of the second tape, until we run out of numbers on the first tape. If we run out in the middle of crossing out a whole group, then the number represented on the first tape is not evenly divisible by the number represented on the second tape, and we can proceed to check increasing numbers on the second tape. If we run out after having crossed out an entire group, then it is evenly divisible by a number other than 1 and itself, so we can halt-reject as the number is not prime. Processing our example would look like:
=> #1111111# => #x111111# => #xx11111# => #xx11111#
^ ^ ^ ^
#11# #11# #11# #11#
^ ^ ^ ^
=> #xx11111# => #xx11111# => #xx11111# => #xxx1111#
^ ^ ^ ^
#11# #11# #11# #11#
^ ^ ^ ^
=> #xxxx111# => ... reset => #xxxx111# => ... cross
^ tape 2 ^ off another
#11# back to #11# pair of 1s
^ head ... ^ ...
=> #xxxxxx1# => #xxxxxxx#
^ ^
#11# #11#
^ ^
At this stage we see a 1 on the second tape and a blank on the first tape; this means the number was not divisible by our current guess. If we had seen blank/blank, we could have halt-rejected immediately. Instead, we need to continue checking larger possible divisors. At this stage we need to:
reset the first tape head to the beginning of the input, replacing x's with 1's again.
add an extra 1 to the second tape head to increment its value, then reset the head to the beginning of its value.
repeat the divisibility check described above.
If we continue this process, we will eventually find a divisor of the number represented on the input tape, if that number is composite. As it is, however, we will currently halt-reject on prime numbers when the second tape increases to the same number as the input. We will then find that the prime number evenly divides itself. We need to check for this; a good place would be between steps 2 and 3 in the last set of 3 steps above, we can compare tapes #1 and #2 and see if they match exactly. this would be just like the divisibility check, but it would only cross off at most one copy of tape #2 from tape #1, and it would halt-accept if it got to blank/blank rather than halt-rejecting.
Obviously, there are a lot of details to fill out if you want to formally define the TM by giving its transition table. But, it can be done and a procedure like the one outlined here can be used to solve this problem. Again, this is not the most efficient way to solve this, but it is a way to solve it, which generally is good enough when looking for TMs for some problem.
I need to construct linear bounded automaton for the language L = { a^{n!} : n >= 0 }. I know how LBA functions, however, I don't have a thought how it can check the n! that to in the power of a. I might want to hear a few suggestions, as I am experiencing difficulty in developing the specific LBA for it.
A linear bounded automaton is a multi-tape non-deterministic Turing machine whose tape length is bounded by some fixed linear function of the input length. That is, the amount of tape available to work with must be known in advance from the length of the input and that length must grow linearly with input size. If we can determine a Turing machine for this language and show we know exactly how much tape will be used as a function of the input length, and that function is linear. we have shown the TM to be an LBA.
Consider the following multi-tape non-deterministic Turing machine for checking whether the input it a^(n!):
if the input tape is empty, halt-reject
write a on the second tape
scan the input tape and if there is only one instance of a remaining, halt-accept
otherwise, go back to the beginning of input
then, cross off (n-1) instances of a in the input for every n instances you find. to do this, move the second tape head right to count up to n-1, and when you reach the blank after the last a on the second tape, leave the a you are at on the input tape alone, reset the second tape head, and continue the process
if you end up running out of instances of a on the input tape while attempting to cross off all but every n'th one during step 5, halt-reject, since the input tape was greater than (n-1)! but was not evenly divisible by n.
otherwise, if you run out of instances of a at the same time you complete a full counting of the second tape, reset both tape heads, write another a to the end of the second tape, and continue the process from step 3.
Here's an example of how this TM functions:
Input: #aaaaaa# #aaaaaa# #xaaaaa# #xaaaaa#
^ => ^ => ^ => ^
Second: ######## #a###### #a###### #a######
^ ^ ^ ^
#xaxaaa# #xaxaaa# #xaxaxa# #xaxaxa#
=> ^ => ^ => ^ => ^
#a###### #a###### #a###### #aa#####
^ ^ ^ ^
#xxxaxa# #xxxxxa#
=> ^ => ^ => halt-accept since we are at the end
#aa##### #aa##### of the tape and looking at a blank
^ ^ on the second tape and only one a
remains
A simple analysis of the way this TM works shows that the number of additional tape cells used cannot be more than the number of tape cells used by the input. Because we only use additional tape cells for writing down the current divisor, and all divisors of sufficiently large values of n! are smaller than n!, the total number of tape cells in play (including input) is certainly less than 2*|input|. But 2*|input| is a linear function of the input size |input|, so this TM is also a LBA.
I have 2 variables, one for raw p-values and another for adjusted p-values. I need to compute a new variable based on the values of these two variables. What I need to do isn't too complicated, but I have a hard time doing it in SPSS because I can't figure out how I can reference a particular row for an existing variable in SPSS syntax.
The first column lists raw p-values in ascending order. The next column lists adjusted p-values, but these adjusted p-values are still incomplete. I need to compare two adjacent p-values in the adjusted p-values column (e.g., row 1 and 2, row 2 and 3, row 3 and 4, and so forth), and take the p-values whichever is smaller in each of these comparisons and enter those p-values into the following column as values for a new variable.
However, that's not the end of the story. One more condition has to be met. That is, the new p-values have to be in the same order as the raw p-values. However, I cannot ensure this if I start the comparisons from the top row. You can see that (i') is greater than (h') and (g'), and (d') is greater than (c'), (b'), and (a') in the example below (picture).
In order to solve this issue, I would need to start the comparison of the adjusted p-values from the bottom. In addition, I would need to compare the adjusted p-values to the new p-values of one row below. One exception is that I can simply use the value of (a) as the value of (a') since the value of (a) should always be the greatest of all the p-values as a rule. Then, for (b') , I need to compare (b) and (a') and enter whichever is smaller as (b'). For (c'), I need to compare (c) and (b') and enter whichever is smaller as (c'), and so forth. By doing this way, (d') would be 0.911 and (i') would be 0.017.
Sorry for this long post, but I would really appreciate if I can get some help to do this task in SPSS.
Thank you in advance for your help.
Raw p-values | Adjusted p-values (Temporal)| New p-values (Final)
-------------|-----------------------------|---------------------
0.002 | 0.030 (i) | 0.025 (i')
0.003 | 0.025 (h) | 0.017 (h')
0.004 | 0.017 (g) | 0.017 (g')
0.005 | 0.028 (f) | 0.028 (f')
0.023 | 0.068 (e) | 0.068 (e')
0.450 | 1.061 (d) | 1.061 (d')
0.544 | 1.145 (c) | 0.911 (c')
0.850 | 0.911 (b) | 0.911 (b')
0.974 | 0.974 (a) | 0.974 (a')
Another tool that may be convenient is the SHIFT VALUES command. It can move one or more columns of data either forward or backward.
I wonder whether the purpose of this has to do with adjusting p values for multiple testing corrections as with Benjamin-Hochberg FDR or others similar. If that is the case, you might find the STATS PADJUST (Analyze > Descriptives > Calculate adjusted p values) extension command useful. It offers six adjustment methods. You can install it from the Utilities (pre-V24) or Extensions (V24+) menu.
To get you started, here are a few tools that can help you with this task:
The LAG function
you can compare values in this line and the previous one, for example, the following will compare the Pval in each line to the one in the previous one, and put the smaller of the two in the NewPval:
compute NewPVal=min(Pval, lag(Pval)).
If you want to do the same process only start from the bottom, you can easily sort your data in reverse order and do the same.
CREATE + LEAD
if you want to make comparisons to the next line instead of the previous line, you should first create a "lead" variable and then compare to it.
for example, the following syntax will create a new variable that for each line contains the value of Pval in the next line, and then chooses the smaller of the two for the NewPval:
create /LeadPval=LEAD(Pval 1).
compute NewPVal=min(Pval, LeadPval).
Using case numbers
You can use case numbers (line numbers) in calculations and in conditions. For example, the following syntax will let you make different calculations in the first line and the following ones:
if $casenum=1 NewPval=Pval.
if $casenum>1 NewPVal=min(Pval, lag(Pval)).
I have been having problems with SPSS. When I try to run a data set it says:
>Error # 12005 in column 14. Text: -4
>A parenthesized value range in the MANOVA procedure contains a lower limit
>(the first value) that is greater than the upper limit (the second value).
>Execution of this command stops.
This is the syntax that I am trying to run:
manova P_Progress, P_ObsComp, P_SocFdBk, P_PsyState
by Group4 (1,2,3,4) Group3 (1,2,3)/
print=cellinfo(means)
homogeneity(all)
error(cor)
signif(multiv,univ,stepdown)/
omean=variables(P_Progress, P_ObsComp, P_SocFdBk, P_PsyState) tables(Group4,
Group3)/plot=normal.
I am working on a two way manova.
I advise to consult the IBM SPSS Statistics Syntax Reference regarding the MANOVA. The syntax of MANOVA should be like this:
MANOVA dependent varlist [BY factor list (min,max)[factor list...]
[WITH covariate list]]
I believe this code should work:
manova P_Progress, P_ObsComp, P_SocFdBk, P_PsyState
by Group4 (1,4) Group3 (1,3)
/print = cellinfo(means)
homogeneity(all)
error(cor)
signif(multiv,univ,stepdown)
/omean = variables(P_Progress, P_ObsComp, P_SocFdBk, P_PsyState)
tables(Group4, Group3)
/plot=normal.
I just asked a question about how the Erlang compiler implements pattern matching, and I got some great responses, one of which is the compiled bytecode (obtained with a parameter passed to the c() directive):
{function, match, 1, 2}.
{label,1}.
{func_info,{atom,match},{atom,match},1}.
{label,2}.
{test,is_tuple,{f,3},[{x,0}]}.
{test,test_arity,{f,3},[{x,0},2]}.
{get_tuple_element,{x,0},0,{x,1}}.
{test,is_eq_exact,{f,3},[{x,1},{atom,a}]}.
return.
{label,3}.
{badmatch,{x,0}}
Its all just plain Erlang tuples. I was expecting some cryptic binary thingy, guess not. I am asking this on impulse here (I could look at the compiler source but asking questions always ends up better with extra insight), how is this output translated in the binary level?
Say {test,is_tuple,{f,3},[{x,0}]} for example. I am assuming this is one instruction, called 'test'... anyway, so this output would essentially be the AST of the bytecode level language, from which the binary encoding is just a 1-1 translation?
This is all so exciting, I had no idea that I can this easily see what the Erlang compiler break things into.
ok so I dug into the compiler source code to find the answer, and to my surprise the asm file produced with the 'S' parameter to the compile:file() function is actually consulted in as is (file:consult()) and then the tuples are checked one by one for further action(line 661 - beam_consult_asm(St) -> - compile.erl). further on then there's a generated mapping table in there (compile folder of the erlang source) that shows what the serial number of each bytecode label is, and Im guessing this is used to generate the actual binary signature of the bytecode.
great stuff. but you just gotta love the consult() function, you can almost have a lispy type syntax for a random language and avoid the need for a parser/lexer fully and just consult source code into the compiler and do stuff with it... code as data data as code...
The compiler has a so-called pattern match compiler which will take a pattern and compile it down to what is essentially a series of branches, switches and such. The code for Erlang is in v3_kernel.erl in the compiler. It uses Simon Peyton Jones, "The Implementation of Functional
Programming Languages", available online at
http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/
Another worthy paper is the one by Peter Sestoft,
http://www.itu.dk/~sestoft/papers/match.ps.gz
which derives a pattern match compiler by inspecting partial evaluation of a simpler system. It may be an easier read, especially if you know ML.
The basic idea is that if you have, say:
% 1
f(a, b) ->
% 2
f(a, c) ->
% 3
f(b, b) ->
% 4
f(b, c) ->
Suppose now we have a call f(X, Y). Say X = a. Then only 1 and 2 are applicable. So we check Y = b and then Y = c. If on the other hand X /= a then we know that we can skip 1 and 2 and begin testing 3 and 4. The key is that if something does not match it tells us something about where the match can continue as well as when we do match. It is a set of constraints which we can solve by testing.
Pattern match compilers seek to optimize the number of tests so there are as few as possible before we have conclusion. Statically typed language have some advantages here since they may know that:
-type foo() :: a | b | c.
and then if we have
-spec f(foo() -> any().
f(a) ->
f(b) ->
f(c) ->
and we did not match f(a), f(b) then f(c) must match. Erlang has to check and then fail if it doesn't match.