@mehdi jafari

You can construct the sequence with n unknown by using $ instead of seq:

S:= P(j,n) $ j= 1..n-1;

Then specify n later:

n:= 4:
S;

Could you provide a more-detailed example please? Show me precisely an example of an "arbitrary function" and what you consider to be its dependent variable(s). Show me precisely an example of the type of input expr you want your procedure to take. And what do you mean by "matching" the "dependent variables list". How can there be more than one dependent variable?

Look at ?Statistics,NonlinearFit . Note that the independent variables are passed in as a list, the parameter v. The value of the expression falg is implicitly the dependent variable, so there is no dependent variable that appears explicitly in the input.

I think that you may be confusing dependent and independent variables.

@Bruno Gobin You are using a very crude workaround so that you can use sum in a way that it was not intended to be used! The problem is solved by using add instead of sum. Quoting from ?sum :

To add a finite sequence of values, rather than compute a formula, use the add command....  Although the sum command can often be used to compute explicit sums, it is strongly recommended that the add command be used in programs if an explicit sum is needed....

@J4James 

You may get better results by animating (2D) contourplot instead. Then you'll get 65 contours in every frame because it won't be constrained by the z-axis. But... The contours will not represent the same level curves in different frames.

@delta7 Ah, that works also.

To see all the color names (there are hundreds) issue the command:

ColorTools:-GetColorNames(),
seq(ColorTools:-GetPalette(P), P in ColorTools:-PaletteNames());

@J4James You must use the same view option in both the animation and all the static plots.

@J4James

In the static plot, include the option view= [DEFAULT, DEFAULT, -35..1]. Then it will look exactly like the last frame of the animation.

@mehdi jafari I believe that the complex aspect has nothing to do with it. If you don't use convert_to_exact= false, then it tries to use solve to solve exactly for the constants of integration. Any floats in the input equations are converted to exact rationals. This solve may fail even if the dsolve has (so far) suceeded. If you do use convert_to_exact= false, then it still uses solve to solve for the constants, but this time solve is working with floating-point coefficients and is more likely to return an answer.

@ilke I would not rule out the possibility of getting a analytic solution with numeric coefficients. The fact that dsolve did not return any answer just means that it could not get an analytic solution with exact coefficients. We already that we can get an analytic solution with symbolic constants (i.e., no initial or boundary conditions). It should be possible to solve numerically for the _C1, ..., _C4. I'll work on it.

The presence of complex numbers in the solution is not the issue.

@ilke You need to use a numeric solution such as that given by Mehdi Jafari, or an analytic solution with numeric coefficients such as I explain in an Answer below.

@rit I have no knowledge whatsoever of the matter.

@Markiyan Hirnyk 

I downloaded your worksheet and executed it in Maple 18 (build ID 922027). I obtained the same error as the OP.

What version of Maple are you using? I tried Maple 16, 17, and 18 and your "Not runnin" code worked in all three for me. Here's the plot:

Please post the objective function Eq1_new.

@nm wrote:

When you do

    bb[i]:=

without pre-allocating bb, the loop becomes inefficient as a new larger bb array has to be created each time.

This is not true in Maple. You may thinking of the case where bb is a list or a sequence. In that case, it is highly inefficient to add an entry to the end for each iteration, and the structure does indeed need to be created from scratch for each new entry.  So each new entry takes O(nops(bb)) time.

If bb is an unassigned name, then making an assignment to bb[anything] establishes bb as a hash table, for which adding entries is quite efficient (each add takes O(1) time). It is true that it is even more efficient to preallocate the memory, but the difference is very slight.