It is not necessary in this problem to restrict the domain to the reals in order for solve to solve it, and at the time that I had posted my Answer, Markiyan had not yet added the phrase "over the reals."

@Carl Love 

And here is the code. The first argument, E, is a set of polynomials presumed to be set equal to 0. The second argument, V, is optional and is a list of the variables in E to prescribe the order of the solution lists. If V is omitted, then a default order is chosen and returned.

SolveMod2:= proc(E::set(polynom), V::list(name):= [indets(E,name)[]])
     V =
     select(
          X-> (VatX-> andmap(e-> Eval(e, VatX) mod 2 = 0, E))(V=~ X),
          (N-> combinat:-permute([1$N, 0$N], N))(nops(V))
     )
end proc:

And here is the code run on a problem of the size that you mentioned. This takes less than 20 seconds on my computer.

E:= {'randpoly([x||(1..11)])' $ 11^3} mod 2;
SolveMod2(E);

Of course, the probability that a random system of 11^3 polynomials in 11 variables has any solution mod 2 is infintesimal. Here is the code run on a system with solutions.

E:= {'randpoly([x||(1..11)])' $ 32} mod 2:
SolveMod2(E);

Are they linear equations? Is some significant subset linear?

@rit 

I said that there were 16 binary operations on two variables. By that I meant that there are 16 functions from {0,1} x {0,1} to {0,1}. If you want to do larger sets, then no, Bits does not handle that.

Regarding the zero padding: That's what the bits argument does. That's why I said

Bits:-Not(235, bits= 8);

(Although it is not necessary in this simple example.)

Regarding your C# code: The point of bitwise operations is to avoid using strings with their inherent relative inefficiency. A single machine word can substitute for a string of 64 bits (assuming a 64-bit processor).

@beidouxing 

But in Maple you cannot substitute {} for (). Maple will often allow you to enter the expression with {}, but this changes the mathematical meaning of the expression. It makes it a set.

@wenny 

Once you use absolute value, there is an infinitude of pairs (a,b) such that the objective function is 0, its minimum value. Those pairs lie along a line in the (a,b) plane. The minimize command has returned to you the equation of that line.

To get a numeric answer, you need some constraints on a and b. If a and b are allowed to be arbitrarily large, then obviously the function value will become arbitrarily small (to -infinity).

@acer 

I was doing what you suggested as you were entering the above comment. See my comment above.

@ 

It's a great solution technique, but setting [A=0, B=0] really trivializes the problem. Here is a way to use other parameters and still have it be automatic.

Download ODEtoDAE_2.mw

@Dave L 

I heartily support user-supplied tolerances for fsolve, something akin to what is available for numerical integration. I've encountered many problems where the failure of fsolve to converge seems to be caused by the tolerance being too close to the working precision.

@Kitonum 

Okay, I see your point. I would rather that plot3d have an option to specify the handedness than needing to switch the order of the arguments, but it is the way that it is.

@Kitonum 

Yes, I was well aware that plot3d allows the abominable syntax x= 0..1, y= 0..x, but I'd prefer to forget it because that syntax encourages sloppy mathematical thinking.

I'll rephrase my advice:

I find it most useful to remember that one should set the ranges in plot3d to be exactly the same as the ranges that one would use for a double integral of the surface over the region in question.

I find it most useful to remember that the limit ranges for the variables in a plot3d are exactly the same as the limits you would use to set up a double integral of the surface over the region in question.

@nm 

Yeah, the hypergeometric answer is wrong and clearly cannot be evaluated for integer n. Sorry that I didn't check that before posting. I have no idea where this answer comes from.

@Mac Dude

 By "closing a paragraph," the OP means collapsing a section.