I've been trying to find a super simple explanation of Push-Down Automaton. This is what I've come up with so far:
A PDA has three operations:
A push to the stack; given an input state, input symbol, and the top stack symbol
A pop from the stack; given an input state, input symbol, and the top stack symbol
A "switch" operation, replacing the top of the stack with another symbol; given an input state, input symbol, and the top stack symbol
A PDA has two accepting forms:
Operations such that the stack has been emptied
Operations such that the stack is back to the starting symbol, and on an accepted final state.
I'm wondering if my second point here is correct. Are these the only two ways a PDA will accept a string, and are these even correct? I've found a ton of examples, but no super simple explanation of the idea.
Related
For example I have several states I will name A, B and C.
A allows 1,0 and loops. When it enters state B, is it possible that everything will be empty again before going to C? If yes, how?
In general finite automata is like decision making type.It can tell whether the given string is recognized by the automata or not.The major draw back of finite automata is that it can't recognize the previously given input.so to enhance it we are going for push down automata(pda).In pda we have stack to store the input symbols.There also we can push or pop only one element at a time.If you want to pop all elements when it enters state B then use a loop to pop all elements of the stack until stack becomes empty
I am running into parser stack overflow in yacc. I am not sure how is the current parser stack size determined. IS there a way to get current parser stack size, so that once the number of tokens reaches the maximum stack depth, an error can be reported? Is there a variable in yacc that holds this information?
There is no standard way to get the parser stack size, although obviously it is internally available since the parser is capable of producing a stack overflow error (without segfaulting or otherwise invoking undefined behaviour). You don't need to check this yourself; you simply need to print the error message provided to yyerror; if the stack overflows, the error message will mention that fact.
There are a few ways you can end up with a version of yàcc which doesn't resize the stack. One is the use of the public domain Berkeley yacc, often called byacc; the version I have kicking around (from 1993) sets the default stack size to 500.
Another possibility is to use Gnu bison, compiling the result with a C++ compiler; by default, this will make the stack non-relocatable since bison doesn't know whether the semantic value union is trivially copyable. (Newer versions of bison might not have this restriction.) By default, the initial bison stack size is 200.
A common way to blow up stacks is to use right recursion for long lists. A particularly bad one is some variant on the following:
program: /* empty */
| statement program
;
which will cause the parser stack overflow if a "program" is too long. It's usually sufficient to just change that to left recursion:
program: /* empty */
| program statement
;
I have been practicing some questions on automata theory where I came across a question on minimal dfa at which I can't figure out where I have gone wrong.I am getting 4 states in the minimal dfa but my book says answer is 3.The question asks a given NFA to convert into a minimal DFA and count the number of states in the latter one.The given NFA(p and r are initial and final states respectively) is:
{p}---b-->{q}
{q}---a--->{r}
{q}---b--->{s}
{r}---a--->{r}
{r}---b--->{s}
{s}---a--->{r}
{s}---b--->{s}
I am getting 4 states:[r],[p],[q,s],[dead].Can the final [r] and the non-final state [q,s] be merged here since they lead to the similar configuration on receiving inputs a and b??I have learned that final and non-final states cannot be in the same equivalence class...
OK, let's start with all possible states for our DFA, there will be 17 (2^4 for the 4 symbols plus 1 for the empty set). These will be:
{}
{p}
{q}
{r}
{s}
{p,q}
{p,r}
{p,s}
{q,r}
{q,s}
{r,q}
{r,s}
{p,q,r}
{p,q,s}
{p,r,s}
{q,r,s}
{p,q,r,s}
Now that we have all the possible sets, let's highlight all that are reachable from the start state p:
{}
{p} --- Start state. From here we can get to {q} only as defined by the transition {p}--b-->{q}
{q} --- from here, we get to r or s, so {r,s} as defined by {q}--a-->{r} and {q}--b-->{s}
{r}
{s}
{p,q}
{p,r}
{p,s}
{q,r}
{q,s}
{r,q}
{r,s} --- from here, we can only get to r or s (the same state!), so we're at a dead end.
{p,q,r}
{p,q,s}
{p,r,s}
{q,r,s}
{p,q,r,s}
The three accessible states are thus {p},{q}, and {r,s}. The reason the "dead" state, or empty set is not reachable is that none of the accessible transitions lead to it.
Hope this helps!
I'm working on assignment 2 of CS193P - Stanford's IOS programming course. One thing I was wondering about is how the calculatorBrain is supposed to be able to accept and run a stored program, a program being an array or stack of operands and operations.
So let's say we want to perform the following calculation: 2, 3, 4, +, *
If you typed this into the calulator, the following would happen:
2 3 4 get pushed onto the stack one at a time, and runProgram called for each one, which simply pops the number off the stack and returns it's value which gets pushed onto the stack.
You press +, and runProgram pops this and sees it has to add the top 2 items which it does and pushes the result onto the stack which now contains 2, 7. You press * and the stack now contains 14.
But I can't see how you can pass an array containing (2, 3, 4, +, *) to the brain (the instructor says later you can just pass a program to the runProgram class method and get the result, without having to instantiate a brain object), as runProgram would first try to execute the top operand i.e. * and to do this it would take the next two objects off the stack and try to multiply them and to push the result back onto the stack. These 2 objects are "+" and "4" which won't work.
Now the instructor has been doing this a lot longer than I have, as I assume that I'm missing somethings, but I'm not sure what.
Any ideas?
If you look at this as passing "2,3,4,+,*" to the "brain", you need to be thinking in the context of the stack processor.
The arguments are evaluated in the order in which they are encountered in the array. But, don't confuse the array for the stack, they are different objects. The stack is internal to the calculator routine and the array of input is external to the routine. Since I'm not taking that particular class at whatever school you're in, I can't speak to the particulars of the language in use, but basically, think of the array "2,3,4,+,*" as input to the keyboard of the calculator. However, the calculator is a very simple machine and only processes one key press at a time.
Thus, when you process the array, you're basically passing each element of the array to the calculator for processing and the calculator is then deciding whether to push to the stack or execute the operator. These elements are passed in order, so the calculator receives: 2 followed by 3, followed by 4, followed by '+', followed by '*'.
It looks like you're trying to think of the problem in terms of the array being passed in to the calculator as the stack, and that's not what you want to do here.
I hope this is clear.
OK - the answer is that the way runProgram gets the next item off the stack is by recursively calling a popOperandOffStack (pOOS) method.
So when it gets passed a program consisting of 2 3 4 + *, it starts by popping * off the stack. It then has to pop the next two operands off the stack. So it calls pOOS, which firstly returns a '+', so it then calls pOOS again (twice) which gets '4' & '3' respectively, which are added to get 7 which is pushed back onto the stack (which now contains 2 7) and also returned as the result of calling pOOS. So when it called pOOS for the first operand of the '*' operation it didn't get '+', it actually got '7'. The second call to pOOS (for the second operand of the *) gets '2' which it then happily multiplies to get 14.
I did try looking up recursion in my IT dictionary, but it just said 'See recursion'.
#steve Ives, I think you nailed the answer with this last comment. Having gone through this assignment a few weeks back (also on my own), I found this site to be helpful understanding the reverse polish calculator, it basically emulates one. But as you are thinking recursion, your brain can go into overload mode. Hope this helps validating some of your scenario testing...Good luck.
HP12C Emulator
I have a task, where I have to calculate optimal policy
(Reinforcement Learning - Markov decision process) in the grid world (agent movies left,right,up,down).
In left table, there are Optimal values (V*).
In right table, there is sollution (directions) which I don't know how to get by using that "Optimal policy" formula.
Y=0.9 (discount factor)
And here is formula:
So if anyone knows how to use that formula, to get solution (those arrows), please help.
Edit: there is whole problem description on this page:
http://webdocs.cs.ualberta.ca/~sutton/book/ebook/node35.html
Rewards: state A(column 2, row 1) is followed by a reward of +10 and transition to state A', while state B(column 4, row 1) is followed by a reward of +5 and transition to state B'.
You can move: up,down,left,right. You cannot move outside the grid or stay in same place.
Break the math down, piece by piece:
The arg max (....) is telling you to find the argument, a, which maximizes everything in the parentheses. The variables a, s, and s' are an action, a state you're in, and a state that results from that action, respectively. So the arg max (...) is telling you to find an action that maximizes that term.
You know gamma, and someone did the hard work of calculating V*(s'), which is the value of that resulting state. So you know what to plug in there, right?
So what is p(s,a,s')? That is the probability that, starting from s and doing a, you end in some s'. This is meant to represent some kind of faulty actuator-- you say "go forward!" and it foolishly decides to go left (or two squares forward, or remain still, or whatever.) For this problem, I'd expect it to be given to you, but you haven't shared it with us. And the summation over s' is telling you that when you start in s, and you pick an action a, you need to sum over all possible resulting s' states. Again, you need the details of that p(s,a,s') function to know what those are.
And last, there is r(s,a) which is the reward for doing action a in state s, regardless of where you end up. In this problem it might be slightly negative, to represent a fuel cost. If there is a series of rewards in the grid and a grab action, it might be positive. You need that, too.
So, what to do? Pick a state s, and calculate your policy for it. For each s, you're going have the possibility of (s,a1), and (s,a2), and (s,a3), etc. You have to find the a that gives you the biggest result. And of course for each pair (s,a) you may (in fact, almost certainly will) have multiple values of s' to stick in the summation.
If this sounds like a lot of work, well, that's why we have computers.
PS - Read the problem description very carefully to find out what happens if you run into a wall.