Series solutions are theoretically infinite series for which (usually) only a finite number of terms can be determined. Let's say that the independent variable is x, the constant of integration is C, and the expansion point is a. Generally, C appears in every nonzero term. The only way to solve for C is to plug in x=a because this is the only thing that will make all terms of the infinite series 0 (other than the 1st term). Plugging in some other value of x would only allow you to approximate C using your finite number of generated terms.

Although your notation for the 0 case isn't complete, this is (to my mind, at the moment) the only possible sensible interpretation of it: Do the nonzero cases as specified; all other cases are 0.

There are a vast number of ways to implement that interpretation in Maple. Here is one---an m x n matrix:

m:= 10:  n:= 9:  #example values
M:= Matrix((m,n), (i,j)-> `if`(((m - i)*(n - j))::odd, i*j/(m^2 - i^2)/(n^2 - j^2), 0));
 

For any integers m and i, both m + i and m - i have the same parity, so there's no need to specify "plus or minus". Also, i = m implies (m - i)::even, so i = m and j = n don't need to be listed as special cases.

It can be done like this:

(convert~)~(fasteners, unit_free)

This can be extended any number of levels, but the syntax forbids (I believe) ~~, so the parentheses around convert~ are required.

To see what's happening, observe

(f~)~([[a], [b]], c); 
             [[f(a, c)], [f(b, c)]]

I doubt that any factorization algorithm could beat the average-case time of this naive division algorithm:

p_log:= (n::And(integer, Not(0)), p::And(posint, Not(1)))-> 
    local k:= 0, q:= n; do k++ until (q/= p)::fraction   
:
#Example:
p_log(2^9*3^7*5^2, 3);
                               7

It can be quickly done by hand (or with the assistance of Maple), and a tiny guess. Are you familiar with Descartes' Rule of Signs [Wikipedia link]? If a real univariate polynomial is sorted by degree (direction doesn't matter), you count its number of sign changes of its coefficients, ignoring coefficients that are 0. If that number is odd, it guarantees a positive root; if it's 0, it guarantees that there's not a positive root (and if it's another even number, then you can't tell). So, for your polynomial we check P(1, y) because x=1 is positive and it's easy to plug in by hand. The resulting polynomial in y has 1 sign change, which is odd, so there's a positive root (let's call it r) for y.  Thus (x= 1, y= r) is a positive root for P(x,y).

This can also be done by the Maple command 

sturm(P(1,y), y, 0, infinity);

You have two choices for your input to Maximize (and other commands in package Optimization): The objective and constraints are either all expressions or all procedures; they can't be a mixture of expressions and procedures. Your f is a procedure, and your Cons is a set of expressions. The error message is telling you to make Cons into a set of procedures.

For this problem, you don't need to use procedure-form input. Tom's Answer shows how to do it with expression input. But if you do want to use procedure-form input (which is sometimes necessary), here is a way to do it:
 

Download ProcFormInput.mw

Here's one of many possible interpretations of what you want. I like this one because it doesn't require foreknowledge of the number of meaningful values of S||i.

for i while (x:= S||(i+1))::And(algebraic, Not(name)) do S1+= x od;

A great command for plotting polynomial curves in two variables (even those of high degree) is algcurves:-plot_real_curve. It figures out all those little details, such as the ranges.

algcurves:-plot_real_curve(
    2.96736996560705e-12*p^2 + 1.31319840299485e-13*t^2 - 8.89549693662593e-7*p +
    8.53128393394231e-7*t - 3.65558815509970e-30*p*t - 1,  # Don't use "= 0"
    p, t, 
    scaling= constrained
);

Since your coefficients have 16 digits precision, it's worth checking if a higher Digits setting makes any difference. I did check that, but it made no difference perceivable to the naked eye.

If your attention is restricted to polynomials of degree 2 in 2 variables (aka "conic sections"), then there are formulas of the 6 coefficients to tell you almost anything you want to know about its geometry, such as whether it's an ellipse, and, if so, ranges of the variables.

Change all square brackets [] that are used algebraically within the equations to round.parentheses (). The [] that group the equation and IC together in the dsolve command should remain. Get rid of the simplify command for now.

It's an interesting Question; I vote up.

To do what you want, you need to declare notsave::uneval. For example:

restart:
Excl:= {'x', 'y'}:
(x,y,z,w):= (3,5,7,9):
SaveNames:= (excl::uneval, fname::{symbol, string})->
    subs(
        _V= remove(
            type, {anames}(user), 
            {procedure, identical(eval(excl, 2)[], eval(excl, 1))}
        )[],
        proc() save _V, fname; return end proc
    )()
:
currentdir("C:/Users/carlj/desktop"):
SaveNames(Excl, "V.txt");


restart:
currentdir("C:/Users/carlj/desktop"):
read "V.txt";
                             w := 9
                             z := 7

x,y,z,w, Excl, eval(SaveNames);
                  x, y, 7, 9, Excl, SaveNames

In the line Excl:= {'x', 'y'}, the quotes would only be necessary if those variables had been already assigned values.

In the remove command, the eval(excl, 2)[] specifies the elements of the exclusion set (as names), and the eval(excl, 1) specifies the set's own name. The 2 and 1 are the number of levels of evaluation used.

If you consider the projection computed in part a to be a point p rather than a vector (this different point of view, i.e. the point\vector distinction, doesn't require any change in the Maple syntax), then the distance for part b is the distance between a and p. This works because the line goes through the origin (at lambda = 0).

Consider this counterexample (which I'm composing in my head while typing on my phone; no paper or Maple, so maybe I'm mistaken): The edges are {{1, 2}, {1, 3}, {2, 4}, {3, 4}, {4, 5}, {4, 6}, {5, 7}, {6, 7}}. I think that the max flow from 1 to 7 is 2, but there are not 2 vertex-disjoint paths from 1 to 7.

However, it does seem plausible to me that the max flow always equals the maximum number of pairwise-edge-disjoint paths.

Does the command PolynomialIdeals:-Quotient do what you want?

Maple's Iterator package is precisely made for this purpose: to generate combinatorial objects one-by-one so that they can be used in a loop without needing the entire list of them stored in memory. For example:

n:= 5: k:= 3:
for C in Iterator:-Combination(n,k) do
    print({seq}(C+~1))
od;
                           {1, 2, 3}
                           {1, 2, 4}
                           {1, 3, 4}
                           {2, 3, 4}
                           {1, 2, 5}
                           {1, 3, 5}
                           {2, 3, 5}
                           {1, 4, 5}
                           {2, 4, 5}
                           {3, 4, 5}

The in clause in the for-do loop header hides the fact that the objects are being generated one-by-one (per loop iteration) rather than as a container (list, sequence, etc.). 

Over the years, I have extensively tested the efficiency of various iteration commands in Maple: for-do, seq, map, etc. There is no significant difference between for and the others. It has a totally undeserved bad reputation for inefficiency. That reputation may be due the fact that there is a very inefficient operation which is unfortunately very common among newbies, and is done with do loops: building a sequence, list, or set one element per loop iteration. The inefficiency is specific to those three container types; building tables or arrays per loop iteration works fine.

The try ... catch statement is the way. In the following example, we predict that we'll face division-by-zero errors, but there's no need to tell Maple that. In other words, there's no need to put any string after the catch. The next statement means to continue with the next iteration of the loop.

R:= rand(-9..9):
randomize(1):
[to 9 do 1/R() od];
Error, numeric exception: division by zero
randomize(1): #to generate the same random numbers
[to 9 do try 1/R() catch: next end try od];
                  [-1  1  1      1  -1  1  -1]
                  [--, -, -, -1, -, --, -, --]
                  [4   2  3      2  4   6  9 ]

Note that the output list has 8 entries, not 9, indicating that one zero was skipped.

The above example is intended for 1D input (aka Maple Input) only.