Suppose that DFA D is a valid DFA. What would this imply regarding the reachability of its final states from initial states? May I assume this:
$\delta^* (q_0, w) = f$, where $w \in \Sigma$ and $f \in F$
No, you cannot assume this. It's perfectly consistent with the definition of a DFA for there to be states which are unreachable from the starting state. What you can do is start with a DFA and filter it down to just the states reachable from the start state without changing the language of the DFA, though, if you think it would help.
Hope this helps!
Related
I've read some material about quantum computers and quantum circuits. A certain number of already known algorithms (Simon's algorithm, period-finding algorithm, Grover's algorithm, …) have the following form:
Suppose I have an unknown classical function f: {0,1}^n -> {0, 1}^m satisfying a certain number of statements. I can associate the (unknown) quantum circuit U_f to it and plug the |0.. 0> input state. Now let us define circuit X and show that when appended to U_f, the global output can be measured to extract some information about f.
Wait a minute... What is the relation with classical circuits? A classical problem would refer to an unknown input that satisfies certain properties, this input representing a state coming from outside (user action, file system, database, server, whatever). In case this state is rather generated by another circuit/algorithm the logic applies to the input before. In the end we don't reason about unknown circuits but about unknown inputs. The circuits (the algorithms/ the functions) are the known/chosen components.
Here I came to realize that the common name "circuit" was somehow misleading. In a classical world gate inputs can be thought as values coexisting with outputs. But quantum gates seem to require a temporal interpretation: inputs and outputs represent temporal evolution of the same qubits.
Now this does not really explain how you transform a given bunch of a priori unknown classical input bits (that I believe your keyboard will keep on generating in the future except maybe if Schrödinger's cat is sitting on it) into a "black box quantum circuit" transforming |0…0> into something to be reversed. For example Grover's algorithm propose, for a quantum circuit corresponding to a function f: {0, 1}^n -> {0, 1} that yields 1 for a single unknown input, an efficient method to determine this input. Nice! But how and why would you have to start with such a circuit in the first place?
In practice, the 'unknown function black box' is just a circuit that checks if its input meets some criteria or is the solution to a problem.
This is useful because it's easier to make a circuit that detects a solution than it is to actually find a solution. Grover's algorithm then augments our detector circuit into a solver circuit:
The classical equivalent of Grover's algorithm is a brute-force search function like this:
def bruteForceSearch(min, max, predicate):
for i in min..max:
if predicate(i):
return i
return none
which you would use it like so:
let mersennePrimeWithFiveDigitExponent = bruteForceSearch(
10000,
99999,
i => isMersennePrime(2**i - 1))
Notice how the brute force search turns our knowledge of how to recognize something into a mechanism for finding something. Grover's algorithm does the same thing, but quadratically faster and with the caveat that the recognizer must be implemented as a reversible circuit.
I have been reviewing some material on the representation of an AI plan given the STRIPS format, and found that different people seem to formulate the same problem in different ways.
For instance, Wikipedia has an example regarding the Monkey in the lab problem. The problem states that:
A box is available that will enable the monkey to reach the bananas hanging from the ceiling if he climbs up on it. Initially, the monkey is at A, the bananas at B, and the box at C. The monkey and the box have height Low, but if the monkey climbs onto the box, he will have height High, the same as the bananas. The actions available to the monkey include Go from one place to another, Push an object from one place to another, ClimbUp onto or CLimbDown from an object, and Grasp or UnGrasp an object. Grasping the object results in holding the object if the monkey and the object are in the same place at the same height.
Here is the Wikipedia plan (please note that it is not matched exactly to this problem description, but it is the same problem. It doesn't seem to implement Ungrasp, which is not important for this discussion):
Now nowhere in this plan can I see that the bananas are located at Level(high), so the only way this could actually be divulged from the plan would be to read through the entire set of Actions and deduce from there that the Monkey must be at Level(high) to interact with the bananas, hence they must be at Level(high).
Would it be a good idea to put this information in the Initial State, and have something like:
Monkey(m) & Bananas(ba) & Box(bx) & Level(low) & Level(high) & Position(A) & Position(B) & Position(C) & At(m, A, low) & At(ba, B, high) & At(bx, C, low)
It looks quite verbose like that, but at the same time, it allows the reader to understand the scenario just through reading the Initial State. I've also been told that we should not be using constants anywhere in STRIPS, so I thought declaring the A, B, and C as Positions was a good idea.
Is it that some people do it differently (which I feel would kind of ruin the idea of having a standardized language to represent things), or is it that one of the ways I have presented isn't in the correct format? I am new to STRIPS, so it is entirely possible (and likely) that I am missing some key points.
This is not the greatest wikipedia ever. The description of STRIPS is accurate, but a little outdated.
Generally you don't need to worry about defining all the variables in the initial state because the variables are defined by the domain (the P in the quadruple in the linked article). For an intuition as to why, you have an operator for MONKEY in your initial state, but you're still introducing a free variable m that is not defined anywhere else. You end up with a chicken and egg problem if you try to do it that way, so instead the facts in the system are just propositional variables which are effectively sentinel values that mean something to the users of the system, not the system itself.
You are correct that you need to define the level for each item as part of the initial state, but the initial state of the example actually correct considering the constraints that the bananas are always high, the box is always low and the monkey is the only thing that changes level. I would probably change the example to have the At proposition take into account the object in question instead of using different proposition names for each object but that's just a style choice; the semantics are the same.
Operators in STRIPS are generally represented by 3 distinct components:
preconditions - each variable in the preconditions list must exactly match the corresponding variable in the current state (trues must be true, falses must be falses) but you ignore all other variables not explicit in the preconditions
add effects - when the action is performed, these are the effects that variables that are added to the state
delete effects - when the action is performed, these are the effects that are deleted from the state
and sometimes a 4th cost component when considering cost optimality
The post conditions listed in your example are the union of the add effects and delete effects. The advantage of separating them will come later when you get into delete relaxation abstractions.
In your proposed initial state you have propositions that contain multiple properties for the same object (e.g. At(bx, C, low)). This is typically avoided in favor of having a proposition for each property of each object in the state. Doing it this way makes you end up with a larger state, but makes for a much simpler implementation since you don't have to decompose a state variable in order to identify the value of a specific property of an object in the preconditions list.
as the title suggests I want somebody to help me in coding the conversion of NFA to DFA . I need the pseudocode only . I have tried searching using Google , and I found the whole source code even , however there were little resource to help me for giving me a formal method (in written words,not via picture) for the conversion . This is a homework problem , and I have already passed the due date , so I really need some altruism here .
Thanks.
I've written an article on this subject.
Converting a NFA to a DFA by subset construction
It includes pseudocode on how to do the transformation as well.
Basically the algorithm is, starting with the starting state of the NFA:
Perform closure on the current state set
For each input symbol do the GOTO operation on the closure set.
If the state set you get from the GOTO is not empty
Do a closure of the state set.
If it is a new set of states:
add a transition between the state sets on the input
repeat the entire operation on this new set
Else
add a transition between the state sets on the input
Do this until there are no more sets or transitions added. It's a difficult algorithm to explain, but not very hard if you have the two basic operations CLOSURE and GOTO done.
When we converting from nfa to dfa there may be result like the image below... My question is, is it necessary to write that from state {4} it's going to Zero state? I mean that without showing the input symbol 1 of {4} is the same with picture below right? or no?
It’s a matter of convention. Personally, I prefer not to clutter my DFA with unnecessary states, especially since DFAs obtained via transformation from NFAs tend to become quite complex anyway, and since it’s deterministic we know that any non-displayed transition must be invalid.
However, I’ve experienced that many people in academia teach / use the other convention, and require all transitions to be explicitly shown. When working as a TA (tutor) I’ve actually had a discussion with a professor about this – he wanted us tutors to deduct points on the final tests for missing transitions in DFAs but I convinced him that deducting points for this was unfair.
it is not necessary to write {4}-> 0 transition because the automat is already accepting the word. this transition means only that this is "nothing" meaningful for our solution. but for details, it is useful to give it, to show the whole automaton.
It matters only if you are trying to draw the MinimalFA (MFA).
Actually you can generate infinite number of DFA s from a single NFA, each of which differ in number of states.
If you remove 'Dead States' in the figure,you will get the MFA.
The figure is OK if you just want a DFA
I am looking for an algorithm to convert a Deterministic Finite Automata to Push Down Automata.
Any help appreciated.
Thanks!
The PDA version of DFA would look the same except each state transition also pushes nothing on the stack and pops nothing off the stack.
Since a PDA is an extension of a DFA with just one additional feature : stack.
Because the transition of a PDA is determined by a triple (current state, input, element at the top of the stack) while transition of a DFA is determined by a tuple (current state, input). And the only difference is the element at the top of the stack. You can convert all the transitions of DFA by transforming the tuple to a triple, e (empty string) inserted as the element at the top of the stack
And after changing the state, push e (empty string) to the stack.
I'm answering this old question just in case someone else looks at it.
The conversions of DFA to PDA can be automated easily by just adding a stack. But there could be possible changes to the semantics of the DFA and after you change it that way manually you could end up in a PDA with less number of states. I faced this problem recently. Its somewhat like this,
In a system (not a compiler or anything like that) the code written earlier was written using an DFA due to some reasons. The transitions occur as the user progress through the code using various functions. After some time a new set of transitions functions arrived which can be used in any order. and also the state after any of these new functions can change back to previous state by one of these functions. The only way to solve this using FST was to add a large number of new states to support this behavior which i a huge amount of work. But instead I just changed from DFA to a PDA. The stack keeps track of the transitions very nicely and the problem is solved with far less number of states. Actually i only had to add N number of states where N is the number of new functions that arrived.
I do not know if someone can automate this kind of a process easily. But there you go, just in case someone is curious about it.
The wikipedia article says
Pushdown automata differ from finite
state machines in two ways:
They can use the top of the stack to decide which transition to
take.
They can manipulate the stack as part of performing a transition.
Pushdown automata choose a transition
by indexing a table by input signal,
current state, and the symbol at the
top of the stack. This means that
those three parameters completely
determine the transition path that is
chosen. Finite state machines just
look at the input signal and the
current state: they have no stack to
work with. Pushdown automata add the
stack as a parameter for choice.
...
Pushdown automata are equivalent to
context-free grammars: for every
context-free grammar, there exists a
pushdown automaton such that the
language generated by the grammar is
identical with the language generated
by the automaton, which is easy to
prove. The reverse is true, though
harder to prove: for every pushdown
automaton there exists a context-free
grammar such that the language
generated by the automaton is
identical with the language generated
by the grammar.