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:

Go to the Maple Applications Center to get the Orthogonal Expansions package. Click on "Download attached file". Follow the trivial installation instructions in the ReadMe file.

Now you can easily find Fourier series in Maple. (Note that Pi is spelled with a capital P in Maple.)

restart:
f:= x-> min(abs(x), Pi/2):
FS:= OrthogonalExpansions:-FourierSeries(f(x), x= -Pi..Pi, infinity);

plot(f(x), x= -Pi..Pi);

plot([seq(eval(FS, infinity= n),  n= [1,2,3,5,6,30])], x= -Pi..Pi);

You will gain understanding of the order in which things are done if you set printlevel:= 15 before running your loop. You are reusing k for every i and j. So only the last (i,j) combination is saved for each k. If you don't understand that, I can explain more. Let me know.

What you want is this:

for i to 3 do
     for j to 3 do
          k:= 3*(i-1)+j;
          a[k]:= (i,j)
     end do
end do;

eval(a);

Note that table entries are not necessarily stored in any order.

Your nested for-do loops can also be done by nested seq loops and a table constructor:

a:= table([seq(seq(3*(i-1)+j = (i,j), j= 1..3), i= 1..3)]);

Try

subs(sqrt(c)= omega*sqrt(m), xsol);
simplify(%);

Try this:

restart;
eta:= (x,y)-> y*sqrt(U*v/x);
alias(eta= eta(x,y));
Phi:= (x,y)-> sqrt(U*v*x)*f(eta);
e3:= vx = diff(Phi(x,y),x);
e4:= vy = diff(Phi(x,y),y);

sort([B||(1..3)], (A,B)-> (A[2]-A[1]) > (B[2]-B[1]))[1];

This looks at the width of the interval, not just the upper limit of the interval.

The sort is builtin and very fast. But if you were doing a very large number of intervals (millions probably), it may be faster to code a linear search for the max.

It's very easy:

L:= [[0,2,3,0,0], [2,3,0,0,0], [1,1,2,2,0]]:
add(1/mul(x!, x= LL), LL= L);

Also, it is not necessary that the lists be the same length. So there is no need to pad with zeros.