The warning indicates that the expression (6) contains a variable other than n, m, or k. Without seeing expression (6), I can't tell what that variable is. If this is not enough info for you to be able to solve the problem, please post the actual expression and/or upload a worksheet containing it.

dsolve({(D@@3)(y)(x)+D(y)(x)/x-y(x)/x^2, y(1)= 1, D(y)(1)=0, (D@@2)(y)(1)=1});

eval(%, x= 3);

evalf(%);

We can use an implicitplot to make a guess at an integer value for one of the variables and then solve for the other. If we get an integer, we're done.

restart:
S:= sum(
     (120*n^2+A*n+B)/16^n/(512*n^4+1024*n^3+712*n^2+194*n+15),
     n= 0..infinity
);
S:= simplify(S);
plots:-implicitplot(S=Pi, A= -200..200, B= -200..200);

From the plot, I guess B=47.

solve(eval(S, B= 47)=Pi, A);
                                          151

Download Pi_sum.mw

If you enclose a sequence in curly braces {}, then it is a set and Maple will put it in an order of its own choosing. If you want the order to matter, then you must enclose it in square brackets [] (or not enclose it at all---but that makes it tricky to work with), and it is called a list.

When you display a list of plots in the default inline GUI renderer, then the filled interiors of the polygons are printed in the reverse of the order that they are listed. This is shown by the following simple example:

p1:= polygonplot([[0,0], [2,0], [2,2], [0,2]], color= red, transparency= 0):
p2:= polygonplot([[1,1], [3,1], [3,3], [1,3]], color= blue, transparency= 0.5):
display([p1,p2]);

display([p2,p1]);

This rule does not necessarily apply to text, axes, gridlines, polygon borders, or any other 1- or 0-dimensional objects.

A:= Array(1..10, i-> .1*i, datatype= float):
dsolve({diff(y(x), x) = y(x), y(0)= 1}, numeric, output= A);

High-level symbolic routines such as diff and maximize cannot be translated. Yes, translation of "functions" is limited to the block that you found in the link.

You shouldn't rely on there being an x in the input expression; your procedure should work for other variables. Here are three possible approaches to this.

The first approach is to check whether there is only one variable in the expression and to use that variable.

refinedexample1:= proc(expr::algebraic)
local
     x:= indets(expr, And(name, Not(constant))),
     f:= unapply(expr, x[])
;
     if nops(x)>1 then
          error "expecting a single name in %1, but found %2", expr, x
     end if;
 
     f(Pi)
end proc;

The second approach is to require the user to pass in the variable. This is the approach used by most Maple procedures. You can make it default to x if nothing is passed in:

refinedexample2:= proc(expr::algebraic, x::name:= :-x)
local f:= unapply(expr, x);
     f(Pi)
end proc;

The third approach is a hybrid of the first two. If no variable is passed by the user, then it checks for a single variable and, if found, uses it; otherwise it uses the variable passed in. This is the approach used by most procedures in the Student package:

refinedexample3:= proc(expr::algebraic, X::name:= [][])
local x,f;
     if X = () then
          x:= indets(expr, And(name, Not(constant)));
          if nops(x) > 1 then
                error "expecting a single name in %1, but found %2", expr, x
          end if;
     else
          x:= {X}
     end if;
     f:= unapply(expr, x[]);
     f(Pi)
end proc;

Addressing your second question, about data type: The data type is literally algebraic, which I've used in the above procedure declarations.

It seems like there are some invisible characters which are commenting out the lines that define vlak2, vlak3, and vlak4 in procedure f. I have never seen a bug like this! And this is with 1D input no less! If I cut-and-paste your plaintext code, then it works (I had to delete the "10" output of the interface(rtablesize= infinity) command from your plaintext.)

Here's a workaround: Cut-and-paste procedure f to a Code Edit Region. It's on the Insert menu. To execute the code (i.e., to define the procedure), right click on the Region and select Execute Code.

Another workaround: Cut-and-paste the code to a plaintext file, like Microsoft Notepad. Then cut-and-paste it back to a new Execution Group in your worksheet.

Here is the worksheet with the first workaround applied. I also left the erroneous Execution Group in the file so that someone else can find the source of the bug.

vraag.mw

Let me know if you can use this.

There is no bug. You need to hande the symbolic case for u(t,x), i.e., when t is a symbol, not a number. If t is a symbol, then it is not 0, so the Dirac case in your `if` is never executed.

So, change your G definition from

G:= (x,xi,t)-> `if`(t=0, ...);

to

G:= (x,xi,t)-> `if`(t::realcons, `if`(t=0, ...), 'procname'(args));

This is not "solving" the conjecture; it is verifying it.

The following could be done faster by sieving for the primes, at the expense of a few more lines of code.

Goldbach:= proc(n::even)
local ct:= 0, p:= 2;
     while p <= n/2 do
          if isprime(n-p) then ct:= ct+1 end if;
          p:= nextprime(p)
     end do;
     ct
end proc:
    
Goldbach(10^7);
                   38807

X:= proc(n)
option remember;
     n*(thisproc(n-3)+thisproc(n-2)+thisproc(n-1))
end proc:
(X(0),X(1),X(2)):= (0,1,2):

length(X(2013));
                              5782

There may be some number-theoretic subtlety that can be applied to this problem. However 2013^1102 is not a big number by Maple standards, and this problem can be done in a few seconds by straightforward computation.

It is not clear to me that every number is attracted to one of the three orbits that you gave. The following procedure only terminates if one of those orbits is reached.

f:= x-> `if`(x::even, x/2, 3*x-1):

F:= proc(X::posint)
     local x:= X;
     do
          if x in {1,5,17} then return x end if;
          x:= f(x)
     end do
end proc:

F(2013^1102);
                              1

When applied to functions (in the Maple sense of that word), combine does the opposite of expand. So, if you agree with the output of expand(cos(x+y)), then the logical extension is cos(2*x) = cos(x+x). So expand(cos(2*x)) is 2*cos(x)^2 - 1 = 1 - 2*sin(x)^2. The combine is just applying that in reverse.

It is a bug, not anything wrong with your code. It gets stuck in an infinite loop. I haven't figured out a workaround yet. If you simplify the model to f:= a+b*x^c, then it works immediately.

See ?Digits and ?Rounding . For chopping:

Digits:= 4:  Rounding:= 0:

For rounding:

Digits:= 4:  Rounding:= nearest: