A Brutal Look at Balanced Parentheses, Computing Machines, and Pushdown Automata

http://raganwald.com/2019/02/14/i-love-programming-and-programmers.html

by braythwayt • 7 years ago

146 77 7 years ago

raganwald.com

praptak• 7 years ago

A silly trick question: are balanced parentheses expressions palindromes?

noir_lord2• 7 years ago

No because () reversed is )(

pygy_2• 7 years ago

Also, they are not necessarily mirror images:

    (()())()

agumonkey2• 7 years ago

should we call these symmetromes ?

skybrian3• 7 years ago

I skimmed, but feel like he should have talked about how in an interview question, you could solve this by counting parens with a 64-bit counter. There are limits on practical input size and on stack size, so arguments about infinite languages don't directly apply.

A deeper question to consider: why do we study infinite languages and then apply the results to finite problems? What do we learn this way?

Epholys• 7 years ago

Yeah, that's the first solution that popped in my mind too. I think it needs just a special case at the beginning to check if the first paren is not a closing one.

EDIT: yep, after reading the comments below I see that I really should have put just a little more thought before dismissing this as too trivial to think about.

skybrian3• 7 years ago

A test case: ())(

FreeFull• 7 years ago

What you actually need is to check if the count ever goes negative.

braythwayt14• 7 years ago

The stack solution checks that the stack is non-empty before popping.

The counter solution simply needs to check that the counter is non-zero before decrementing.

All cases then work perfectly.

braythwayt14• 7 years ago

Author here.

That solution has been discussed elsewhere in my blog. If you think of the family of problems involving nested things, or tree-like things, or recognizing, or parsing, the case where we only have one kind of parentheses and nothing else is what we might call the "degenerate case."

And like many degenerate cases, there is an optimization: Instead of pushing the exact same parenthesis onto the stack over and over again, we count them.

Alas, this does not grow. If we want to modify our code to handle multiple types of parentheses, or parse expressions that include parentheses into trees, and so forth, we must return to the stack.

So... My general thinking is that it is useful to know that for the degenerate case, we can replace a stack with a counter, but should I ever find myself writing a parser or what-not, if I used an optimization like this, I'd probably document that it's an optimization the degenerate case where we only ever put one thing on the stack.

One wild way to do that is to leave the code as-is, but hack the stack itself. So you still call .push() and .pop() and so forth, but behind the scenes, the "stack" object just counts pushes and pops.

skybrian3• 7 years ago

Yes, agreed. But it does show another pitfall when it comes to using a degenerate case as an interview question: someone who doesn't know anything about parsing or stacks might solve it easily if they have a different mindset. On the other hand, half-remembering something from school could really mess you up.

mehrdadn• 7 years ago

What do you do when you have multiple types of grouping? E.g. Parentheses and braces and brackets in a programming language?

mjevans• 7 years ago

I think that depends on the goals of the design. The very simple single-grouping type case can be used to prove that something isn't obviously false in isolation.

Once grouping starts to be an issue I think that different spans need to be broken out from the main section and each treated as isolated fragments to validate.

pflats2• 7 years ago

Asking someone who hasn’t been recently exposed to computing theory to write a balanced parentheses recognizer is asking them to reinvent the basic research of people like Kleene and von Dyck, extemporaneously. And then write code under the interviewer’s watching eye. That is unlikely to show these candidates in their best light, and the results become very uneven.
Outside of a special-case like certain CS students, this question is likely to give very inconsistent results, and those results are going to be dominated by a candidate’s recent familiarity with the underlying problem, rather than their coding skills.
In most cases, that makes for a bad interview question.

This only makes it a bad interview question if the goal of the question is to only hire the candidates that can code the solution.

Otherwise, it can be a very good interview question. How do they go about "reinvent[ing] the basic research of people like Kleene and von Dyck, extemporaneously"? What questions do they ask? What ideas do they come up with? What resources do they say they would consult? Under pressure, how do they behave? If they make a mistake, are they coachable? Do they lash out or double-down on mistakes? If they mention using a language's regex, do they understand the performance tradeoffs of various different features?

There is a lot to see by asking the question beyond just "whether or not candidate X can code a solution".

pflats2• 7 years ago

Beyond that, I have taught theory of computation in the past, and I think the rest of the article is a solid writeup. The DPA section might need another pass; that felt the most uneven. Things that jumped out at me:

- If the audience if programmers unfamiliar with automata theory, I am not sure how many would know what a Turing machine, von Neumann machine, or even a program counter is.

- Clarifying what is meant by "internal" and "external" state.

braythwayt14• 7 years ago

Thank you, that's excellent feedback.

tropo2• 7 years ago

There is no program counter. Computers don't normally need to count programs. ("let's see, I have calc.exe, that's one, and notepad.exe makes two...")

There is an instruction pointer. Note that it doesn't count. It frequently is incremented, but it can jump forward and even backward. It points at an instruction.

braythwayt14• 7 years ago

That's certainly an interesting approach, but in that case I would want to budget a fair bit of time, and not be attached to coding a solution at all.

And again, you want to be aware that you are going to have sharply different experiences depending upon the candidate's familiarity with the basic research.

It would be very interesting to walk through a candidate's thinking about this problem "raw," but it would be grossly unfair to ask the same question of an intern who had studied the problem in the last semester.

I have seen interview questions along the lines of "reinvent basic research," but they typically pick something obscure-ish to reduce the likelihood that the candidate has seen it before, and such things are usually more of the dreaded "whiteboard your thinking," rather than judging you based on the code produced.

agumonkey2• 7 years ago

after that you're ready to read about https://en.wikipedia.org/wiki/Catalan_number

deathanatos4• 7 years ago

Outside of a special-case like certain CS students, this question is likely to give very inconsistent results, and those results are going to be dominated by a candidate’s recent familiarity with the underlying problem, rather than their coding skills.
In most cases, that makes for a bad interview question.

Well, I'm going to have to disagree there. Asking the question and expecting full knowledge of the theoretics behind it, yes. But real-world "practical" software engineering often requires writing parsers, and yes, parsers for context-free languages (whether the parser-writer realizes that or not). A simple, hand-rolled recursive descent parser would suffice for this language.

But what if someone hasn’t seen this stuff in a decade? Or learned to program without going through a formal CS education? Is it reasonable to expect them to work out the ideas in an interview?

Someone, in a decade of SWE experience, has never needed to implement a parser?

Parsing, as a category of things to talk about, has stuff that someone with a theoretical background should know, but it is also so imminently practical that someone without the degree should have hit it and be able to answer it. I'm not asking that they realize this is a deterministic context free language, or that a PDA is the appropriate machine to parse such a language.

The point of balanced-parens as an interview question is not to get you to recreate the entire history and hierarchy of languages. It's to get you to write a for loop that requires a moderately involved data structure (a stack) to see if you have any ability to reason and to code.

(I also dislike asking the single-variant form of this question, as you can solve it w/ a simple counter. If you involve a second type of matched character, e.g., {}s, then it should require a PDA.)

Are other engineering disciplines so readily accepting of folks w/o training in the field in which they're applying a job to?

If not this, then what? "They might not have run into this!" is why we (should…) ask more than one question in an interview. But I feel like this refrain gets used to justify never asking any question which might reveal that half the candidates that apply for "Senior Software Engineer" positions cannot express proficiency in any programming language…

braythwayt14• 7 years ago

Where I work, we track statistics on our interview questions. We are retiring this one because we believe that the results are strongly skewed by whether the candidate has had exposure to the theory behind it.

We only use this for people at the beginning of their career, mind you. We have completely different expectations of someone with ten years of experience than we do of someone applying for a CAP (aka "work-term") or SDE I (aka "entry-level") position.

It's not that good people can't work it out from first principles, but it's clearly a lot more work for those who have to figure it out from first principles than for those who know immediately that a stack is involved and apply their focus to the loop and the stack and handling follow-up questions.

The ideal question or problem from our perspective is is one that is equally challenging for everyone, that way when we're having a candidate review, we won't need a lot of, "...But then again, the candidate clearly knew nothing about parsing, so they actually did quite well, considering."

thaumasiotes2• 7 years ago

The ideal question or problem from our perspective is is one that is equally challenging for everyone

It seems like you could solve this by asking a question no one has ever been exposed to before, or by exposing each candidate to the theory relevant to the question yourself.

Except that the first strategy is guaranteed to fail some of the time, because there are no questions like that.

Why not go the other way?

kjeetgill3• 7 years ago

This is amazingly well written. You covered a good deal of any introduction to computational theory course in a straightforward, well motivated matter. This is definitely something I'll be passing around to some of my bootcamp friends who are curious taste some of the theory they don't get exposure to.

Ironically, what I thought what made this so effective and interesting was that it dug into the theory of a really really easy programming problem. This is a reasonable homework assignment for any first year student. Maybe not month one, but year one for sure.

That suggests the question: Is balanced parentheses a good interview question?

If you just needed a solution to solve the problem and maybe check a few edge cases; yeah, it's great because it's simple. If you're using it to broach a conversation on automata, regular expressions, and context free languages well yeah delving into that is bad unless you're writing real parsers/compilers at this gig.

I was really put off my the musing over whether it's a good interview question. For such a beautifully written piece it seems to say: if you don't expect candidates to know as much as this don't ask it at all.

If you want to make an apple pie from scratch, you must first create the universe.

...

But if I ask you to make an apple pie I'm not going to ding you for starting with apples, flour, sugar, and butter.

braythwayt14• 7 years ago

If you want to make an apple pie from scratch, you must first create the universe.
...
But if I ask you to make an apple pie I'm not going to ding you for starting with apples, flour, sugar, and butter.

That is most eloquently put, thank you! There's a reason that "Food Scientist" and "Chef" are related disciplines, but not the same job.

kjeetgill3• 7 years ago

You probably know, but I should have added that the first line was a quote from Carl Sagan.

braythwayt14• 7 years ago

I took your feedback seriously, tell me what you think:

https://github.com/raganwald/raganwald.github.com/commit/bec...

kjeetgill3• 7 years ago

I like it! I think it cuts closer to what I think people generally should inow at the very least.

An obvious question is, _Do you need to know the difference between a regular language and a context-free language if all you want to do is write some code that recognizes balanced parentheses?_

You have a real talent for motivating the conversation around theory. I like the subject matter so I rarely need more than: hey, I think this is cool. But when I share it with others it says all the things I can't!

seanmcdirmid• 7 years ago

If you're using it to broach a conversation on automata, regular expressions, and context free languages well yeah delving into that is bad unless you're writing real parsers/compilers at this gig.

If it is a compiler gig, I don't think we can get much mileage out out of the balance parentheses problem. Language implementors either just deal with paren balancing as part of the parser or, if they want better error recovery, write a simple paren balancer as a separate pass between lexing and real parsing. In the latter case, implementors will just go with the most simplest solution available and won't bother with a PDA (since it really isn't necessary).

If you really want to test a language implementor, ask them how they would implement a parser for a language that allows < and > to be used as both comparison operators and generic type parentheses.

kerkeslager6• 7 years ago

This is a very well-written essay which explains its computing concepts effectively and thoroughly. I upvoted.

However, the bit at the end with the balanced parentheses matchers being a bad interview question seems to be missing the forest for the trees. A simple solution to this problem which has nothing to do with any of the computational theory discussed:

   def is_balanced_parens(s):
       nesting_depth = 0
       contains_nesting = False

       for c in s:
           if c == '(':
               nesting_depth += 1
               contains_nesting = True
           elif c == ')':
               nesting_depth -= 1
           else:
               return False

           if nesting_depth < 0:
               return False

       return contains_nesting and nesting_depth == 0

This isn't that hard of a problem, and if an interview candidate couldn't come up with a basic solution like this, I'd very much like to know that.

braythwayt14• 7 years ago

As I mentioned elsewhere, I do not find it a hard problem, and neither do most programmers that I know.

BUT.

Most of the people in my "tribe" had some formal education in computer science.

Our experience when hiring people is that there are programmers with a lot of raw talent and potential who will need a full slot (about 45 minutes of actual problem-solving time) to come up with something like the the code you suggest.

There will be no time to discuss their solution, ask them how to handle multiple types of parentheses, &c.

What most of those "They seem really smart, but struggled to balance parentheses" candidates seem to have in common is coming to programming without the formal education, e.g. through a "hacker school."

Whereas, the folks coming to us directly out of a university with a traditional CS curriculum grasp the basic idea right away, and we usually get past the first question and on to a follow-up in the same 45 minutes.

We already know from their resumé that some of the folks are coming from Waterloo or wherever, so it adds no useful information to us for them to do a lot better than the people with less formal backgrounds. For this reason, we now only ask this question of people doing work terms from universities with a formal CS curriculum.

When people are coming to us via another path, we now give them another question entirely, and we will be retiring this one outright in the near future.

user59944614• 7 years ago

Matching parenthesis is a puzzle question. Either the candidate knows to use a stack, or he's gonna spend one hour to figure it out.

tzs• 7 years ago

What most of those "They seem really smart, but struggled to balance parentheses" candidates seem to have in common is coming to programming without the formal education, e.g. through a "hacker school."

How much of this is due to them starting coding before thinking about the problem?

I'd not be surprised at all if these people would, if given several strings of parenthesis on a whiteboard and simply asked if those specific strings were balanced, have no trouble answering. I'd also not be surprised if then asked to explain how they determined this, they could do so. Then, if asked to write a program to use the same method, they could probably readily do it.

A lot of problems that are not hard if you think about them and then start coding are a lot harder if you try to simultaneously work out how to solve it and code that.

kerkeslager6• 7 years ago

There are a bunch of things going on in your post:

1. If you're willing to train programmers, then all you're really looking for is an IQ test to see if they're smart enough to learn how to program. So in that case, you don't really need to ask programming questions at all. But if you're not willing to train programmers, then it makes sense to filter out programmers who aren't familiar with basic problem solving techniques, regardless of background. If they don't know how to do the job, that problem doesn't simply go away because you identify the cause (that they don't have a formal CS background). If a candidate is coming out of a "hacker school", I'd be MORE likely to ask this sort of question because I want to figure out if their lack of formal education is going to be a problem.

2. Someone with a formal CS background obviously has an advantage with this sort of question because they've seen this problem before, or a problem like it. But there's a lot of value in seeing how a candidate approaches a problem they've never seen before.

3. I'll say again that the response I posted doesn't require any formal CS education, as proven by the fact that I came up with that algorithm in an interview for an internship, before I had any formal CS education beyond for loops and if statements.

Twisol2• 7 years ago

I really like this solution, because it generalizes in (what might be) a surprising way.

The basic approach works by associating '(' with the number 1, ')' with the number -1, and replacing string concatenation with addition. The empty string is just 0. A balanced string of parenthesis is one where every prefix has a non-negative valuation and the whole string has a zero valuation.

This valuation function is a monoid homomorphism: the sum of the values of two strings is the same as the value of their concatenation. Membership in our language is a matter of checking the valuation of some set of related strings (here, all prefixes). Converting the problem into this valuation monoid ends up being super convenient.

This solution breaks down into three interwoven but logically separate pieces: identifying the related strings to check, computing their valuations, and validating the valuations. You can tweak any of these steps individually and get a different language.

    import operator

    def scan(f, initial, iterable):
      accumulator = initial
      for value in iterable:
        accumulator = f(accumulator, value)
        yield accumulator

    def valuation(ch):
      return {'(': 1, ')': -1}[ch]

    def is_balanced_parentheses(s):
      values = map(valuation, s)
      for value in scan(operator.add, 0, values):
        if value < 0:
          return False
      return (value == 0)

braythwayt14• 7 years ago

A balanced string of parenthesis is one where every prefix has a non-negative valuation and the whole string has a zero valuation.

Speaking of coming up with solutions from first principles, I had a candidate come up with the following:

Map the opening and closing parentheses to indices, in two arrays. Example: For the string `(())()`, the two arrays would be `[0, 1, 4]` for `(` and `[2, 3, 5]` for `)`.

If the arrays of indices are not the same length, it isn't balanced.

If they are the same length, go through the two arrays in pairs. The candidate didn't express it this way, but I thought "zip the arrays" in my mind, so I'll express it that way, we get `[[0, 2], [1, 3], [4, 5]]`.

The candidate then said, if in each of these pairs, the index for `)` is greater than the index for `(`, the parentheses are balanced. Which is mathematically equivalent to a stack or a counter (the optimized degenerate case) or the prefix valuation.

Of course it's not as efficient as other solutions, and I don't see it generalizing, but hey... It was inventive, in my mind.

munificent• 7 years ago

Your solution is actually an optimized implementation of a pushdown automata.

nesting_depth is the stack. There is only one kind of symbol that can be pushed, so it's represented as a simple count of the number of symbols that are on the stack.

kerkeslager6• 7 years ago

Okay, but I don't need to know the concept of a PDA to implement that, nor would I assume a candidate understands PDAs from reading that code.

UncleEntity• 7 years ago

This isn't that hard of a problem, and if an interview candidate couldn't come up with a basic solution like this, I'd very much like to know that.

   def is_balanced_parens(s):
       return s.count('(') == s.count(')')

Think I'd fail the interview test...

Anon843• 7 years ago

So you claim that ")(" is balanced?

bboreham2• 7 years ago

Fails on the first example in TFA.

deathanatos4• 7 years ago

I think your parent's solution simply considers the empty string not part of the language. The article thinks it is. It's a trivial adjustment to the solution to include it.

antidesitter• 7 years ago

Two purely-functional versions (written in Haskell):

  balanced1 input = 
    let partialsums = scanl (+) 0 $ map (\x -> if x == '(' then 1 else -1) input
    in all (>= 0) partialsums && last partialsums == 0

  balanced2 = balanced' 0 where
    balanced' count [] = count == 0
    balanced' count ('(':rest) = balanced' (count + 1) rest
    balanced' count (')':rest) = balanced' (count - 1) rest && count > 0

A more general version with multiple types of brackets:

  balanced = balanced' [] where
    balanced' stack [] = null stack
    balanced' stack ('(':rest) = balanced' ('(':stack) rest
    balanced' stack ('[':rest) = balanced' ('[':stack) rest
    balanced' stack ('{':rest) = balanced' ('{':stack) rest
    balanced' stack (')':rest) = head stack == '(' && balanced' (tail stack) rest
    balanced' stack (']':rest) = head stack == '[' && balanced' (tail stack) rest
    balanced' stack ('}':rest) = head stack == '{' && balanced' (tail stack) rest
    balanced' stack (_:rest) = balanced' stack rest

Tarean• 7 years ago

My naive version would be

    import Control.Monad (foldM)
    checkBalanced :: [Char] -> Bool
    checkBalanced = isStackEmpty . foldM step mempty
      where
        step (x:xs) c
          | x == c = Just xs
        step ls c
          | Just r <- inverse c = Just (r : ls)
        step _ _ = Nothing
        inverse = flip lookup [( '(', ')' )]
        isStackEmpty stack = stack == Just []

jejones3141• 7 years ago

I think that '()))((' will be judged balanced by the above code.

db48x• 7 years ago

No, he checks each time through the loop to see if the counter ever goes below zero; if it does, then the string is unbalanced.

kerkeslager6• 7 years ago

Why don't you write a unit test and see? :)

somacert• 7 years ago

Scary, that is almost the exact code I came up with.

The funny thing is balanced parens can be recognized with with a state machine it is just ugly.

        state_data = {
                '0p':{
                        '(':'1p',
                        ')':'fail',
                        'END':'pass',
                        'OTHER':'0p',
                        },
                '1p':{
                        '(':'2p',
                        ')':'1p',
                        'END': 'fail',
                        'OTHER':'1p',
                        },
                '2p':{
                        '(':'3p',
                        ')':'2p',
                        'END': 'fail',
                        'OTHER':'2p',
                        }

                 ...
            }

Just make sure the state machine has as many states as you need paren levels.

I admit the moment that the math vernacular appears my brain seems to shut down, however after reading the proof that balanced parens cannot be described several times. It seems to depend on a couple things.

1 The string is allowed to be infinite the state machine not.

2 "But state(B, start, p) is the same state as state(B, start, q)!" why? the strings are defined to be different I see no reason they would be in the same state.

EDIT added analysis of article proof.

braythwayt14• 7 years ago

The proof rest on feeding a nested parenthesis string to a hypothetical DFA called “B.” Since these are nested parentheses, a string that is recognized will be of the form `pp’`, where `p` is a string of open parentheses, and `p’` is a string of closed parentheses the same length as `p`.

e.g. (((((((((())))))))))

In that example, `p` is length ten. After reading `p`, the recognizer must be in one of its states. It can’t have halted, and it can’t have recognized.

Let’s say that the recognizer has `n` states. Consider the strings (), (()), ((())), ...

After (, the machine is in some state. Let’s give that a number, 0.

If we start all over and give it ((, it must be in another state, state 1, or we must accept that two different strings end up in the same state. Then we can start all over and give it (((, and we must end up in state 2. And so we can go, adding a parenthesis each time, and the machine must end up in a different state after reading a different number of opening parentheses.

Eventually we reach state n-1, after starting from scratch and giving it n opening parentheses. We must now know that all the strings from 0 to n-1 in length lead to n different states in an n-state DFA.

So what happens when we give it n+1 opening parentheses?

It must end in one of its states, but we already know that the strings with one through n opening parentheses have ended up in each of its n states. So the string with n+1 opening parentheses must end up in the same states as one of the shorter strings with opening parentheses, we just don’t know which.

Back to the proof. The shorter of the two strings is p from the proof. The longer is q.

arthurcolle2• 7 years ago

https://github.com/stochastic-thread/balanced_parentheses/bl...

What do you think of this implementation I just wrote? It is generalized to work with parentheses, brackets and braces, and to handle the different types of braces I just used different scores that offset each other depending on the direction of the symbol. Couldn't really think of a better way to handle this other than using numbers that don't add up to one another (in a momentary fugue state, I used 1,-1,2,-2,3,-3 as the score values but that obviously doesn't work as [}) would be false flagged as matched. Doesn't seem elegant to use random floats to accomplish this.

It's a pretty trivial problem, but I think coming up with a clever solution to the generalization is a little more interesting.

P.S. your site is down

kerkeslager6• 7 years ago

https://github.com/stochastic-thread/balanced_parentheses/bl....
What do you think of this implementation I just wrote? It is generalized to work with parentheses, brackets and braces, and to handle the different types of braces I just used different scores that offset each other depending on the direction of the symbol. Couldn't really think of a better way to handle this other than using numbers that don't add up to one another (in a momentary fugue state, I used 1,-1,2,-2,3,-3 as the score values but that obviously doesn't work as [}) would be false flagged as matched. Doesn't seem elegant to use random floats to accomplish this.

Two critiques, one minor, and one major:

Minor critique: is_balanced is a pure function. It doesn't need to be wrapped in a class, and an object doesn't need to be instantiated to call it. This adds complexity and in general is a bad habit. Languages like Java require classes, but that's Java exposing details of its underlying implementation, not a pattern to be imitated.

Major critique: try your function with the string "((((((]]]]]". In general, your approach doesn't work, because for whatever numbers you use (such as x=1 and y=1.2) the scores will "collide" at when there are lcm(x,y) where lcm is the least common multiple function. There's an even subtler bug for the string "{)(}".

It's a pretty trivial problem, but I think coming up with a clever solution to the generalization is a little more interesting.

Yes, once you're generalizing I think the PDA becomes basically the simplest solution.

P.S. your site is down

Thanks! It actually wasn't down, my HN profile was just linking to an old URL. I fixed it. :)

karthickgururaj• 7 years ago

Sorry - I'm not able to understand the post. I fully understand the problem - I ask this question sometimes during interviews - with two bracket characters. Say, () and []. So a string like "([)]" is not correctly balanced.

Some folks try with counters - but that very quickly gets out of hand. I try to prod them to a solution - by giving patterns that will defeat their solutions.

What I'm expecting is that the person can identify that use of stack here, which (and this is my source of confusion here) - is the most natural way to solve this problem. Push when we encounter an opening bracket, pop and match when we encounter a closing bracket. The function is generic, within 10 lines in C, can easily be extended to more bracket characters.

So - what is the point of this post?

poopchute• 7 years ago

Its a quick intro to computability theory. There is a progression of more and more complicated 'machines' on the way from Finite Automata towards Turing Machines. This article goes over what types of things each machine can and can't solve. Its more of a theoretical topic than a practical one (and why you'll occasionally see silly things like someone implementing a turing machine in powerpoint to show that powerpoint could compute anything)

A Brutal Look at Balanced Parentheses, Computing Machines, and Pushdown Automata

Related Stories