This page is for student questions and my answers related to HW#8. Questions are in black, answers in blue.

On Question 1, you say "Prove that under this definition, the classes NC[t(n)], AC[t(n)] and TC[t(n)] would be the same for any function t(n)."

Are you asking us to prove that each of the classes would be the same under the new definition as they were under the old definition? Or are you asking us to prove that under the new definition, the classes are the same as each other?

The first, that the two definitions of *each class* give the same class.
The different classes are still probably different from each other (since they
haven't changed), but whether they are is still unknown.

In Question 2, is c_{0} always equal to 0?

Yes, c_{0} would be the carry bit from the place to the right
of the "binary point". Since we're adding integers, there's nothing
to the right of the binary point so this carry bit is 0.

While proving MCVP in P, you said that we can reduce CVP to MCVP using double-rail logic. Am I missing some details here? I can't figure out how to make two gates out of one gate in the original circuit.

Let me describe the double-rail construction again. Suppose C is a circuit with s gates, including NOT gates, and with n inputs. We make a monotone circuit D that has 2s gates, with no NOT gates, and with 2n inputs. The way we make D is to make two copies of each gate in C, and connect them as I described in lecture.

The reduction from CVP to MCVP takes (C,x) to (D,x,x-bar) where x is a string in {0,1}^n and x-bar is the string in {0,1}^n that is the bitwise complement of x.

I'm worried that my solution to Question 6 is too easy. What exactly is the input size n in this problem?

Don't worry, the simple solution you've described is correct. The main point of this problem is to put the "polynomial time" of the next problem in perspective, and to give a little insight as to the perils of unrestricted use of O-notation (i.e., we have a "constant-time" solution here that is not at all practical).

The input, however big it is, must represent a configuration of a 64-square chessboard. One possibility is that the input is thus never bigger than a certain constant size. If the input is allowed to be bigger, you may assume that we can extract the chessboard position from the input string in constant time.

I just noticed a discrepency regarding the HW8 due time: the home page announcements say 4:00pm, the homework assignment itself says 4:30pm. Not a big deal, but I thought I'd mention it.

Thanks, I'm clearly not going to reject things handed in between 4:00 and 4:30 but I should mention this in class.

On HW 8 Question 6, what exactly is meant by White "forcing" a win? Is the following recursive definition correct? (Base case) White can force a win in a position if she has a move that takes her to a position in which Black is checkmated. (Induction step) White can force a win if she has a move that takes her to a position in which all of Black's moves go to a position in which she can force a win.

Yes. There is a simpler base case -- White "can force a win" if it's Black's move and Black is already checkmated.

The thing I'm not sure about is the "all." I think that under this definition, the language CHESS-WIN is smaller than what would typically be regarded as winning positions for white (even with the business of draws being losing for white) as it requires all of Black's moves to go to a forced win, ruling out cases in which Black can say, sacrifice a piece to avert mate, thought that piece may be of great enough value to cost Black the game eventually, just not in a forced way.

If Black gives up his queen, the resulting position is probably a losing one. If there is no way for Black to save the game under optimal play, then that position will be defined to be "White-win" by using the definition you give above. I think you may be neglecting the fact that there can be a large number of rounds of recursion before a position is declared winning or losing. (For example, if White can force mate in 42 moves, the position is winning for White. Remember, though, that we are counting stalemates or three-time repitition of positions as wins for Black, so White has to be able to force mate against these alternatives as well.

I can't quite parse question 5. The threshold for every gate seems possible to be any number: anything smaller than 12 and also anything bigger or equals to 12 (suppose s=24).... so what exactly are we trying to prove here?

If your gate has 1000 inputs the threshold must be at most 12 or at least 988. It is true that any threshold gate with only 24 inputs is ok, but a general threshold circuit could have gates with fan-in ranging up to the size of the entire circuit.

You say "We might have defined these classes in terms of circuits that had NOT gates of fan-in one anywhere in the circuit." Do these circuits have any other constraints? I.e., where our original definition is analogous to MCVP, this definition is analogous to CVP, allowing all AND and OR gates as well?

That's right, you have AND and OR gates, plus threshold gates in the case of the ThC classes. Size is still number of gates and depth is still the length of the longest path from input to output. The fan-in of AND and OR gates is still two for the NC classes and unbounded for the AC classes.

Do we have to use double-rail logic in Question 1? I think I see how to do it by just applying DeMorgan's Laws repeatedly.

You're right, if we aren't considering uniformity you just have to show
that the monotone circuit of the correct size and depth *exists* given
that the original circuit exists, so you don't care how hard it is to make
the monotone circuit from the original one. (Note also that for threshold
gates you are going to have to think about what version of DeMorgan you are
going to need. I prefer the double-rail proof because it makes the gates of
the new circuit locally, from individual gates of the old circuit, and thus
is very easy to implement in parallel (for example, it gives FO-uniform
circuits if the original ones are FO-uniform).

Last modified 11 May 2004